Covering the requirements of cases. The realities of SuperJob
I decided to write an article about the process of interaction between our testers and analysts and the bonuses that SuperJob receives from this process.
The work of the testers with the requirements consists of three stages: the FT Review, the FT Coverage, the Case Review.
The FT Review
Requirements are conducted by analysts in Enterprise Architect, from there they are copied to Confluence. After writing the requirements, they are sent to review testers.
While this interaction is conducted through Google Sheets, where there is:
The name of FT
Reference to FT
Responsible for FT analyst
Statuses from analysts 3-333215.
Statuses from testers
The analyst to the corresponding item of the table puts down the status “On Review”: 3-333222.
At this stage, as part of Confluence, questions are asked on certain points of the requirements, since the functionality allows you to add comments to arbitrary parts of the text. In the comments there are discussions, according to the results of which the FT is updated.
After the requirements have been added and updated, they are transferred to the development and testing.
Test cases are written in TestRail, the test case storage architecture repeats the requirements storage architecture. This is necessary for ease of searching, and in order not to reinvent your own bike - it's easier to take it from an analyst neighbor.
Testing covers requirements - each item of requirements is covered, each offer.
Each item of requirements is numbered, there is a trace of test cases for items of requirements. Separately, I would like to note that in each case the FT version is affixed to which this case was written - the requirements may change and the points in them too, if you do not take into account the FT version, then you don’t find them.
It is easy to check the quality of coverage requirements of cases. Before the eyes, there is not a sheet of 50 cases and the same sheet of FT alongside, but choose one item of requirements and immediately see which cases cover this item;
In the case of a change in requirements, it is immediately clear what cases need to be corrected.
Cases are written in three versions: 3r3323222.
Cases headings (most of them). When a case has only a title, it is clear what needs to be done. They are faster to write than detailed test cases and at the same time transparent coating:
Test cases. Detailed test case with steps, when there are many nuances in the case and all of them cannot fit in the heading;
Case-check-lists. When a case consists of a checklist for checking a certain direction of the functional. To highlight such cases we use in the title (cases):
In the sections of FT, where there are mock-ups, a test case is created “Matching with the layout M ”. It serves as a simple reminder that there is a layout and the implementation needs to be checked with it. This case without an internal description - the check-list for verification with the layout is described in the regulations.
Review of cases
After writing the cases, the status of the “Review of cases” is affixed to the general table, this is a sign that another tester can take this FT and conduct a review of the cases. This is necessary so that the cases are equally understandable to all testers and in order to take a fresh look at the requirements.
In case of unsuccessful review, for example, new issues have appeared in the TF or coverage is insufficient - the requirement is transferred to the “Finalize” status. There are not enough comments in TestRail to describe all your wishes - as long as it happens in writing in Slack, which is not very convenient for tracking.
If the review is successful - FT enters the “Ready” status.
In rare cases, when the requirements were updated after writing test cases on them - FT is transferred to the “Updated” status. Additionally, a tester covering FT subscribes to updates to the Confluence page. If the requirements have changed a lot - a task is created for the tester to update the cases.
What gives us this approach?
First, the development of proven requirements. This saves the time of developers, to whom illogic, shortcomings and shoals of FT simply do not reach;
Secondly, testers are preparing for testing in parallel with the development, so we reduce the release time features. Testers can calmly and responsibly approach the process of writing cases, and not in the format “Aaaa, a huge feature fell, you need to pour it tonight. Let's test faster! ”
Thirdly, it is an increase in the quality of testing due to a review of cases. Say “No!” To a stare.
What don't you like?
There is a rather large time gap between the writing of cases and their running on the feature - although the cases are ready and they can only be checked, but the tester still falls out of context;
As I wrote earlier - there are not enough comments in TestRail, as in Confluence - you can’t just take a note of a problematic place and leave a comment to it.
That's all for now. Thanks for attention!
And how does the process of working with the requirements of you?
It may be interesting
We take being #1 in Commercial Odor Remover Products & Systems very seriously. Here are some of the reasons you can trust Cupridyne Clean to bring you a solution to your Commercial Odor Control problem.