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 the testers with the requirements consists of three stages: the FT Review, the FT Coverage, the Case Review.
Requirements are conducted by analysts in Enterprise Architect, from there they are copied to Confluence. After writing the requirements, they are sent to the testers review.
While this interaction is conducted through Google Sheets, where there is:
The analyst to the corresponding item of the table puts down the status “On Review”:
At this stage, within Confluence, questions are asked on certain items of requirements, since the functionality allows you to add comments to arbitrary parts of the text. In the comments there are discussions, the outcome of which is 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, 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 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 is created “Matching with the M layout ...”. 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 in the general table, the status of “Review of cases” is affixed, 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 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?
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 the testers with the requirements consists of three stages: the FT Review, the FT Coverage, the Case Review.
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 the testers review.
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 puts down the status “On Review”:
At this stage, within Confluence, questions are asked on certain items of requirements, since the functionality allows you to add comments to arbitrary parts of the text. In the comments there are discussions, the outcome of which is 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, 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 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 is created “Matching with the M layout ...”. 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 in the general table, the status of “Review of cases” is affixed, 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 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.
Conclusion
What gives us this approach?
- First, the development of proven requirements. This saves the time of developers, to whom illogic, shortcomings and FT shoals 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 has fallen, you need to pour it tonight. Let's test faster! ”
- Thirdly, this 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 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?