مقال باللغة الانجليزية عن كيفية اختبار البرمجيات بدون متطلبات "?How to test without requirments"

Imagine that you are a part of a QA team, and you are involved to test a complex project, but when you asked about the requirements, the team told you “Sorry we didn’t document the requirements”, This situation is very common in the software industry in different projects, personally I faced this situation before, sometimes the team doesn't document the requirements for the project due to different reasons like the team is in rush and wants to implement the project quickly, the project scope changes a lot, or the team gave a little importance to the documentation part.

This situation can happen while testing the whole system or if you are testing a new feature of the project, No one can deny the importance of having documentation in the software QA process, and in some companies, testers are asked to write, but you have to handle the situation and here are some suggestions that would help you:

1- Try to understand the system

Trying the system out as an end-user and understanding the purpose of the system, will give you more knowledge about it, here you can just understand the main functionalities, or do some exploratory testing which is " An approach to software testing that is often described as simultaneous learning, test design, and execution. It focuses on the discovery and relies on the guidance of the individual tester to uncover defects that are not easily ", You simply learn the system, design some test cases, and execute them.

2- Try to find similar projects

Search for projects doing similar functions as the system you are intended to test, for example, if you are testing an E-commerce, try to search for some e-commerce and try them out, If you can't understand what's expected from "Add to Cart" button, try it in another project.

3- Meetings and asking questions

You might get a great knowledge by meetings and asking questions, try to organize some meetings with the project manager, developer, designers, and other stakeholders, and it's ideal to previously prepare your questions about the system so you can get more information in less time.

Questions can be like and not limited to :

What is the main purpose of the system?

Who are the main users?

Are there any personas?

What are the main modules of the system? and what's the expected of each of them?

Ask the project manager, product owner, or developer about the expected behavior of a specific function.

Many questions can be asked here, so you can get valuable information about the system.

4- Any document would help you

No requirements No Problem, but there might be other documents rather than the requirements that would help you like :

The Database schema will help you understand the main objects of the system and their main relations.

The Data Flow diagrams

The business model will open your eye to the whole system.

Usecases are so important and valuable in this case as they show you the main users and their interaction with the system.

5- Use your common sense and previous experience

Many functions are so easy to define their expected behavior based on your previous experience of work or your experience as a user of some systems, Common sense also will help you.

As a tester you can avoid facing such problems in the future, enhance your skills by trying out and browsing different applications in different domains, just doing some exploratory testing, even it’s a new project for you, doing this will expand your experience and give you hands-on experience in different domains, so when you get involved in one of the projects without requirements, handling the project will be easier.

Try to previously create your own checklists for the most common projects and functions, like the Login function the expected behavior of this function is very common, so previously defining it will save you a lot of time in your upcoming projects and give you more time to focus and learn new function, this also applies for your previous project, documenting your experience after every project will worth gold later on.

Finally testing without requirements isn't that difficult, but it's a situation that needs more patience and flexibility to build your own resources and knowledge, so it can be handled easily.