Perhaps in no company will there be two identical and interchangeable employees. Some are well versed in test design techniques and write test documentation in jewelry, others are masters of various types and types of testing. In the process of working on projects, employees, as a rule, complement each other, which has a beneficial effect on the final product.
All our work on quality assurance is built on the basis of deep expertise of the applied field. For some teams it is insurance, for others - financial instruments, Internet banking or exchange trading, for others - a wide sector of government projects.
The secret is that testers should not just understand the application area, but should know its specifics and the most typical mistakes, moreover, they should understand their users.
That is why we devote so much time and effort to training and immersing our employees.
Excess documentation and dive issues
Agree, any project requires a certain time to immerse yourself in it. And it does not matter whether it is small or large, state or commercial, still, before becoming a full-fledged member of the project team, you will have to go through the path of becoming. So on one state project, where the testing team consisted of a little more than 50 people, we faced the need to integrate a new person with the introduction of a new person:
In the processes described in numerous regulations.
In a subject area that is covered in detail in many huge volumes of regulatory legal acts of the India.
Into the business logic of individual subsystems (and there are more than a hundred of them) and, no less importantly, in particular the interaction of these subsystems with each other.
In the technologies and tools used on the project: server "monitors", tools for working with logs, API (SOAP and REST), a huge database on PostgreSQL and so on.
What to do in such a situation? Especially if the employee has to come to the project, and in two weeks to show the "class"? How do I train him? No matter how much I would like to minimize my costs for this process and simply overwhelm the beginner with a ton of information in the hope that he himself will somehow figure it out and in two weeks he will not be distinguished from experienced fighters, you still need to choose a systematic approach.
What is a systematic approach?
1. Each "recruit" on the project is met by a voluminous document, which, telling about great prospects, now and then leads to the necessary documents and regulations necessary for the employee in the first days of his work. It is this document that replaces the very mentor of the first days, who takes by the hand and leads to important places of the project. And it frees up a lot of time for one simple reason: the document was created after analyzing numerous questions asked by previous beginners. Analysis is important!
2. It is very important that the employee understands not only how the product functions, but also its logic from a business point of view. And the whole business is described at the level of regulatory legal acts of the India, so we also had to teach employees the intricacies of jurisprudence! First, the employee was informed about the different organizational forms of enterprises in the India, and then smoothly moved to the subject area in the context of comparison "legislation - TK - visual functionality before the eyes", and at the end a control section was made with answers to such questions:
3. Next, the immersion proceeded to the stage of passing the regression checklist directly. An end-to-end business process that begins from the registration of the user and, having passed through dozens of key subsystems along the logical chain, ends in the form of a report or some final action like payment by the user. Thus, the immersive had the opportunity to get acquainted with the end-to-end key business processes and see how the main subsystems are integrated with each other.
4. Next, the subsequent stages for immersion were determined individually: who is weak in Soap UI, pull him up in it, others in SQL or Excel integration; system monitoring is weak - please pump the employee here. Each direction has its own sets of materials, its own controls. For example:
5. At this stage, the most interesting thing begins – the work. Despite the fact that all previous stages were also done on real data and in real conditions, at this stage personal responsibility for the quality of the test already comes. But at the same time, a mentor is assigned to the employee, who directs, pointing the way to the light.
This whole journey lasts two weeks, after which the employee demonstrates the acquired knowledge and achievements to the head of testing on the project and his test manager and mentor. Based on the results of the defense, a list of recommendations on those points that need to be improved is formed, and the final stage begins.
Finale. Three months later, the employee undergoes the last control - project certification, in which the independent manager of the testing subgroup conducts a survey in the following areas:
- regulated production processes;
- use of technologies and tools on the project;
- key business processes of the product;
- testing theory (yes, that's important to us too).
A small block from the database of questions:
The entire attestation is recorded and each answer is graded on an approved 5-point scale. Next, the average rating and recommendations for the necessary improvements are displayed. All this information is aggregated into the employee's profile and will be available to the testing management until the last day of the employee's stay on the project.
Dashboard of employee profiles:
Is that all? No.
Now, every quarter, this employee, like a number of others, will undergo a simplified certification according to the same scheme, confirming his qualifications to an independent line manager, and his profile will show the dynamics of growth of his qualifications.
How much time is spent on quarterly certifications? Frankly, not a little, but it is worth it, because after a year of work on the project, employees have a very high level of immersion in the business logic of the product, in technology, easily cope with complex technical tasks and competently approach the issue of applying test analysis and test design.
Lack or no information
On the project in the field of financial investments, we wisely approached the problem of lack of documentation and completely solved it. How? — We wrote extended test cases and coordinated them with the customer. At the start of the project, the team received an introduction from the customer: "At the moment we do not have any documentation, will you be able to test the system and document the current functionality in test cases?" Easy!".
To begin with, the team developed a template, which was later sent to the customer for approval. After discussing small incomprehensible details with the customer, we agreed on a template for future test cases and proceeded to describe the system.
We describe the implemented functionality in test cases, coordinate with the customer In the process of writing test cases, we found forecast calculators that show several values at the output (like a loan calculator). For testing and description in test cases, it was necessary to know which formulas are used to calculate the final values. However, at that time, the customer did not provide them to us. Some of the calculations were able to understand and describe independently. The rest - in detailed formulas received from the customer. As a result, all formulas were completely recorded in test cases. All test cases were written in the most detailed way, including all sorts of variants of boundary values, positive and negative testing.
Further, these test cases were transferred to the customer for verification and approval.
Approval of test cases was held almost without questions and comments. And soon we tested the product qualitatively.
We are not afraid to replace the team and cooperate with the analyst All new improvements we first describe in test cases, coordinate with the customer and only after that proceed to testing.
Why waste time on such a detailed description and why you need to write test cases before testing? The answers are simple:
We are not afraid that an experienced employee with deep expertise will get sick or quit.
At any time, you can completely replace the composition of the team, even with trainees (after passing the system on such test cases, they will understand both the system itself and the principles of testing, and, without having special knowledge, will apply them in the future).
Possible risks arising when writing a TK by different participants in the process are reduced.
All shortcomings in the documentation are identified even before the start of testing.
So, safely overcoming all the difficulties of diving into new projects, this month we were joined by 2 manual testing specialists, 4 automators, 1 Test Manager and 1 marketing fairy.
No comments:
Post a Comment