Verifying Requirements

The most important thing on specifying Requirements is Quality Measure of each Requirement. Quality Measure is specified for a requirement, any solution that meets this measure will be acceptable, and any solution that does not meet the measure will be not acceptable. Quality Measure are used to test the new system against the requirements. Attempting to define the quality Measure for a requirement helps to rationalize fuzzy requirements. For example: everyone would agree with a statement like “System must provide good value”. But each person may have a different interpretation of “Good Value”. In devising the scale that must be used to measure “Good Value”, it will become necessary to identify what that term means. Sometimes requiring the stakeholders to think about a requirement in this way will lead to defining an agreed-upon quality measure. In other cases, there may be no agreement on a quality measure. One solution would be to replace one vague requirement with several unambiguous requirements, each with its own quality measure. It is important that guidelines for requirement development and documentation be defined at the outset of the project. In all but smallest programs, careful analysis is required to ensure that the system is developed properly. Uses Cases are one way to document functional requirements, and can lead to more through system designs and test procedures. In addition to Functional Requirements, it is also important to consider Nonfunctional Requirements, such as performance and security, early in the process. They can determine the technology choices and areas of risk. Nonfunctional Requirements do not endow the system with any specific functions, but rather constrain or further define how the system will perform any given function. Functional Requirements should be specified along with their associated Nonfunctional Requirements.

Involve Testers from the beginning

Now I will describe about the first step of Effective Software Testing in the Requirement Phase. Testers need to be involved from the beginning of a project’s life cycle so they can understand exactly what they are testing and can work with other stakeholders to create testable requirements.

A requirement can be considered Testable if it is possible to design a procedure in which the functionality being tested can be executed, the expected output is known, and the output can be programmatically or visually verified. Tester need a solid understanding of the product, so they can be devise better and more complete test plans, designs, procedures, and cases. Early test team involvement can eliminate confusion about functional behavior later in the project life cycle. In addition, early involvement allows the test team to learn over time which aspects of the application are the most critical to the end user and which are the highest-risk elements. This knowledge enables testers to focus on the most important parts of the application first avoiding over-testing rarely used areas and under-testing the more important ones.

Some organizations regard testers strictly as consumer of the requirements and other software development work products, requiring them to learn the application and domain as software builds are delivered to the testers, instead of involving them during the earlier phases. This may be acceptable in smaller project in a small company, but in the big company especially in financial company (my company) which have complex environment, it is not realistic to expect testers to find all significant defects if their first exposure to the application is after it has already been through requirement, analysis, design, and some software implementation. Testers need deeper knowledge that can come only from understanding the thought process used during the specification of product functionality. Such understanding not only increases the quality and depth of the test procedures developed, but also allows testers to provide feedback regarding the requirements. The earlier in the life cycle a defect is discovered, the cheaper it will be to fix it. In my first few days as software tester, I’d given so many documents contain requirements, analysis, and design to learn. And I had to discussed with another testers, test leader, test manager, and business analyst to make the best Test Design which results the best Test Plan.

Effective Software Testing (Requirements Phase)

Requirements Phase

The most effective Testing Program start at the beginning of project, long before any program code has been written. The requirements documentations is verified first, then in the later stages of the project, testing can concentrate on ensuring the quality of the application code. Expensive reworking is minimized by eliminating requirements-related defect early in the project’s life, prior to detailed design or coding work.

The requirements specifications for a software application or system must ultimately describe its functionality in great detail. One of the most challenging aspects of requirements development is communicating with the people who are supplying the requirements. Each requirement should be stated precisely and clearly, so it can be understood in the same way by everyone who reads it.

If there is a consistent way of documenting requirements, it is possible for the stakeholders responsible for requirements gathering to effectively participate in the requirements process. As soon as requirements is made visible, it can be tested an clarified by asking the stakeholders detailed questions. A variety of requirements test can be applied to ensure that each requirement is relevant, and that everyone has the same understanding of its meaning.