Bad habits in testing-management
This is the continuation of my speech about bad habits in testing.
Suppose we learned a lesson from the last speech. But, in fact, we work not alone, but with other people.
We manage, we're being managed.
I'll tell you about bad habits in test management, which is worth learning.
I will teach you bad.
Author's control: you all do it, just do not know about it
Author's control: "You all do it. Just do not know yet."
In my speech, I'll tell you about a seemingly obvious thing as "Author's control".
Have you ever had such things that everything was done according to specifications, properly tested and everything is fine ...
But it turns out full of shit. How can this be avoided?
In my speech, I'll tell you about such practice as "Author's control", how and when and why it should be used.
But in fact, you really do it all. Just don't know about it yet.
Bad habits in software testing and management
Human is designed so that only studies that to which is the soul. We can try to teach something under pressure.
But this is not our method, Shurick.
In the history of mankind, man best surrenders self-destruct and fall into the abyss of vice and chaos.
So in testing.
Not everyone wants to reach the heights, remaining little white and clean.
In my report I will teach you some bad habits that will make easier your life as a tester or test-manager.
Welcome to the Dark Side.
I will teach you Bad.
Guide to QA dept devastation
There are many success-stories about how to create a QA dept or processes.
But I don't like success stories.
In my report I will tell you about the typical mistakes that people with whom I worked and me made.
In the full of venom and hatred form you will hear about few "sins", which we and our bosses like to do.
This will help you understand how to act when confronted with it and how not to make such errors.
Attention! All coincidences are not accidental.
BDD. Gherkin+Ruby or auto-tests for the humanities
In this report, I will tell you what is BDD and how, using Gherkin, autotests can be written even those who never engaged in programming. It's so tempting when auto-tests in advance can write even a designer!
Almost GitHub Flow in web-development or how we develop Rustoria.ru
A long time ago, I've split all reports on two kinds:
1. Spherical methodology in vacuum.
2. Look how we made this.
I've decided to make my report by second way. In my report I'll introduce you one of the possible ways of web-interface's development and testing processes. I'll show you what is git issues, tell you about our deployment scheme and continuous delivery. This report is like some kind of our progress report. I can't ignore the following questions:
- How to live without bug-tracker and why we should keep friendship with designers?
- Benefits of processing pull-requests via "L.I.F.O."?
- What is "L.I.F.O."? - "FFFF" - our main principle. What is it?
- "PVO" methodology. - Handmade Continuous Delivery - good or bad?
- Do we need to feed developers at nights? If yes, that why?
- Sysadmins extroverts - beyond the good and evil.
- Flexible planning - how we implemented it.
Everybody is welcome!