The Role of Testing in the Engineering Product Development Process
Vice President, Engineering at Pinger
No Mention of a Dedicated QA Team
"The reason why they were unsuccessful was that it needed a specialized team that would just maintain the test suite when features would change and this was not scalable."
When I joined the company, there had already been two unsuccessful automation programs. The reason why they were unsuccessful was that it needed a specialized team that would just maintain the test suite when features would change and this was not scalable. The tests would run after the feature was released, and the developers would not receive any feedback if something went wrong during the sprint. As a result, we needed to create a brand new team and augment the team as the number of tests increased. This was for a mobile application, which made the process even tricky.
How QA Engineers Can Add Value
"Instead of creating a brand new team, we had our automation team create a framework, write a few tests, and then train the QA engineers."
Instead of creating a brand new team, we had our automation team create a framework, write a few tests, and then train the QA engineers. My take on this was to write automated tests that the QA engineer could optimize while they would qualify each story. On top of that, my direction was to run the tests before the story was released and not after. For that, we used the Gherkin method to set up action validation. Instead of writing the automated test suite, my team of three developers wrote a framework and trained the QA engineers to write the automated test from the get-go.
This resulted in ample tests and enabled the QA engineers to correct them straight away as we changed the feature. The QA engineers were delighted to be a part of the process to delve deeper into the technology part. They owned the tests instead of another team; furthermore, they held the trials and ensured that the tests ran smoothly.
The brittleness of the test was managed by a collaboration between the QA engineers and the developers. Because the team who wrote the framework eventually ended up becoming a part of the cram team, they were not separate teams anymore, which brings us back to the quote "You work with a person, not for the person," by Elisabeth Hendrickson author of "Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing". In the end, we had better coverage of automation, ownership of the test, and everyone understood that it was impossible to make releases more seamlessly.
Once they started owning the framework, we gained two things:
- The collaboration between QA engineers and developers would make it show that it was more significant and understand at which level they could move with the test.
- We had lesser user acceptance tests and lower stack tests, which made our test suites less brittle and faster.
While all the tests were done manually, gradually, they moved into the automated process, with minimal speculation from the developers. Upon involving more developers to own the framework, they started doing more tests. The shift in the process made the tests faster, less brittle, and the code more robust. Our goal was to make the testing a part of engineering, not just QA, 一 which was quite successful by the end.
- Some teams will be more collaborative than others. It may take a lot of effort to start the collaboration, but once you have it, there are better possibilities.
- Whether you are building a new feature or rebuilding it, testing is an essential part of the process.
Be notified about next articles from Joëlle Gernez
Vice President, Engineering at Pinger
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.