Everyone is talking about DevOps but what about QA? I tend to call it DevQA as we are now working so closely together with the development team that manual testing is mainly limited to exploratory testing. The developers are in charge of the quality and we are assisting them in all steps and supporting them with test automation, code reviews or also pair testing. For me DevQA describes our way from Quality Control to Quality Assistance.

QUALITY CONTROL

When I started as tester more than 3 years ago we didn’t had any QA processes. So this was a learning process for me as well as the team and everything started with simply testing what was provided by our developers. There wasn’t much documentation about features or a real design process.

Our first test process included a lot of testing at the end of the development cycle when the builds were handed over to QA. I should mention that back then QA was sitting completely separated from the development in its own office and it was common that we had to deal with multiple projects at the same time. We were busy writing test cases (in Excel), creating test plans and executing them as well as composing extensive test reports.

QUALITY ASSURANCE

As a first step we decided to move closer to the development teams so every team got a dedicated tester sitting in the same office. This enhanced the communication a lot and the process started to change. Step by step QA got involved more and more in the development process. Discussing features while they are being implemented and giving feedback directly during implementation.

QA got it’s dedicated place in the JIRA workflows and started to review design documents. At the same time we were evaluating the first frameworks for test automation which should become part of our daily routine as well. We started easy by just using Selenium and Sikuli for a couple of projects, but instead of following the traditional approach of automating module by module we started by automating bugs and most critical feature such as login and registration. More on that in “Getting Started with Automation“.

Now we were able to provide valuable input during any part of the development process, even our release management process got some love. This worked pretty well for some time till we realized that developers tend to push their stuff to QA and let them do all the testing. In the end we played a lot of times real ping pong with the features passing the forth and back between tester and developer.

QUALITY ASSISTANCE

It was a change in my mindsight which sparked the idea of quality assistance later on. Instead of complaining the team needs to change I asked myself what can I do to support the developers to take up more responsibility for quality again. I have to say it wasn’t an easy task and we also had a lot of throwbacks but it is totally worth it to go down this road.

What worked best from my side was curiosity about what the developers are doing so I took a look on the code reviews and asked questions here and there about different functions in the code. Also when we encountered bugs it was appreciated to sit together with the developer and try to understand it together. Developers are usually proud about what they are doing and they are eager to explain stuff to people who are really interested in it. But QA was still the gatekeeper.

After a while I noticed that the developers were trying to test their code more but they often got lost in what and how to test. It is important trying to sense this and be sensitive when approaching the developer. Don’t blame for missing knowledge and don’t make it too obvious, try to give small hints here and there which will point the developers in the right direction. If a certain point is reached they will approach you and asking for help. Now you can also give some workshops, share your insights on the project, on testing, on our way to think.

Following this road the respect and collaboration between developers and testers will grow and one time you can also do the final step to introduce Quality Assistance to the whole team as a vision.