Test Maturity Model: how a tester can evaluate a project and plan processes
Hello! My name is Misha, and I am a Senior QA with commercial experience of over 6 years. Now I work at Provectus, but I started my way as a tester back in my student days with participation in alpha and beta tests of various games. At one point, I thought: “Why not start doing this professionally?”. And off we go. During this time I managed to participate in various projects: from start-ups to enterprises, from small training unit games to huge applications with the strongest business logic.
But often I was introduced into small teams, in which there were from 5 developers for 1-2 testers and, as a rule, a lot of heat in the project. Actually, about how to learn to understand where you find yourself and how to begin to advance in the formulation of QA-processes, I want to share with you.
Having accumulated experience from participation in projects, I would conditionally divide them into 3 types:
')
At the time of my involvement, each of them was at his own stage of development. I began to observe these situations and began to develop my vision - how to promote testing processes on them. After some time I stumbled upon the Maturity Model, and she lay one on one at my work. This strengthened my belief that this is the place to be.
And here I am very cleverly insert a quote from Wikipedia :
In short and simple, this is a set of models that show how well the processes in an organization are organized according to certain criteria. Having a similar assessment, it is possible to soberly assess whether it is worth giving one or another order to one or another contractor.
Actually, the development of the Maturity Model began with this. In the 1980s, the US Department of Defense realized that it could not accurately assess the quality of the work of software contractors. And since this state structure is also of such a level, this is unacceptable. Money is state, deadlines are clearly delineated, and reliable software for weapons will allow everyone to sleep more easily. Based on this, the ministry commissioned the Software Engineering Institute to create a similar evaluation system and the first questionnaire was created a year later, and the first version of the model was created 4 years later.
These are 5 levels, within the framework of which the work / reliability / stability of the enterprise is evaluated.
Testers have their own special MM, it is called TMMi. It also contains 5 levels, on which I would like to dwell in more detail and consider what is characteristic of each of them.
The first level - "Initial"
At the first level, testing is not structured and chaotic. There is no stable environment to support testing processes. The team does not pay attention to planning and standards.
The main goal is to deliver the product on time without critical problems, because testing is used here only to show that the application is working without major failures. Often, the success of such projects depends solely on the heroism and skills of individual people, and not on established processes.
As a result:
Second level - “repeatable”
At the second level, testing becomes a manageable process. Discipline and progress achieved ensures that these practices are maintained during times of stress. Testing is still considered the activity that follows the development. Test plans are being developed and implemented, with the help of which they clearly define what testing is needed, when and by whom.
The main goal is to make sure that the product meets the specified requirements.
As a result:
The third level - "Defined"
At the third level, testing is no longer regarded as activity following the programming. Testing is fully integrated into the project. Testing planning is carried out at earlier stages and is fixed in the master plan. Non-functional testing is being implemented (for example, usability).
As a result:
The fourth level - "Measured"
At the fourth level, testing is a well-defined, well-established and measurable process. Testing is perceived as an assessment and consists of all operations of the software development life cycle. The practice of measuring the quality of testing is being introduced. These measurements are used to predict performance and cost of testing.
As a result:
Fifth level - "Innovation"
At the fifth level, all approaches and processes are well established. The team does not stop at this stage, but continues to systematically improve processes, constantly trying to reduce the time of the test cycle and time-to-market without reducing the quality of the project. Testing is focused on preventiveness. Automation is added for more efficient use of resources.
As a result:
Case number 1. Unfair testing
Once I got on a small project, where testing was conducted by the customer, his friends or the cat. Assessing the situation and looking at the model, we can understand that we are at level number 1 and we should focus on level number 2 while planning activities. After putting Jira in order, where there was a huge number of bugs (of which most are duplicates or not replicable), I started writing test documentation in the form of checklists and setting up basic testing processes. Such as regression testing and sanity testing during major changes.
Case number 2. Without testing
In my opinion, projects of this type can be in three cases:
Once on any of these projects, you can often see the benefit of the fact that he is at a secret zero level. We can jump over the first level and immediately do everything qualitatively with a sensible-sense-arrangement, guided by the goals of the second. Often we can implement test plans on the basis of which all necessary types of testing will be performed. You can immediately identify the same workflow with the development team, which is not enough for projects from the first case.
Case number 3. Testing was
In truth, the most rare case: a person due to certain events, decided to change the team / department / work and gives you his work. In such a situation, you already have an established system of interaction with developers, a certain base of test documentation. Further development paths can be either improvement of the established process, or advancement to the third level - implement testing at earlier stages or add non-functional testing.
Case number 4. Three in one
When I came to my project in Provectus, I was faced with a situation in which there were only a little of the three cases described above. As in case number 1, the first step was to tidy up the Jira. As in the second case, it was decided to do everything at once qualitatively in order to immediately be guided by the second level. Therefore, I immediately began to develop test documentation and implement test management tools. I also tried to squeeze the maximum out of the artifacts of past iterations, as was the case in the third case.
After a very short time, I can safely say that we are already deliberately moving to the third level - we even connected testing at the business requirements stage :)
In my experience, most Ukrainian projects, as well as projects that are not designed for the long term, successfully manage to bring to “Go live” at level 3. But if you have a long-term project, the possibilities to improve it are endless and you can safely be guided by the best practices of the highest levels.
In conclusion, I would like to say that the purpose of this article was to show not so much how to work with the most classical MM or TMM, but that with its help you can clearly understand at what stage the project you are on, and which movements to take and which should not. Moreover, taking its principles as a basis, you can create your own model, which can be applied not only in development, but also in various spheres of life. And most importantly - it is tested and works :)
But often I was introduced into small teams, in which there were from 5 developers for 1-2 testers and, as a rule, a lot of heat in the project. Actually, about how to learn to understand where you find yourself and how to begin to advance in the formulation of QA-processes, I want to share with you.
First of all you should understand which project you are on.
Having accumulated experience from participation in projects, I would conditionally divide them into 3 types:
')
- projects without testing;
- projects with unfair testing;
- projects with testing.
At the time of my involvement, each of them was at his own stage of development. I began to observe these situations and began to develop my vision - how to promote testing processes on them. After some time I stumbled upon the Maturity Model, and she lay one on one at my work. This strengthened my belief that this is the place to be.
What is Maturity Model
And here I am very cleverly insert a quote from Wikipedia :
Capability Maturity Model Integration (CMMI) - a set of models (methodologies) for improving processes in organizations of different sizes and activities. CMMI contains a set of recommendations in the form of practices, the implementation of which, according to the developers of the model, allows to realize the goals necessary for the full implementation of certain areas of activity.
In short and simple, this is a set of models that show how well the processes in an organization are organized according to certain criteria. Having a similar assessment, it is possible to soberly assess whether it is worth giving one or another order to one or another contractor.
Actually, the development of the Maturity Model began with this. In the 1980s, the US Department of Defense realized that it could not accurately assess the quality of the work of software contractors. And since this state structure is also of such a level, this is unacceptable. Money is state, deadlines are clearly delineated, and reliable software for weapons will allow everyone to sleep more easily. Based on this, the ministry commissioned the Software Engineering Institute to create a similar evaluation system and the first questionnaire was created a year later, and the first version of the model was created 4 years later.
Maturity Model Levels
These are 5 levels, within the framework of which the work / reliability / stability of the enterprise is evaluated.
Where in Maturity Model testing
Testers have their own special MM, it is called TMMi. It also contains 5 levels, on which I would like to dwell in more detail and consider what is characteristic of each of them.
The first level - "Initial"
At the first level, testing is not structured and chaotic. There is no stable environment to support testing processes. The team does not pay attention to planning and standards.
The main goal is to deliver the product on time without critical problems, because testing is used here only to show that the application is working without major failures. Often, the success of such projects depends solely on the heroism and skills of individual people, and not on established processes.
As a result:
- no test documentation;
- the product is unstable;
- rejection of processes during problem situations;
- testing is nothing more than debugging assistance.
Second level - “repeatable”
At the second level, testing becomes a manageable process. Discipline and progress achieved ensures that these practices are maintained during times of stress. Testing is still considered the activity that follows the development. Test plans are being developed and implemented, with the help of which they clearly define what testing is needed, when and by whom.
The main goal is to make sure that the product meets the specified requirements.
As a result:
- there are basic types and types of testing (integration, modular, regression, acceptance);
- test plans introduced;
- test activities are monitored and controlled;
- The process is documented and can be repeated.
The third level - "Defined"
At the third level, testing is no longer regarded as activity following the programming. Testing is fully integrated into the project. Testing planning is carried out at earlier stages and is fixed in the master plan. Non-functional testing is being implemented (for example, usability).
As a result:
- testing begins with the requirements stage;
- activities are added that allow you to work more efficiently (internal training, additional reviews);
- non-functional testing is being introduced.
The fourth level - "Measured"
At the fourth level, testing is a well-defined, well-established and measurable process. Testing is perceived as an assessment and consists of all operations of the software development life cycle. The practice of measuring the quality of testing is being introduced. These measurements are used to predict performance and cost of testing.
As a result:
- testing as a measurable process;
- measurements are used to predict;
- the team is looking for ways to make the testing process more efficient.
Fifth level - "Innovation"
At the fifth level, all approaches and processes are well established. The team does not stop at this stage, but continues to systematically improve processes, constantly trying to reduce the time of the test cycle and time-to-market without reducing the quality of the project. Testing is focused on preventiveness. Automation is added for more efficient use of resources.
As a result:
- continued process improvement;
- focus on prevention and optimization.
How does knowledge of this structure help?
Case number 1. Unfair testing
Once I got on a small project, where testing was conducted by the customer, his friends or the cat. Assessing the situation and looking at the model, we can understand that we are at level number 1 and we should focus on level number 2 while planning activities. After putting Jira in order, where there was a huge number of bugs (of which most are duplicates or not replicable), I started writing test documentation in the form of checklists and setting up basic testing processes. Such as regression testing and sanity testing during major changes.
Case number 2. Without testing
In my opinion, projects of this type can be in three cases:
- the project is just starting;
- there was no need for a tester on the project as long as there was a small functionality;
- The full-stack command has closed the shortage of testers with the help of high-quality code-review and dev-testing.
Once on any of these projects, you can often see the benefit of the fact that he is at a secret zero level. We can jump over the first level and immediately do everything qualitatively with a sensible-sense-arrangement, guided by the goals of the second. Often we can implement test plans on the basis of which all necessary types of testing will be performed. You can immediately identify the same workflow with the development team, which is not enough for projects from the first case.
Case number 3. Testing was
In truth, the most rare case: a person due to certain events, decided to change the team / department / work and gives you his work. In such a situation, you already have an established system of interaction with developers, a certain base of test documentation. Further development paths can be either improvement of the established process, or advancement to the third level - implement testing at earlier stages or add non-functional testing.
Case number 4. Three in one
When I came to my project in Provectus, I was faced with a situation in which there were only a little of the three cases described above. As in case number 1, the first step was to tidy up the Jira. As in the second case, it was decided to do everything at once qualitatively in order to immediately be guided by the second level. Therefore, I immediately began to develop test documentation and implement test management tools. I also tried to squeeze the maximum out of the artifacts of past iterations, as was the case in the third case.
After a very short time, I can safely say that we are already deliberately moving to the third level - we even connected testing at the business requirements stage :)
findings
In my experience, most Ukrainian projects, as well as projects that are not designed for the long term, successfully manage to bring to “Go live” at level 3. But if you have a long-term project, the possibilities to improve it are endless and you can safely be guided by the best practices of the highest levels.
In conclusion, I would like to say that the purpose of this article was to show not so much how to work with the most classical MM or TMM, but that with its help you can clearly understand at what stage the project you are on, and which movements to take and which should not. Moreover, taking its principles as a basis, you can create your own model, which can be applied not only in development, but also in various spheres of life. And most importantly - it is tested and works :)
Source: https://habr.com/ru/post/448458/
All Articles