Test automation by Scrum methodology
The use of Agile family of methodologies, the so-called flexible methodologies, in the field of IT is gaining momentum. This family, as you know, includes such methodologies as Kanban, XP, Scrum, and other, less well-known methodologies.
I recall the meaning of each of them according to ISTQB:
All of the above methodologies have one goal - to quickly deliver a quality product to the end user. These are all flexible methodologies. If using the waterfall model, the testing process is very simple and straightforward, because it is performed sequentially, after the completion of the active development phase, then Scrum is not so easy.
The team consists of PO (Product owner), Scrum Master and Developing Team, which in turn consists of 1 QA Automation, 1 Backend developer, 1 Frontend developer, 1 UX and 1 layout designer. Development is iterative, sprints for 2 weeks. During each sprint several types of meetings are held:
The process of performing the task is as follows:
What happens at the beginning of the sprint for the test automation and at the end of the sprint for the developer? After all, it would seem that at the beginning of the sprint there are still no completed tasks, and at the end of the sprint there are no more tasks left that would not be transferred to testing. And about the same thing happens, code optimization, refactoring, the introduction of new tools and the like.
As an example for the automator - the introduction of Allure reports, for the developer - the optimization of queries.
At the beginning of the test automation process, you must configure the CI in order to conduct regression testing automatically. The goal is to keep manual work to a minimum. Because there is no time for anything, you need to work quickly. After that, you should do the repository, set up the launch of the assembly by Merge request. If someone from the developers has sent something to the main branch of the project, the build starts and you can see from the results whether the changes are correct.
Before you start writing tests, you need to understand the main business idea of ​​the project in order to identify areas of high risk that are the first to be addressed. All the same, we will be realistic, completely cover the application with tests, even if it is small, it will not work. Sutherland wrote that there was never enough time to implement the whole Backlog, so he always applied the Pareto principle to Backlog. We write 20% of autotests covering 80% of possible defects.
When writing tests you need to achieve maximum abstraction. You should not write a function code that can be used only under certain conditions. It is much better to implement it in such a way as to reuse the code as much as possible by changing the input parameters.
Effective work in Scrum is impossible without close work with the developer, because there is little time for self-study of the code. Faster and better get the result if you receive information from the first mouth. How this or that functionality is implemented, which was used in this case. This is important for understanding the internal structure.
The automator, and in Scrum especially, must be technically savvy in order to understand how the application works so to speak “under the hood”. It is important to be able to quickly and easily move from one technology to another. For example, when changing a database, you need to be ready to change the way you connect to it. The technology stack should be as wide as possible.
Scrum involves a quick reaction to changes, urgent corrections. Assuming that users found some inconsistency in the application, the development team should respond and release the patch as soon as possible. To do this, it is important to be able to pinpoint the problem very precisely. Autotesting is very helpful in this. Suppose we have a three-level web application: there is a DB, frontend, backend. Somewhere in the application there is a bug. When using manual testing, the search for a problem may take more than one day, then the problem will need to be fixed and re-tested. When autotesting we run regression testing and within a couple of hours we get a full report reflecting the exact location of the bug.
I recall the meaning of each of them according to ISTQB:
- Kanban is a flexible Agile family methodology whose main goal is to visualize work flow, optimize it and reduce development time.
Distinctive features of Kanban are:
')- The presence of the Kanban Board is a board on which the states of various tasks related to specific types of activities are visible, for example, these tasks are at the stage of development or testing.
- Work-in-progress limit. This means that at each stage a certain number of tasks can be found on the Kanban Board. Taking a new task into development is possible only if one of the previous ones is completed. Also, if at one of the stages the tasks are over, those responsible for this stage may go to help accomplish the tasks at the previous stage.
- Lead Time. Each task has a fixed time between its creation and closure, which must be adhered to.
- The presence of the Kanban Board is a board on which the states of various tasks related to specific types of activities are visible, for example, these tasks are at the stage of development or testing.
- XP is an agile Agile family methodology, the main goal of which is to ensure high speed of writing code, as well as use basic programming practices in pairs, making an extensive review of the code, unit testing of the entire code, as well as achieving simplicity and clarity in the code. When using Scrum, the basic XP practices are often implemented.
- Scrum is a flexible Agile family methodology, a set of principles on which the development process is based, allowing in rigidly fixed and short-term iterations, called sprints, to provide the end user with working software with new features for which the highest priority is defined.
Distinctive features of Scrum are:- Product Increment - the team works in equal intervals of time, called sprints, for which it undertakes to develop, test and put into operation certain functionality of the application.
- Product Backlog, Sprint Backlog - application functionality is divided into tasks, which are prioritized in the list and executed in accordance with it.
- Definition of Done - upon completion of the work on the functionality, the pre-approved requirements, called Definition of Done, must be fulfilled. Requirements are set in advance and discussed by the whole team.
- Daily Stand Up Meeting is a daily meeting, the main purpose of which is to receive answers from each team member to 3 questions: “What did I do yesterday”, “What will I do today” and “What difficulties do I have”. This increases the visibility of the entire development process for the entire team.
All of the above methodologies have one goal - to quickly deliver a quality product to the end user. These are all flexible methodologies. If using the waterfall model, the testing process is very simple and straightforward, because it is performed sequentially, after the completion of the active development phase, then Scrum is not so easy.
And how is Scrum built with us?
The team consists of PO (Product owner), Scrum Master and Developing Team, which in turn consists of 1 QA Automation, 1 Backend developer, 1 Frontend developer, 1 UX and 1 layout designer. Development is iterative, sprints for 2 weeks. During each sprint several types of meetings are held:
- Planning - planning a sprint, a set of tasks for the next 2 weeks from the Backlog project.
- Backlog refinement - analysis of the Road map of the project, assessment of the tasks lying in the Backlog.
- Demo - show the results of the sprint, evaluation of the work performed, the decision about the success of the sprint.
- Retro - discussion of the positive and negative points of the sprint, the search for solutions necessary to eliminate the negative points.
- Daily meeting - a daily rally in order to see the situation on the project on behalf of each team member.
The process of performing the task is as follows:
- On the scheduling task gets into the backlog of the current sprint from the backlog project
- After it goes to the In dev status on the Scrum Board and the developers start to run
- The result of the task is poured into a separate feature branch in git
- The task moves from the status “In dev” to the status “In test“ on the Scrum Board
- The result is poured on the test stand and tested.
- Implemented autotests for the task
- After this, the written autotests and the implemented functionality are sent to the main branch of the project in Git - to develop
- When all tasks are completed and covered by autotests, they are assembled on the CI. If the build is successful (all unit and autotests passed), the application is automatically rolled out to the internal demo stand for the demo.
- If the result of the sprint is accepted successfully - the assembly is rolled out on the industrial server.
What happens at the beginning of the sprint for the test automation and at the end of the sprint for the developer? After all, it would seem that at the beginning of the sprint there are still no completed tasks, and at the end of the sprint there are no more tasks left that would not be transferred to testing. And about the same thing happens, code optimization, refactoring, the introduction of new tools and the like.
As an example for the automator - the introduction of Allure reports, for the developer - the optimization of queries.
Scrum Testing
At the beginning of the test automation process, you must configure the CI in order to conduct regression testing automatically. The goal is to keep manual work to a minimum. Because there is no time for anything, you need to work quickly. After that, you should do the repository, set up the launch of the assembly by Merge request. If someone from the developers has sent something to the main branch of the project, the build starts and you can see from the results whether the changes are correct.
Before you start writing tests, you need to understand the main business idea of ​​the project in order to identify areas of high risk that are the first to be addressed. All the same, we will be realistic, completely cover the application with tests, even if it is small, it will not work. Sutherland wrote that there was never enough time to implement the whole Backlog, so he always applied the Pareto principle to Backlog. We write 20% of autotests covering 80% of possible defects.
When writing tests you need to achieve maximum abstraction. You should not write a function code that can be used only under certain conditions. It is much better to implement it in such a way as to reuse the code as much as possible by changing the input parameters.
Effective work in Scrum is impossible without close work with the developer, because there is little time for self-study of the code. Faster and better get the result if you receive information from the first mouth. How this or that functionality is implemented, which was used in this case. This is important for understanding the internal structure.
Required qualities of test automation
The automator, and in Scrum especially, must be technically savvy in order to understand how the application works so to speak “under the hood”. It is important to be able to quickly and easily move from one technology to another. For example, when changing a database, you need to be ready to change the way you connect to it. The technology stack should be as wide as possible.
Scrum involves a quick reaction to changes, urgent corrections. Assuming that users found some inconsistency in the application, the development team should respond and release the patch as soon as possible. To do this, it is important to be able to pinpoint the problem very precisely. Autotesting is very helpful in this. Suppose we have a three-level web application: there is a DB, frontend, backend. Somewhere in the application there is a bug. When using manual testing, the search for a problem may take more than one day, then the problem will need to be fixed and re-tested. When autotesting we run regression testing and within a couple of hours we get a full report reflecting the exact location of the bug.
Source: https://habr.com/ru/post/317916/
All Articles