This blog post is about: why Operation Kalashnikov was doomed to succeed, what does it mean to have an emotional bond to a mission, why Front-End Engineers have smashed what was so hard for Quality Assurance specialists, what kind of effects we've expected and how I've cynically machiavelised the project outcome ...
Previous post in the series can be found here.
Where did the last post leave us? We were just about to start Operation Kalashnikov - our final experiment aimed to prove that we either are able to tackle the challenges of E2E automation or we should go for entirely different scenario (gardening maybe?) ...
We may be quite specific (as an organisation) but "selling" Kalashnikov to our Product counterparts (POs, Product Mgrs) was not a problem - everyone was fully on-board when it comes to the importance & value of properly automated E2E tests. No-one questioned / veto-ed Project Kalashnikov - quite the contrary: people were genuinely interested in the outcomes & openly supported the efforts.
The bond
The first surprise came even before the project officially started ...
I came to the office in the morning to find out that ... Kalashnikov has got its official posters ... official video ... official site on the knowledge base. You may find it funny & not really relevant but it's a testament of a simple fact: people who did these things personally CARED for it. It was spontaneous - they've done it in their own, private time at home ... They've got an emotional bond & they've expressed it in such a way (with posters, announcements, video, etc.) to make a clear statement:
We. Are. Gonna. Make. It. Happen.
It was definitely a good sign - at this point I knew that people had embraced the topic as THEIR mission. This is how ownership manifests itself.
TBH, the project was not a rocket science - to automate a bunch of test cases in a part of the platform that wasn't yet automated at all. The goal was to prove we're able to do it efficiently (with a much higher velocity than when using Selenium, w/o getting stuck on tricky UI constructs) - all aspects of work that were NOT about the test writing itself were to be put aside (for now), e.g.:
- CI/CD integration
- test data prep
- execution parallelism
We were far more interested in whether Cypress DSL & Electron-based test exec engine are enough to deal with the complexity of our UI (e.g. quite sophisticated calendar with pretty wide palette of interactions).
All the doubts and fears have perished around the 5th day of experiment. Front-End Engineers didn't philosophize much - they've ripped through test cases like a hot knife through a cube of butter or an icebreaker across an ice-bound bay. It seemed like they were not told it was supposed to be a challenge ;P
At this point I knew we've ...
Nailed It
Why?
The issue was never the technology. It was a combination of psychological/human-related factors people were shrugging off in a reflex of self-defense:
- bunch of front-enders from a single team were much more a team (in terms of co-operation, mutual support, etc.) than 3 times as big bunch of QAs spread among several separate teams
- by writing tests in JavaScript - their primary language of choice - front-enders have removed technology as a barrier/distractor/inertia factor: it was helping them, instead of slowing them down
- front-enders have put tests in the same repository as the original app source code - this way they didn't need several commits to adjust the DOM (e.g. add test-specific property) & separately create a test
- Cypress is a bundle which pretty much works out-of-the-box - wrapping Selenium can make you feel jaded before you actually have anything running; and you never feel it's 100% set up - there's always something to fix/adjust/etc.
- non-engineer based QAs frequently switch between very different "modes of work" - QA style (designing test cases, organizing them, preparing test data, seeding it, performing manual tests) & development style (actual test automation) - in 95% of cases it's the former that they consider a comfort zone (even if they don't like it ...), while the latter is always a stress & they don't develop as fast as test programmers as they'd like to
- a different attitude: Kalashnikov guys have meant to have it DONE, not just to be DOING it (it's a matter of small goals that are within reach, instead of perspective of mythical Nirvana no-one had ever seen)
From my perspective (as a leader of the pack) Kalashnikov was an even bigger success - now I knew that our flexibility in terms of test automation has extended: I don't need to rely on QA only, front-enders can contribute (veeery efficiently) as well.
The shakedown
For our small QA community it was some sort of shock that has completely undermined their confidence. They were visibly smashed and at this point I had completely no clue regarding how they'd react - all options were in game:
- I've suspected some were here (with us) because of Java (to learn Java & eventually become Java developers) - I've suspected these will leave nearly instantaneously
- I knew some have strong "fatherhood" feelings regarding the old solution - such individuals could treat the situation as their personal failure & wave the team good-bye after their "child's" burial ...
- it was quite likely that some will perceive front-enders' efficiency as the threat - "now front-enders will do the automation & we'll be reduced to manual testing & designing new test cases for them"
- at last but not least - I've expected that there will be individuals who won't handle the pressure: there are plenty of companies where you can pretty much indefinitely have fun writing some tests w/o any metrics or setting yourself ambitious goals like CD - why bother?
That's why we've moved quickly - to not let people speculate, assume too much or get lost in allegations ... The situation had to be crystal clear, so QA peeps could evaluate the new state of matters & make the decision - whether they are still on board & up to the mission.
Or not.
Fast pivot
The experiment was flagged as a success. The Kalashnikov team (front-enders) hasn't just executed the full plan (for their time-bound experiment), they've actually explored some more ambitious, aspirational scenarios to learn/prove even more.
We had to strike the iron while it was still hot - we've set up a follow-up meeting (for the representatives of tech leadership, QAs & front-enders who've participated in the experiment) which ... I've shamelessly manipulated by driving the discussion flow towards the pre-determined outcome I've planned beforehand ...
I'm not 100% proud of that.
But it was a defining moment when we've needed a clear direction, unambiguous & unanimous driven decision. And we needed everyone present leaving the meeting to be 100% committed to the "agreed" output ...
The next post of the series is available here.
