Structuring Quality Assurance Team

It is quite shocking to see people talking about separate Test Automation and Manual Testing teams in the era of DevOps culture. On one side we are talking about removing the silos and enabling collaboration but on the other side, we are trying to break down a single function into two silos. Of course, the decision to break down testing teams into groups had a reason in the past, let's briefly discuss the reason and discuss how this can be eliminated today.

Profitability is important for every company, and one major pillar of this is controlling the costs. From human resources perspective, we need to ensure the pay grade of a position matches the complexity of the tasks handled by the position. In the Quality Assurance function, we have two main tasks: Writing / executing manual tests and writing automated tests which will be executed by machines. The first task ( manual testing ) can even be carried over by power users of an application with some training on testing topics, however, the latter is actually software development which requires extensive knowledge of coding. Based on this breakdown, utilizing a single team will either not be possible ( power users can not code ) or not feasible ( software developers are too expensive to write manual tests ).

But DevOps is all about breaking the silos down and enabling each team to contribute, so how can we apply this culture to our traditional testing problem?

We already figured out having coding skills for the manual testing team is too costly and also not solving the problem at scale ( we want business analysts and product managers to contribute when/if necessary ), so we need to approach from the other side of the equation which is to make manual tests automated by default. Sounds strange right? Actually not, what we need is a way to execute tests written in plain English automatically. Luckily enough there is already a solution for this problem.

Gherkin is a DSL ( Domain Specific Language ) introduced in Cucumber which is a tool for BDD (Behaviour Driven Development ) by SmartBear. This language was designed to be non-technical and human-readable, so everyone can easily learn and write tests within that language. Same tests can also be interpreted by a test automation solution to execute automatically.

The way to adopt this approach starts with generating a sentence dictionary for the company based on the actions needed in the tests. This will serve as a contract with the test writers ( Manual QA team and everybody else who contributes ) and the test automation team. The sentences you will define varies between simple operations like "I open a web page" or "I click a button" and complex operations specific to your product like "I reset the web application cache". You will notice the sentence dictionary matures quite fast. Even though there will be hundreds of tests written, it will contain a bunch of sentences in different combinations.

Eventually, you will only need a core test automation team who is tasked to automate new sentences that occasionally pop up based on new needs and maintain the test automation platform. The big chunk of the work which is test writing and manual test execution can be done by the rest of the engineering team.