Showing posts with label IT: Testing: Basics. Show all posts
Showing posts with label IT: Testing: Basics. Show all posts

Saturday, November 14, 2009

Why needs testing?

As discussed in my previous post "Who wants testing?", people want testing for different reasons and to satisfy different objectives. In summary, testing is required to ensure the following:
  1. required features are delivered by products;
  2. required features are working as per expected.
For more details, please refer to my post "Who wants testing?".

Who wants testing?

Basically, there are 3 types of people who want testing:
  1. customer;
  2. company;
  3. project manager.
However, why do they want testing? Or why do they need testing?

Customer
Practically, there are 2 reasons why customer needs testing. That is,
  1. to ensure business objectives are satisfied by products;
  2. to minimize risk from deploying products or changes into production.
Therefore, delivery projects are required to ensure the following:
  1. required features are provided by products;
  2. required features are working as per expected;
  3. required features are delivered in time and within budget.
To achieve the above objectives, the first and second objectives require testing while the third one could be achieved by project management.

Company
Company refers to people who runs the company or in charge of selling products of the company. In general, there is only one reason for them to request testing. That is,
  1. to gain advantage in market over competitors.
To achieve this objective, the company needs to gain confidence from the market that:
  1. the products can help customers to achieve business needs consistently;
  2. the company can deliver what customers need consistently.
Again, both testing and project management are required to achieve the first objective while the second one could be delivered by project management.

Project Manager
There is only 1 reason why project manager requires testing. That is,
  1. to ensure products are acceptable by customers.
Again, for products to be acceptable by customers, testing is required to ensure:
  1. required features are delivered by products;
  2. required features are working as per expected.
Others
Some people may suggest that developer also wants testing. It is absolutely clear that testing by developer should be part of the overall testing strategy. However, testing is very often blamed by developer to stop or delay their delivery of software to customers. Therefore, it is obvious that there are mixed emotions within developer towards testing. Most important of all, they don't really want testing when they come under pressure to deliver. Unfortunately, this is always the situation for developer.

Monday, September 22, 2008

5 Levels of Maturity in Testing

Boris Beizer had defined 5 levels of maturity in testing:

Level 0
There is no difference between testing and debugging. Other than in support of debugging, testing has no purpose. Defects may be stumbled upon but there is no formalized effort to find them.

Level 1
The purpose of testing is to show that software works. This approach, which starts with the premise that the software is (basically) correct, may blind us to discovering defects. Those performing the testing may subconsciously select test cases that shall not fail. They will not create the "diabolical" tests needed to find deeply hidden defects.

Level 2
The purpose of testing is to show that the software doesn't work. This is a very different mindset. It assumes the software doesn't work and challenges the tester to find its defects. With this approach, we will consciously select test cases that evaluate the system in its nooks and crannies, at its boundaries, and near its edges, using diabolically constructed test cases.

Level 3
The purpose of testing is not to prove anything, but to reduce the perceived risk of not working to an acceptance value. While we can prove a system incorrect with only one test case, it is impossible to ever prove it correct. To do so would require us to test every possible valid combination of input data and every possible invalid combination of input data. Our goals are to understand the quality of the software in terms of its defects, to furnish the developers with information about the software's deficiencies, and to provide management with an evaluation of the negative impact on our organization if we shipped this product to customers in its present state.

Level 4
Testing is not an act. It is a mental discipline that results in low-risk software without much testing effort. At this maturity level, we focus on making software more testable from its inception. This includes reviews and inspections of its requirements, design and code. In addition, it means writing code that incorporates facilities the tester can easily use to interrogate it while it is executing. Further, it means writing code that is self-diagnosing, that report errors rather than requiring tester to discover them.

Sourced from Chapter 1, A Practitioner's Guide to Software Test Design by Lee Copeland