Testing team in Scrum project

We have four Scrum teams in our department. Sprints, time boxing, rallies, demo, Product Owner, customer, etc. Over the years, a list of core values ​​has been formulated:

• team spirit and atmosphere in teams - the convenience of the processes is more important than the rules and habits that have developed over the years;
• automation of the routine is more important than mass pushing;
• quick decision making is more important than consultations, collegiums, long meetings;
• trust in people, the ability to learn (and make mistakes!) is more important than the centralization of management;
• openness to all (from top management to a specific project participant) and involvement is more important than momentary saving of time and visibility of consent;
• democracy in the discussion of issues, but the dictatorship in the implementation of decisions in life;
• the necessary minimum of rules, but exactingness in their execution;
• when everyone thinks the same way - no one thinks;
• “The man said - the man did,” everyone is responsible for their decisions.

Everything is good, but for several years we did not let go of the thought of how to organize testing. We experimented a lot before we came to the current state of affairs.

At first we tried to test by the developers themselves. So that the developers did not just write unit tests, but fully worked as testers - they checked complex cases and tested them with their hands. Frankly, testers from developers are not very. Testing your code is a torment: “It works anyway, I just wrote it.”
Tried to include testers in development teams. It brings together developers and testers, makes them understand each other’s problems. Sometimes it brings so close that the tester becomes another developer in the team, and the developer, as I said above, is already a bad tester. But there is a positive point - the developers are beginning to think about how to test the product.
We tried to involve testing teams external to the project (there is a separate testing department that does not participate in the project). They explained to the members of the external team for a long time what and how, they deployed the infrastructure, they explained for a long time what we need from them. Spent a lot of time, and did not get much profit.
As a result, the idea of ​​what we, in fact, need to organize testing, appeared.

Permanent testing team

We needed exactly the team - well-developed people who knew each other, trusted each other, and had similar knowledge and skills. A team that, in addition to testing itself, could develop technologies and develop itself. Now we have such a dedicated team of 7 people.
Initially they wanted to get a team of generalists who can do everything. But the wagon, as a rule, knows vast areas, but superficially. And I wanted to immersion in the area was great. As a result, this idea was abandoned and two directions were singled out: functional and automated testing.
Functional testing is basic for all testers. This includes highlighting requirements, designing tests, and directly implementing them. Functional testing, in turn, is divided into testing of the basic functionality and testing of applied logic.
Automated testing involves the automation of manual tests, the organization of specialized types of testing.
Testers who are assigned to any one area, can go deep there, it improves the quality of testing.
')

Maximum focus on automation

Automatic deployment, automatic test run, imitation of real user actions, automatic fixation of results, reasons for trailed tests, environment.
Now we have about 800 GUI tests that cover the lion’s share of the system’s functionality. They start without any participation of the tester. The environment is automatically raised, the data necessary for testing are automatically created, the tests are automatically run.


Table of automatic test run
(oops, it looks like someone piled the last run)

Tests work through the API and UI. The API is used to prepare some test data, while testing via the UI allows you to check real-life user scenarios.
In addition to the tests themselves, we automatically remove non-functional system performance indicators: the execution time of operations, the number of requests between the server and the client, and the traffic. The measured characteristics are available to everyone on the project in the form of graphs in dynamics.


Traffic schedules and operation times

Testing Confidence

At any time, we can ask the testing team what state the product is in. Testing team on the basis of running automatic tests, express testing can quickly answer whether it is possible to put the product in production, and if not, then why.
This opinion we trust. We know that if the testing team gave the go-ahead, we won’t get critical production errors. We know that the team forbids us to release a version for a reason, but because there is a reason.

Conducting specialized testing

First of all, we are talking about load testing. All other species are somehow covered by it. Tools for such testing are quite expensive. We wrote our tool to carry out various types of special testing.
The main task of the utility is to simulate the work of many users in the system. You can write different scenarios of user work with minimal time and effort.

Utility to simulate user actions

Testing the completeness, convenience of functionality

Testers can not verify that the very idea, the idea of ​​the product is correct, that it was necessary to do this way and not otherwise. We close this problem with corridor testing, but this is a separate topic of a separate article ...
However, testers can easily verify that the functionality is convenient to use. It often happens that the requirements for the functionality were formally met, but the user simply tries to use the product.
Convenience in this case is not only the user interface. This is an external API, and the ability to quickly and efficiently implement the tasks with the help of the system.

Closest to developers

The convergence of testers and developers allows you to get a test result earlier. If the bugs reach the developer in a week, then he needs to dive into the code again, delve into it again, and if in a day, it’s easier to remember what you wrote yesterday.
The developers are trying to give features in parts that can be tested directly during the sprint, they tell what is ready now and what else is under construction. This allows you to quickly begin to test and find problems on the still raw functionality.

Graphs of the duration of development and testing;
the second option reduces the term by 1/4

The idea of ​​a dedicated testing team fits well into the basic principles of our work. The team has been working on projects for 3 years and has shown its effectiveness.
We found the option seems optimal. But maybe you can tell how you organized testing in your Scrum projects, do you have a dedicated department or testing group, if not, why did you refuse?