Edit post Follow this blog Administration + Create my blog

Testing (Validation) Principles

May 3 2019 , Written by Harry Published on #TESTER

Testing (Validation) Principles:


1. The primary role of software testing is two-fold:

- Determine if the system meets specifications (developer view);

- Determine whether the system meets operational business and user needs (sponsor/customer/user view).

 In addition, there are several secondary roles for testing in an organization that include:

+ raising issues;

+ instilling confidence in the system;

+ providing insight into the software delivery process;

+ continuously improving the test process.


2. Testing is a detection activity.

- It can only demonstrate the presence of errors.

- Testing cannot prove the absence of errors. Thus, testing is the process of analyzing a software item to detect the differences between required outputs (or conditions) and actual outputs (or conditions).

- You can't test quality into software - Testing will not improve bad coding techniques or poor coding structure.


3. Present test results as observations…not judgments.

This approach goes a long way in developing a congenial constructive communication with the developers.


4. As a general testing principal, all requirements should be validated by one of the following methods: testing, inspection, demonstration, and analysis.

This document focuses primarily on the testing method of validation. Some requirements may not be able to be cost-effectively validated by testing. In such cases, requirements should be validated by some other method than testing.


5. Project interim deliverables/documentation may be verified to provide in-progress quality assurance of successful system/software validation. 


6. Test planning begins as soon as requirements are established, and must be modified whenever the requirements are modified.


7. The testing effort is planned under the assumption that errors will be found.


8. The testing process is documented (plans, design, cases, procedures, and reports) and approved.


9. Every test case/procedure/result should be repeatable.


10. All hardware or software changes should be tested prior to releasing the system to the production environment. This includes regression testing of all software components that could be impacted by the change(s).


11. Testing standards should be established to address: Documentation, Deliverables, Tools & techniques, Quality requirements


12. Software developers are not the only ones to test the software. Independent testers/users (independent of the engineer responsible for development) may be used to conduct system, acceptance, and other types of testing.


13. Testers never assume that the system/software is correct. The software testing effort provides that evidence.


14. Start early. Even though you might not have all of the details at hand, you can complete a great deal of the planning effort by starting on the general and working toward the specific.

By starting early, you can also identify resource needs and plan for them before other areas of the project subsume them.


15. Keep the test plan flexible. Make it easy to add test cases, test data, and so on. The test plan itself should be changeable, but subject to change control.


16. Frequently review the test plan. Other people's observations and input greatly facilitate achieving a comprehensive test plan.

The test plan should be subject to quality control just like any other project deliverable.


17. Keep the test plan concise and readable.

- The test plan does not need to be large and complicated.

- In fact, the more concise and readable it is, the more useful it will be.

- Remember that the test plan is intended to be a communication document.

- The details should be kept in a separate reference document.


18. Calculate the planning effort.

You can count on roughly one-third of the testing effort being spent on each of the following test activities: planning, execution, and evaluation.


19. Spend the time to do a complete test plan. The better the test plan, the easier it will be to execute the tests.


20. Always write down what you do and what happens when you do exploratory testing.12The primary objectives9 of testing during the requirements phase is to:

• Determine that the requirements fairly represent what the is needed

• Determine that the needs have been defined and documented

• Verify that a reasonable and valid cost/benefit study has been performed

• Determine that the business problem has been solved

• Verify that the control requirements have been specified

• Verify that a reasonable process was followed in developing the business solution

• Verify that a reasonable alternative was selected among the most probable alternative solutions”


21. eXtreme Testing - The process of testing software in a dynamic environment whereby the program is executing while testing is underway to identify defects and enhance improved quality and productivity.

- The methodology combines the best practices of traditional software testing methods and processes with the ability to apply these time-tested methods in a rapid development paradigm.

- It focuses on collaboration between developer, customer, and tester, testing is accomplished in shorter timeframes with an emphasis on developing the software correctly the first time, thereby eliminating the need for lengthy test cycles and redundant tests.

- This is a highly customizable approach to testing software and is adaptable to any software development environment.

- The best success is achieved in organizations that already have mature development and testing processes and have attained a level of capability beyond simplistic means.

Share this post
To be informed of the latest articles, subscribe:
Comment on this post