In the beginning, a little bit about scrum Scrum is a set of rules for organizing a flexible workflow, which consists of a team approach, working in iterations, focusing on the goal of each iteration, and non—standard distribution of responsibilities within the team. The method came from the world of IT development and is now used in various business areas. Scrum work is based on "sprints" — these are periods lasting from 7 to 30 days, it all depends on the composition of the team and the project. For each sprint, they form their own goal, according to which they sum up the results. The next sprint begins after the completion of the previous one, regardless of its results — unless, of course, the sponsor decides to complete work on the product. The approach involves regular monitoring of work, which allows you to evaluate intermediate results. Thanks to Scrum, you can analyze whether the team is moving in the right direction and whether it is possible to solve problems with the least effort. The main feature of Scrum is flexibility. You can always make new ideas to the project or other necessary changes. The methodology allows you to gradually go to the desired result and check the effectiveness and value of the work done along the way. Not to be confused with Agile. These concepts are very similar, but Agile is a common philosophy and a set of values and principles implemented in the form of a family of flexible approaches to software development. Agile is based on four values and 12 principles, which are spelled out in the manifesto. Scrum is just one of the Agile approaches. It allows you to implement the 12 principles of Agile in practice. Scrum teams have the following roles: The product owner. Is responsible for maximizing the value of the product. This person knows exactly what needs to be implemented first. Scrum master. His task is to organize the work in the team in accordance with the Scrum guidelines so that no one interferes with the team to solve the tasks independently and comfortably. Developers. A group of people with all the knowledge and skills necessary to achieve the goal. QA. A group of people who ensure the quality of the released features, often this group of people is responsible for taking risks when publishing changes. QA also specializes in quality assurance for the entire product, not just features that were released within a certain sprint. Development lifecycle The flexible development model usually consists of 5 positions: Planning Development Testing Demonstration(optional) Integration Planning Let's imagine that the team works in n-week sprints, each sprint is focused on specific user stories. As part of sprint planning, the following processes take place: establishment, elaboration of tasks and stories, determination of priorities and severity of tasks, their evaluation. As a result, the tasks form releases that are added to the sprint and determine its goal. A QA engineer should be involved in planning since after this stage he can already start creating test cases/checklists for tasks. In the process, it is necessary to rely on functional requirements, this will become a good practice. The tools in this case are a bug tracker and a system for creating tests. Success criteria are correctly formulated requirements for the task and created test documentation. If the team has a QA Automation engineer, then at the sprint planning stage he can start tasks to cover the new functionality with autotests. Development After getting the task to work, the developer writes the code, commits the changes and pushes the branch into the version control system. Testing should start as early as possible (early testing saves time and money). In this case, the use of unit tests and integration tests will be a good testing practice. are unit or component tests aimed at checking individual modules of the system. Unit tests are often written by developers themselves. Unit tests are the testing of all the combined modules (components) of the system, as a result of which they are assembled together. After that, the modules are checked for errors in the code. Integration testing should be performed after modular testing using a CI/CD tool. Integration tests Testing It is necessary to determine the levels of testing that can be used in the project. Usually, it is: Unit or component testing. Integration testing. System testing. Types of testing that can be used in the project: Functional. Non-functional. Code access testing (white/black box). Testing with changes and exploratory testing. Therefore, we must build a testing pyramid, where the first and second stages will be developer tests (modular and integration), and the final one will be manual testing and automated end-to-end tests (testing with changes) within the framework of the system testing, run by QA engineers. Manual testing When the task has been tested, the QA engineer takes it for execution depending on the priority and creates a test case/checklist if there is no test documentation for the task. Depending on the description of the task, they apply functional/non-functional testing, code access testing. When compiling test documentation, the QA engineer should use suitable test design techniques. The QA engineer checks the task and, if there are no errors, prepares the release for regression testing. Or returns it to the developer for revision, having created the corresponding bug. Ad-hoc testing Research or ad-hoc testing is free–form testing aimed at finding bugs when a QA engineer applies an intuitive approach or accumulated knowledge about a product. Load testing Load testing is usually divided into: performance testing, that is, the response time of system requests. stability testing – checking the system at optimal load for a long time. stress testing is testing the system under maximum load with the achievement of a fall/failure. Such testing should be performed when releasing a new/modified system component that requires checking for performance, scalability, fault tolerance, the presence of bottlenecks in the code, memory leaks, and vulnerabilities in hardware configuration settings. Load testing should preferably be carried out on a remote machine in test infrastructure, using scripts in the appropriate program (I told you more about load testing here - , ). Vegeta GHZ End-To-End tests (regression testing) E2E tests are automated tests that test a test scenario from start to finish. There can be both API and UI tests. The QA Automation engineer should write the E2E tests in the team. It is better to start working immediately after planning, and to release tasks together or after product releases. QA Automation-an engineer takes a task to work depending on its priority. Having written the autotest, the QA Automation engineer must run his code using the CI/CD tool along with the rest of the tests of the affected module. Next, the engineer sends the task to review. If there are any comments, the code is corrected, the tests are run again using CI/CD, and the code is checked again and sent to the master by the responsible person. E2E tests or regression are run at the final stage of testing, before the release of the release in the prod, when manual testing has already been carried out. Regression tests are best done through a CI/CD tool. The criterion of success is passing all test scenarios. Integration Implementation or deployment is the final stage of the software lifecycle, usually performed by responsible persons. The scheme is as follows – a branch in the version control system containing release tasks is merged into the prod branch, a QA engineer checks the logs after deployment, conducts functional testing on the prod if possible, and interested parties receive the final result. If successful, the release and all tasks included in it are transferred to the "ready" status. If blocking or critical tasks are detected, the release is rolled back through the version control system. The implementation is completed. That's it! In this way, you can create a testing strategy for a Scrum project. Thank you for your time. Ruslan Muradov | Head of QA | UnaBank.
