QPM

Improvement of the QA & Testing skills of people

Instead of taking the activities, process, framework, etc. as the starting point for improvement, you can also take people as the starting point. In particular the mindset of the people. Obviously, a mindset is framework independent. So, you could work with an Agile mindset in all the Agile frameworks or even in a more traditional, or sequential, development environment. We define the Agile mindset as follows:

This people-oriented approach requires an effort of each person involved in designing, building, running and maintaining software to be transparent on how the person gives substance to six pre-defined Quality key areas [Sogeti 2020]: QA Awareness, QA & Testing, Governance, Transparency, Automation and Infrastructure. We call this approach Quality to People Mapping (QPM).

How does QPM work?

QPM is a team effort and demands participation of all the people involved. So, gather all people involved, which would be easy if you are DevOps and work in a communicative and collaborative manner. People will take on roles such as business analyst, software architect, designer, developer, operations engineer, tester, database administrator and so on in the group.

Note: These people – in any case, the roles – are always there, no matter which framework or software development approach is being used.

Let every participant fill in – in the QPM table – how they would add substance to the Quality key areas and request a quality architect to be the moderator of the QPM workshop as not all participants will be Quality experts. Given the simplicity of QPM, you will be able to implement it right away.

What does a QPM table look like?

A QPM table maps the quality key areas with various roles. At the intersections, the participants will mention the quality measures that they will apply. The result is a table that you can use to provide clarity (transparency) to everyone about how each participant will contribute to the quality of software development. According to this table, the team can hold a certain person responsible if the promised contribution is not made. Using the table, the team can take over a quality measure from a person if this person has not been able to carry out that specific quality measure. In the end, the whole team is responsible for delivering quality.

Which quality measures can be chosen? You can think of: INVEST, TDD, SbE, ATDD, BDD, pair programming, test design techniques, risk analysis, risk poker, MBTD, MBT, code quality and test automation tools, review techniques, DoD, DoR, DoS, WoW, and so on. For more about this we refer to, amongst others, "Tooling", "Quality risk analysis & test strategy", "Quality measures", "Reviewing (static testing)", and "There are many techniques, which one to use?".

To summarize, identify quality measures per role, measure the effects of applying these measures and define actions to improve – the application of – these quality measures per role. When the team reviews and revises this QPM table frequently, let's say once a month, the Quality & Testing skills of the people will improve continuously.

We have used this approach several times, perhaps not always as successful, but it has always made people think about quality, which is of utmost importance to us. After all, it is people who create valuable high-quality software.