I need your clothes, boots and project requirements. Requirements testing for beginners
The first thing any competent QA specialist should do when entering
a new project, is to ask for familiarization with the project requirements. And the sooner, the better. However, not everyone knows how to work with these requirements, test them effectively and quickly, and this article is exactly about this.
What are requirements and what types are there?
Requirements are any condition that the final product, all its capabilities, limitations and system logic must meet. They are created in the process of developing the task for software development/modernization.
The requirements are divided into functional and non-functional, as well as explicit and implicit (the most insidious)Moreover, implicit requirements must be translated into explicit ones, since the definitions of implicit requirements are not written down anywhere, which means that their presence is fraught with discrepancies and misunderstandings within the team, due to which, in the future, development may encounter problems.
Functional Requirements describe what the system must do. They include
myself:
1. Business requirements;
2. Functional requirements;
3. User requirements;
4.System requirements.
Non-functional requirements describe how exactly the system should work and
why. They include:
1. Business rules;
2. Rules for interaction with external interfaces;
3. Quality metrics;
4. Limitations.
What should a QA specialist do if there are no requirements or almost no requirements?
If you are unlucky and the requirements for the project do not meet the necessary
criteria, or maybe there are none at all, then we need to detect them in time
problem with the requirements and start solving it.
Requirements can be found in various sources:
1. Design documentation;
2. Customer and Interested Parties;
3. Business market segment, similar projects;
4. Industry experts;
5. Internet and media;
6. Legislation;
7. Logic and common sense;
8. Life and professional experience;
9. Colleagues and professional community.
Requirements for a project where they were not present need to be collected, recorded and
agree. Only after this step is it advisable to start working on the project.
Options for recording requirements:
1. Technical specifications, specifications;
2. Schemes, prototypes, layouts, matrices, mind maps;
3. Recordings of conversations in Skype or other messengers;
4. E-mail, messages;
5. Test cases, user stories;
6. Confluence, Wiki or other knowledge bases;
7. Tasks in the tracker in which the team works;
8. TestLink, TestRail and other systems.
What to do with the requirements?
Hooray! The requirements are collected, now what? Requirements need to be managed in order to get the maximum benefit from them for the project.
Requirements management is a process that includes:
1. Version management (identification of versions, tracking versions of individual
requirements, tracking versions of requirement sets);
2. Change management (proposing changes, analyzing the impact of changes on
system, decision making, updating individual requirements, updating
set of requirements, updating plans, assessing the variability of requirements);
3. Tracking the status of requirements (determining possible states
requirements, recording the status of each requirement, tracking
states of distribution of requirements);
4. Tracking the relationships of requirements (defining relationships with other requirements, defining relationships with other elements of the system).
How to conduct requirements testing?
Very interesting, of course, but how to conduct this requirements testing? Below I will give an approximate testing plan, try to work with each of the points as deeply as possible.
Requirements Test Plan:
1. Immersion in the task/subject area. Viewing layouts, design, proofreading the points of the technical specifications, collecting information on the task.
2. Ask questions. Ask your colleagues, customer representatives, your team members, everyone involved in the system.
3. Decompose the requirements and create checklists, test cases, user stories. This will help identify gaps in the requirements.
4. Investigate the system's behavior.
5. Create diagrams, mind maps. Graphic representation gives a visual idea of the system.
What to Look for When Testing: 11 Elements of Quality
There are a set of basic characteristics that good documentation should have. The characteristics of requirements quality are defined differently by different sources, but the following characteristics are generally recognized:
Uniqueness: one requirement – one functionality.
✅ Example of an acceptable requirement | ❗️ Example of a requirement with a broken characteristic |
The requirement specifies one system action – user registration. | The system should allow user authorization using social network data, request certain information from social networks and publish it on the user’s wall in the social network. |
How to test a requirement for uniqueness?
Ask yourself: “How many properties are included in the requirement?”
Atomicity: the requirement cannot be broken down into smaller parts, the requirement cannot be clarified.
✅ Example of an acceptable requirement | ❗️ Example of a requirement with a broken characteristic |
In the “Transfer to account” field, the user can select only ruble accounts. | The user can select an article to read, comment on it and rate it. |
How to test a requirement for atomicity?
Break the requirement into parts. If it works, the requirement does not have atomicity.
Completeness: the requirement is presented in its entirety in one place in the documentation.
✅ Example of an acceptable requirement | ❗️ Example of a requirement with a broken characteristic |
In the functionality describing registration: “to complete registration, the user must enter a captcha.” This requirement is not found anywhere else in the documentation. | In the functionality describing registration: “to complete registration, the user must enter a captcha.” In the functionality describing security requirements: “to register, the user must enter an individual captcha.” |
How to test a requirement for completeness?
Read the documentation carefully, note any repetitions of requirements.
Subsequence: the requirement must not conflict with other requirements and constraints of the system.
✅ Example of an acceptable requirement | ❗️ Example of a requirement with a broken characteristic |
When the user picks up the phone, the phone should make a dial tone. | When the user picks up the phone, the phone should make a beep. When the “silent” mode is active, the phone should not make any sounds. |
How to test a requirement for consistency?
Prototyping, requirements mapping, and a traceability matrix (requirements relationships) will help.
Traceability: the requirement is recorded in the documentation and it is possible to understand where it came from.
✅ Example of an acceptable requirement | ❗️ Example of a requirement with a broken characteristic |
When opening a catalog of alcoholic products, a pop-up window must open on the site to confirm the user's permitted age of 18+ (in accordance with the requirements of Russian legislation). | The pizza delivery app should not be available for download by children under 16 years of age. |
How to test a requirement for traceability?
Prototyping, traceability matrix (requirements relationships) will help. Studying legislation. It is appropriate to ask the analyst about the emergence of a particular requirement.
Relevance: the requirement is not outdated, it complies with current legislation or technical realities.
✅ Example of an acceptable requirement | ❗️ Example of a requirement with a broken characteristic |
The application must run on Windows OS 7 or higher. | The application must work on Android 2.0 OS |
How to test a requirement for relevance?
Read carefully and ask questions. Such requirements are often restrictive, so think and ask where this or that restriction came from.
7. Feasibility: the requirement can be met within the framework of existing technologies.
✅ Example of an acceptable requirement | ❗️ Example of a requirement with a broken characteristic |
The application should download to the user's PC within 3 seconds. | The game should load in 0.1 milliseconds. |
How to test a requirement for feasibility?
Put yourself in the user's shoes. If it's a technical, system, or business requirement, ask questions of colleagues and analysts. Refer to hardware and software manuals and tasks.
8. Clarity: the requirement must be understood by everyone in the same way.
✅ Example of an acceptable requirement | ❗️ Example of a requirement with a broken characteristic |
The input field “Phone number” has an input mask that allows you to enter into the field | The input field is filled with valid characters. |
How to test a requirement for clarity?
By asking questions, researching the system. You can put yourself in the user's shoes and ask yourself: “How do I understand this term or definition?”
9. Verifiability: the fulfillment of a requirement can be measured or verified based on
certain and specified criteria.
✅ Example of an acceptable requirement | ❗️ Example of a requirement with a broken characteristic |
Cards in the product catalog should be displayed as a table. Each table cell displays a preview of the product. | The site must have easy navigation. |
How to test a requirement for verifiability?
Create a checklist or test case – what is the expected result you get, what tools will you use to measure the success or failure of the test case?
10. Mandatory: Without this requirement, the user will not be able to fully utilize the system.
✅ Example of an acceptable requirement | ❗️ Example of a requirement with a broken characteristic |
You can add a product to the online store | The requirements do not mention that the purchased product must be removed from the catalog. |
How to test requirements for mandatory nature?
Compare requirements, ask questions, build diagrams and check connections.
11. Completeness: the requirements are described exhaustively.
✅ Example of an acceptable requirement | ❗️ Example of a requirement with a broken characteristic |
Only letters of the Russian alphabet and a space are available for input in the field. Other characters cannot be entered. Input cannot begin with a space, only with a letter. The case does not matter. Input restrictions: minimum 2 maximum 160 characters. The field is required. It goes into error state when losing focus without filling, when sending an empty field and when entering a number of characters less than the minimum. The error is removed | Only letters are available for input in the field. Input restrictions: minimum 2 characters. The field is required. It goes into error state when losing focus without filling, when sending an empty field and when entering fewer characters than the minimum. |
How to test requirements for completeness?
After reviewing the requirements, you should not have any questions left “what if?”. What about the tools?
Tools for implementing requirements testing
1. Standard task/specification template;
2. Flow of resolving contradictions in requirements (Who is the keeper of the task? Who has the final say?);
3. Requirements testing as a separate stage of the development flow;
4. Documentation/Work scheme;
5. Discussion (attached tasks, links to discussions, etc.);
6. Layouts for each state/animation;
7. Layout/task acceptance checklists;
8. Public testing checklists for typical tasks;
9. Checklist compiled before development;
10. Brand book;
11. The view of a person from a related project, the experience of colleagues;
12. DOD (Definition Of Done).
I hope this article has helped you answer some of your questions and testing
The demands are no longer as frightening as before.
