When creating new software functionality, the analytical team creates certain technical requirements, and the QA department tests the product based on these instructions. And, of course, this happens even before the product reaches the end user.
In this article, we will talk about the important points that you should pay attention to when testing software requirements.
There are several basic characteristics that must be present in the technical documentation for any project. Usually, it includes the following:
- Completeness;
- Clear interpretation;
- Consistency of facts;
- The need for implementation;
- Practicability;
- Complete testability.
If necessary, this list may include more items, but these 6 are the key ones! Further, we’ll analyze each of them in more detail.
Completeness
Specification of any project should answer the questions: is everything described? Could anything be missed? Is there any hidden functionality?
To test this item quickly and effectively, one should make a special checklist of software functionality tests. It is a good practice to make such documents at the stage of familiarization with the PRD – product requirements document (not just thinking about possible test scenarios but documenting each point).
Naturally, the process of writing tests is a labor-intensive process. But it will significantly save you time in the future since the checklist will be ready and you will only have to implement all the planned tests.
Clearness
All participants must understand the product requirements in the same way. All the contradictions that are present in the product requirements document must be clarified for general understanding.
PRD should not have a double meaning. Try to avoid such situations. Of course, you should not seek out every little thing and try to describe the smallest functional blocks in detail. Just the nature and interpretation of the document should not cause conflicting interpretations from both the testing department and the support/development department.
If the document is only for internal corporate use, then specialists can compromise and discuss some points personally. And if the document is for a client, then you have to provide a detailed description of EVERYTHING to receive as few clarifying questions as possible.
Consistency of Facts
The nature of the requirements should not contradict itself. Sometimes, this can happen when the number of requirements is simply huge. The analytics department (those people who create PRD after a dialogue with a client) simply forgets that they have already described functional X and again comes up with and details the behavior of specific functionality. And sometimes, it describes something completely different and wrong.
The Need For Implementation
It is very good when the technical documentation is created as comprehensively as possible. But this does not mean that a simple functionality needs to take over 20 pages. Write in the PRD only relevant data, namely:
- The body of PRD – developed functionality, basic software development scenario, types of potential bugs;
- User Documentation – a guide on how to use this software.
Practicability
This point is more related to the development department. It is they who must technically make sure that the developed product will function exactly the way the client and the PRD want it.
Complete Testability
Is it possible to test the functionality at the moment? One should think about this fact in advance. Otherwise, it will happen that the programmer created the software, and only then the QA specialist realizes that there is no way to check the current task. Or it can be tested, but there is no way to create automated tests for it, etc.
Leave A Comment