It will not immediately ring a bell for everyone: “quality engineering”. It’s the new concept in achieving the right quality of IT systems. Testing an application only after the digital product has been fully developed has long been a thing of the past. But more is needed to guarantee the quality of applications that are delivered faster and more frequently in today’s high-performance IT delivery models. The road to quality engineering means changes in terms of starting points, skills, organization, automation and quality measures.
Quality engineering means a team together takes responsibility for the quality of the IT product. No longer a separate test team, isolated from software developers, works in modern IT delivery. Every DevOps team member contributes to quality. This way, the notorious silos of traditional IT delivery are being eradicated. At the same time, more collaboration and testing from the start of the development alone does not guarantee better and faster delivery of digital products. Achieving quality at speed requires a specific integrated approach as described below.
Team members today have a role instead of a function. That is an important precondition for genuinely taking joint responsibility for the quality of the product. For example, an operations person will also be able to perform test activities. And important is that nobody on the team has a monopoly on specific tasks. Why should the developer not be able to test if the login function is working? It is a matter of awareness. Reversely it is also important that testers understand programming. This makes it easier to give each other relevant feedback during the development and maintenance process. Typically, a development team consists of about seven people, who together have all knowledge and skills to properly perform any task.
From IT quality to business value
It is crucial to determine the value the software has for the organization and its customers. That is a completely different starting point than delivering the highest possible quality. For example, speed may be much more important than complete functionality. The app with which citizens have to register for a corona test had to be available quickly. So the stakeholders accept imperfections in the first releases. These can be adjusted in a future releases. As soon as people can register, the most important business value is achieved.
Many organizations previously implemented test competence centers. These detached teams are increasingly being phased out. The test center transforms to a facilitating department that helps DevOps teams by supplying and supporting test methods, testing tools and other relevant knowledge. And additionally, with end-to-end regression tests, a test competence center can provide confidence that the combined end product meets all acceptance criteria. Organizations can assess for themselves whether such confirmation offers added value. For instance based on quality risks.
Automation is not a goal in itself
“Automate everything!” Is often said. But beware. Before you decide to automate test processes, it must be clear what you want to know about quality and related risks. Define which indicators are needed to support establishing confidence in business value. Set up an environment in which you can properly measure these indicators. In this way you prevent automation from becoming a goal in itself, instead of contributing to, for example, speed, saving efforts, lower sensitivity to errors and / or the removal of boring work.
To keep quality a priority, the DevOps team applies a number of quality measures. For instance, pairing. Team members pair up to take care of the software development together. Working in pairs does not mean it will take more time, because with combined knowledge and skills results are achieved faster and better, and rework is prevented. The use of feature toggles is a technical quality measure with which software is easily switched on and off to ease the operations tasks in the team by disconnecting the deployment from the actual use of new features.
Quality engineering, applied in this way, becomes the way to achieve the right quality at the right time. Delivering the business value that stakeholders expect from the IT system at that time.
About Rik Marselis
Rik Marselis is principal quality consultant at Sogeti in the Netherlands. He has assisted many organizations in improving their IT-processes, in establishing their quality & testing approach, setting up their quality & test organization, and he acted as quality coach, qa-consultant, test manager and quality supervisor. Rik uses his more than 40 years of experience in systems development and quality and testing to bring fit for purpose solutions to our clients. He focuses at three major tasks: * Consultancy on Quality engineering & Testing in the broadest sense (quality & test policy, project startup, process improvement, coaching, second-opinions, etc…) * Develop and give training courses for both novice and experienced testers (Rik is an accredited trainer for TMAP, TPI and ISTQB certification training courses) * Research and development of the quality engineering & testing profession. Rik has contributed to over 20 books on quality and testing, of which 5 as an main author and 5 as project leader. His most recent book in the TMAP body of knowledge is “Quality for DevOps teams”. Rik is a much-appreciated keynote-speaker and workshop-host at conferences (he has presented at conferences in over 15 countries).
More on Rik Marselis.