Covering the requirements of cases. The realities of SuperJob
Hi, habrovchane!
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 testers with requirements consists of three stages: Review of FT, Coverage of FT, Review of Cases.
')
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 analyst to the corresponding item of the table affixes the status “On Review”:
At this stage, within the framework of Confluence, questions are asked on certain points of requirements, since the functionality allows you to add comments to arbitrary parts of the text. In the comments there are discussions, the results of which are updated FT.
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, well, in order not to reinvent your bicycle - it's easier to take it from your analyst neighbor.
Testing covers requirements - each clause of requirements, each clause is covered.
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 can’t find them.
In this way:
Cases are written in three versions:
In the sections of FT, where there are mock-ups, a test case “Matching with the layout M ...” is created. 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.
After writing the cases, the status of the “Review of cases” is entered in the general table, this is a sign that another tester can take this FT and conduct a review of cases. This is necessary so that the cases are equally clear 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 was successful - FT gets into 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?
That's all for now. Thanks for attention!
And how does the process of working with the requirements of you?
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 testers with requirements consists of three stages: Review of FT, Coverage of FT, Review of Cases.
')
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:
- FT name
- Link to FT
- FT analyst
- Analyst statuses
- Responsible Tester
- Statuses from testers
The analyst to the corresponding item of the table affixes the status “On Review”:
At this stage, within the framework of Confluence, questions are asked on certain points of requirements, since the functionality allows you to add comments to arbitrary parts of the text. In the comments there are discussions, the results of which are updated FT.
After the requirements have been added and updated, they are transferred to the development and testing.
FT coating
Test cases are written in TestRail, the test case storage architecture repeats the requirements storage architecture. This is necessary for ease of searching, well, in order not to reinvent your bicycle - it's easier to take it from your analyst neighbor.
Testing covers requirements - each clause of requirements, each clause is covered.
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 can’t find them.
In this way:
- 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 apparent which cases need to be corrected.
Cases are written in three versions:
- 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 select such cases we use in the title (cases):
In the sections of FT, where there are mock-ups, a test case “Matching with the layout M ...” is created. 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 entered in the general table, this is a sign that another tester can take this FT and conduct a review of cases. This is necessary so that the cases are equally clear 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 was successful - FT gets into 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.
Conclusion
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 run 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 note of the problem area 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?
Source: https://habr.com/ru/post/428345/
All Articles