Introduction
Good afternoon, Hubrovians. I was recently working on a test assignment for the QA Lead position at 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 quite trivial.
It’s hard to come up with a better test plan that includes a complete checklist.
However, the second part raised the question: "Are there any common problems for all testers that hinder working more effectively?"
The first thing that came to mind was to list all the noticeable issues I encountered while testing, filter out the trivial ones, and generalize the rest. But I quickly realized that the inductive method would only address questions that pertain not to "everyone" but, at best, to "most" testers. Therefore, I decided to take a different approach, a deductive one, and here’s what I came up with.
Definitions
The first thing I usually do when tackling a new task is to try to understand what it’s about, and for that, I need to grasp the meaning of the words in which it’s presented. The key terms to discuss are as follows:
- issue
- tester
- the work of a tester
- the effectiveness of a tester's work
Let's turn to Wikipedia and common sense:
(from Ancient Greek πρόβλημα) in a broad sense - a complex theoretical or practical question requiring study and resolution; in science - a contradictory situation represented by opposing positions in the explanation of certain phenomena, objects, processes, and requiring an adequate theory for its resolution; in life, a problem is formulated in a way understandable to people as 'I know what, but I don’t know how', meaning it is known what needs to be achieved, but it is unknown how to do that. It derives from late Latin problēma, from Greek πρόβλημα 'something put forward, set in front'; from προβάλλω 'to throw forward, present in front of oneself; to accuse.'
There isn’t much meaning here; essentially, 'problem' = 'anything that needs to be resolved.'
— a specialist (we won't divide into types, as we're interested in all testers) who participates in testing a component or system, with the result of their activity being:
— a set of activities related to testing.
(from Latin effectivus) — the ratio between the achieved result and the resources used (:2015).
— a consequence of a chain (series) of actions (outcome) or events, expressed qualitatively or quantitatively. Possible results include advantage, inconvenience, benefit, loss, value, and victory.
As with the 'problem,' little meaning: something that resulted from the work done.
— a quantitatively measurable ability to perform some activity by a person or people; conditions allowing, through certain transformations, to achieve the desired result. A tester is a person, and according to the theory of vital resources, every person possesses four economic assets:
monetary resources (income) — a renewable resource;
energy (life force) — a partially renewable resource;
time — a fixed and fundamentally non-renewable resource;
knowledge (information) — a renewable resource; it is part of human capital that can both increase and diminish..
I want to note that the definition of effectiveness in our case is not entirely correct, since the more knowledge we use, the lower the effectiveness turns out to be. Therefore, I would redefine effectiveness as 'the ratio between the achieved result and the resources expended.' Then everything is correct: knowledge is not spent during work but reduces the costs of the only fundamentally non-renewable resource of the tester — their time.
Solution
So, we are looking for global problems faced by testers that decrease the effectiveness of their work.
The most significant resource consumed by a tester is their time (the others can be associated with it in one way or another), and to talk about a correct calculation of effectiveness, we must also relate the result to time.
To illustrate this, let's consider a system whose viability is ensured by the work of a tester. Such a system is a project that includes a tester in its team. The project life cycle can be roughly represented by the following algorithm:
- Working with Requirements
- Formulating the Technical Specification
- Development
- Testing
- Releasing to Production
- Support (goto p.1)
The entire project can be recursively broken down into subprojects (features), each with the same life cycle.
From the perspective of the project, its implementation efficiency is greater the less time is spent on it.
Thus, we arrive at a definition of the maximum possible efficiency of a tester from the project's point of view — this is a state of the project where the time for testing is equal to zero. And the common problem for all testers is the impossibility of reaching that time.
What can be done about this?
The conclusions are quite obvious and have long been utilized by many:
- Development and testing should begin and end almost simultaneously (this is usually handled by the department ). The ideal scenario is when all developed functionality is covered by automated tests at the time of readiness, 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 need to be spent checking that new functionality hasn't broken old functionality. Therefore, the more complex the project, the more automation is required for .
- Every time we miss a bug in production, and a user finds it, we have to spend additional time going through the project life cycle starting from p.1 (Working with requirements, in this case, users). Since the reasons for missing the bug are generally unknown, we have only one way to optimize — every bug found by users must be included in the regression testing to ensure that it does not reappear.
Source: habr.com
