Introduction
Good afternoon, Khabrovites. I solved here just now a test task for a QA Lead vacancy for a fintech company. The first task, to create a test plan with a complete checklist and examples of test cases for testing an electric kettle, is trivially solved:
It’s hard to come up with a better test plan with a complete checklist.
But the second part turned out to be a question: “Are there any problems common to all testers that prevent them from working more efficiently?”.
The first thing that came to mind was to list all the more or less noticeable problems that I encountered during testing, weed out small things, and summarize the rest. But I quickly realized that the inductive method would answer a question that does not apply to “all”, but, at best, only to “most” testers. Therefore, I decided to approach from the other side, deductive, and that's what happened.
define
The first thing I usually do when solving a new problem is to try to understand what it is about, and for this I need to understand the meaning of the words with which it is posed. The key words to understand are:
- problem
- tester
- tester work
- tester performance
Let's turn to Wikipedia and common sense:
(ancient Greek πρόβλημα) in a broad sense - a complex theoretical or practical issue that requires study, resolution; in science - a contradictory situation, acting in the form of opposite positions in the explanation of any phenomena, objects, processes and requiring an adequate theory to resolve it; in life, the problem is formulated in a way that people understand, “I know what, I don’t know how”, that is, we know what needs to be obtained, but it is not known how to do it. Comes from late. lat. problēma, from Greek. πρόβλημα "thrown forward, placed in front"; from προβάλλω “throw forward, put in front of you; blame".
There is not much sense, in fact, “problem” = “anything that needs to be dealt with”.
- a specialist (we will not divide into types, since we are interested in all testers), who takes part in testing a component or system, the result of which is:
- a set of activities related to testing.
(lat. effectivus) - the ratio between the result achieved and the resources used (: 2015).
- a consequence of a chain (sequence) of actions (outcome) or events expressed qualitatively or quantitatively. Possible outcomes include advantage, inconvenience, gain, loss, value, and victory.
As with the “problem”, there is little sense: something that turned out as a result of the work.
- the quantitatively measurable ability to perform any activity of a person or people; conditions that allow, with the help of certain transformations, to obtain the desired result. The tester is a person, and in accordance with the theory of vital resources, each person is the owner of four economic assets:
cash (income) is a renewable resource;
energy (life force) - a partially renewable resource;
time is a fixed and fundamentally non-renewable resource;
knowledge (information) is a renewable resource, it is a part of human capital that can both grow and collapse.
I want to note that the definition of efficiency in our case is not entirely correct, since the more knowledge we use, the lower the efficiency. Therefore, I would redefine efficiency as “the ratio between the result achieved and the resources expended”. Then everything is correct: knowledge is not wasted during work, but it reduces the costs of the only fundamentally non-renewable resource of the tester - his time.
Solution
So, we are looking for global problems of testers that worsen the efficiency of their work.
The most significant resource that is spent on the work of a tester is his time (the rest can be brought to it one way or another), and in order for us to talk about the correct calculation of efficiency, we must also bring the result to time.
To do this, consider a system whose viability is ensured by the tester with his work. Such a system is a project whose team includes a tester. The life cycle of a project can be roughly represented by the following algorithm:
- Working with requirements
- Formation of terms of reference
- Development
- The test is
- Release to production
- Support (goto p.1)
In this case, the entire project can be recursively divided into subprojects (features), with the same life cycle.
From the point of view of the project, the effectiveness of its implementation is greater, the less time spent on it.
Thus, we come to the definition of the maximum possible efficiency of the tester from the point of view of the project - this is the state of the project when the time for testing is zero. A common problem for all testers is the impossibility of reaching this time.
How to deal with this?
The conclusions are quite obvious and have been used by many for a long time:
- Development and testing should start and end at almost the same time (this is usually done by the ). The ideal option is when all the functionality being developed is already covered by autotests by the time it is ready, organized into regression (and, if possible, pre-commit) testing using some .
- The more features in the project (the more complex it is), the more time will have to be spent on checking that the new functionality does not break the old one. Hence, the more complex the project, the more automation is required. .
- Every time we release a bug into production and the user finds it, we have to spend extra time going through the project life cycle starting from point 1 (Working with requirements, in this case, users). Since the reasons for skipping a bug are generally unknown, we are left with only one optimization path - each bug found by users should be included in regression testing to make sure that it does not appear again.
Source: habr.com