Workflow sample: from start to defeat (it’s almost like in “Star Wars” ☺):
Episode I: A New Hope
Automation is just started from scratch or continued after stagnation. A lot of energy and aspirations. First simple tests are developed and look ok.
Episode II: The Force Awakens
Coverage is growing, several dozens of tests work ok and look like profitable. But on horizon you can see, that current workflow isn’t ok for automation and requires future changes, because soon you will rest against the ceiling of possibilities.
Episode III: The Phantom Menace
Allusions to management, that it needs to think about more deep changes and current automation process will hit to possibilities ceiling soon, does not face much interest. You are asked to think about it later, and first focus should be on the current decision. Especially since it is so well developing.
Episode IV: The Empire Strikes Back
You are before the fact that no cardinal changes will be expected. Together with that you are forced to extend coverage with scenarios which are becoming more complicated, and to be honest, they should be done not by automation crutches, but by management & development processes fixing. Also developers don’t fix your found bugs, because it happens only in your tools or tests that means it’s your problem.
Episode V: The Last Jedi
Disappointment. All crumbles around. Tools which you developed, should be adapted again and again for strange solutions on developers side. Users find new and new bugs in your tools due to incompatibility with developers code. And obviously it should be fixed on your side. Tests adaptation requires a lot of time and looks like endless routine. Increasingly, the viewing of new vacancies begins along with the loss of interest to the case, which beckoned so much some time ago. Ok, this vacancy looks cool, interview is scheduled…
Cards House is broken.
Typical symptoms, which should make you thinking, that you will meet this workflow in a team (check at interview):
- They don’t have unittests — Today it’s difficult to imagine that big project can be tested only on end-user level, without unittests.
- They don’t use CI — CI is standard since long time. And if it’s not used in workflow, no automated builds or tests runs, it’s alarming sign.
- They don’t have automation — To have tuned automation process isn’t an issue for many years already. And if it’s absent, it does not say anything good about product quality.
- They don’t have code review — It is very-very bad signal. Code review is workflow part which should be set up first of all and doesn’t require special technical tools. It’s not possible to have high quality if each developer pushes his changes to ‘master’ branch directly.
- They aren’t decision makers — There is a multi-layers hierarchy in management. And probability, that you can pass through bureaucracy and will change giant machine, tends to 0.
- They will give you a chance to make all from scratch — My favourite, which means not capabilities, but problems that will delay like the tentacles of a giant squid. It looks like ‘Ability to understand someone else’s code’ for developers.
The presence of above factors should make you thinking “Are you ready to become a ‘loner hero’ ?”
Solution:
- Avoid getting into such conditions. See topic about symptoms.
- Run away if you are inside there already. If you feel you like your profession, it will be a best way to find a team or company who shares your views, instead of attempt to change a game. The spent efforts, time (and sometimes health) will not be paid off with the result.
