Almost every organisation is looking for a new or other way to develop software or is already doing it. ‘Agile’, ‘Scrum’, ‘Kanban‘, ‘DevOps’ are words that are used a lot nowadays.
We noticed that many organisations have different reasons for what drives them to transform their way of working. In the financial sector for example, they strive to reach a higher level of quality from their software products and to avoid as much risks as possible. In the telecom sector they want to shorten their time to market (TTM) and are willing to take more risks to achieve it.
Both reasons are good, but they have their disadvantages. Avoiding as many risks as almost possible results in a development process that is slower than necessary.
Achieving a shorter TTM often results in a development process where QA is easily overlooked. Eventually resulting in a descending level of confidence with various stakeholders.
This raises the question if you can realise a shorter TTM and a higher level of quality at the same time. In our opinion this is certainly possible, but the right balance is essential. With the right balance we mean that QA should be a part of the development process from the very beginning and the right, most essential risks should be covered in this process.
Quality Analysis
To make this all possible it is important that your team is well composed. It should contain T-shaped professionals with different expertise. QA is one of those expertise. Not in the traditional way as a quality gate at the end of the development process but as a involved team member right from the start. So the role of the traditional tester has changed. In the new way of working you should be able to assess requirements, for example User Stories. Additional to that you should have same understanding of code and coding. I.e. you should be able to read and understand some simple pieces of code. This is what makes you T-shaped team member.
It is not always necessary to be a complete tool expert but you should be able to explain to technical members of your team what you want to accomplish with the team. Especially when your team is working on a larger product, automation is indispensable. Because you frequently release code as an agile team regression testing is very important. This can’t be done manually, because it would take way too much time. So as a team you will have to automate this. You should make a balanced set of unit, integration and GUI tests to make sure your application remains working properly.
If you have your development and deployment well aligned to each other and a quality minded team you can maintain a high velocity without losing grip on quality. This can even accelerate your TTM. But it requires commitment of the whole team, maybe even the whole organisation. There should be an understanding that quality is not only a testers responsibility, but a concern of the whole team. It is part of the whole development cycle.
Co-Author: Niek van Malsen:
Is a Senior Agile Test Specialist and Scrum Master at Sogeti in The Netherlands. In his (testing) career he gained experience at multiple organisations in different roles. He has been a member of different Scrum teams and his expertise and experience lies in the area of test automation, continuous delivery and process improvement .
