Testing Without Defined Requirements

In recent years in teaching and consultation with testers and test managers around the world, I've noticed something interesting. First, the testers complained that almost never receives the user requirements that is appropriate for testing. Moreover, when speaking of what the evidence base, the main response is "user needs".
When I suggest that there are other ways to design and evaluate the evidence, the answer is similar to the time you accidentally walked into the glass of the revolving door at the airport in Portland-surprise, followed by intense laughter.

I'm serious, however. There are other ways actually to design and evaluate evidence as well as the requirements. First, let's see why you may have to do this.
By the way, let me be quick to say that I am a great believer that solid, verifiable requirements for any project. Without them, you are at risk of a multitude of problems, including not knowing whether an acceptable solution has been delivered. But we also know that we anticipate real-world situations which cannot (or should I say "probably not") to obtain verifiable requirements.

Here are just some of the situations that may require different techniques of evidence-based requirements.

"We do not do well the needs" –
The title of this article is intentional. The word "defined" explicitly indicates that the requirements are documented so that we can discuss, review, manage and all the other things to do with things that are written - including the filing with the garbage and forgotten. Hopefully we will not be filing away and forgotten part.

Commercial Off-The-Shelf Software –
Take the example of buying a commercial software product. You must have defined the requirements, but not for the purpose of building the software. Their concerns relate to the fitness for use. At least, needs a list of things that the software can do for you. Hopefully, the requirements also define the desired or required attributes such as performance and usability. However, these requirements do not describe the processing rules of the software or your organization.

Requirements Obsolete –
Maybe at a time in the past that a number of current and correct. However, over time was not kind to them. The business has changed, laws and technology have changed and now those requirements are not even close to how the system or your organization is today.
The lack of user input or customer ¬–
The project team, including testers, you may want verifiable requirements. However, users and customers simply will not provide them. Maybe they cannot reach agreement on what is desired. Or, they will not give her time - "We have a business to run here. You do your job and we'll do ours." Sure, I'll say when you've missed the mark - you just have a problem telling you where the mark is. That's very frustrating, indeed.

Generic Test Sources
There are at least fourteen sources of evidence:

1. Field and data issues - Is the field issues and the right attributes?
2. Record Management - Is the information processed correctly from one point to another in the application without data loss?
3. The file processing - Are the files accessed and treated correctly?
4. Field and data relationships - When two or more data elements are related, relations are processed correctly?
5. Concordance and data fusion - when two or more data sources are involved, the data are merged correctly?
6. Security - Is the data protected from malicious access, both internal and external to the organization?
7. Performance - Does the application have sufficient performance to meet user needs in terms of response times, performance, cargo handling, etc? This may also include stress tests to simulate conditions that cause the application to fail due to overload.
8. Control of flows (processes and code) - different control flows in the code to perform functions as intended?
9. The procedures and documentation - Are the procedures and documentation to describe accurately the behavior of the application and function?
10. Audit trails - the operations and functions can be traced to a specific time and the user?
11. Recovery - Can the process be recovered from a failed state?
12. Ease of use - Can anyone in the public user intends to use the application without extensive training or additional skills? Can the application functions is easily done?
13. Error handling - errors (both expected and unexpected) handled correctly?
14. Search - Are they being consulted and is in the application?

Summary-
The verification is based on the performance of the project and is evaluated to determine if something has been built correctly in accordance with the specifications or the "world of paper." This is mostly the point of view of the developer. The validation is based on the evaluation of something based on user need or simulated real world conditions. The intention is to determine fitness for use of the customer or user perspective. Without the two points of view, is at risk from the construction or purchase of something that meets the specifications, but is unfit for use.

Requirements-based testing is verification. It is a robust and useful technique if you have clear demonstrable needs. The techniques described in this article are forms of evidence from the perspective of real world use and validation may be considered.