Testing Techniques

• Black Box Testing
• White Box Testing
• Regression Testing
• These principles & techniques can be applied to any type of testing.

 Black Box Testing

 Testing of a function without knowing internal structure of the program.

 White Box Testing

 Testing of a function with knowing internal structure of the program. 

 Regression Testing

 To ensure that the code changes have not had an adverse affect to the other modules or on existing functions.

 Functional Testing

 Ø       Study SRS

Ø       Identify Unit Functions

Ø       For each unit function

·         Take each input function

·         Identify Equivalence class

·         Form Test cases

·         Form Test cases for boundary values

·         From Test cases for Error Guessing

Ø       Form Unit function v/s Test cases, Cross Reference Matrix

Ø       Find the coverage

What makes a good Software QA engineer?

The same qualities a good tester has are useful for a QA engineer. Additionally, they must be able to understand the entire software development process and how it can fit into the business approach and goals of the organization. Communication skills and the ability to understand various sides of issues are important. In organizations in the early stages of implementing QA processes, patience and diplomacy are especially needed. An ability to find problems as well as to see 'what's missing' is important for inspections and reviews.

 

·         Testing

 

Ø       An examination of the behavior of a program by executing on sample data sets.

Ø       Testing comprises of set of activities to detect defects in a produced material.

Ø       To unearth & correct defects

Ø       To detect defects early & to reduce cost of defect fixing

Ø       To avoid user detecting problems

Ø       To ensure that product works as users expected it to.

 

As a manager what process did you adopt to define testing policy?

Below are the important steps to define testing policy in general. But it can change

according to how you implemented in your organization. Let’s understand in detail the

below steps of implementing a testing policy in an organization.

Definition: - The first thing any organization need to do is define one unique definition

for testing within organization. So that every one is on the same mind set.

How to achieve: - How are we going to achieve our objective?. Is there going to be a

testing committee, will there be compulsory test plans which needs to be executed etc etc.

Evaluate: - After testing is implemented in project how do we evaluate the same. Are we

going to derive metrics of defect per phase, per programmer etc etc. Finally it’s

important to let know every one how testing has added value to the project.

Standards : - Finally what are the standards we want to achieve by testing. For instance

we can define saying that more than 20 defects per KLOC will be considered below

standard and code review should be done for the same.

Figure:

Does Increase in testing always mean good to the project?

No increase in testing does not mean always good for the product, company or the

project. In real test scenarios from 100% test plans only 20% test plans are critical from

business angle. Running those critical test plans will assure that the testing is proper

rather than running the full 100% test plans again and again. Below is the graph which

explains the impact of under testing and over testing. If you under test a system your

number of defect will increase, but on the contrary if you over test a system your cost of

testing will increase. Even if your defects come down your cost of testing has shooted

up.

What is the difference between Defect and Failure?

Define Defect?

Defect is a variance from a normal flow

When a defect reaches the end customer it is termed as failure and if the defect is

detected internally and resolved it’s called as a defect.

There are mainly three categories of defect:-

Wrong: - The requirements have been implemented incorrectly. This defect is a variance

from the given specification.

Missing: - There is a requirement given by the customer and is not done. This is a

variance from specification, an indication that the specification was not implemented, or

a requirement of the customer was noted properly.

Extra: - A requirement incorporated into the product that was not given by the end

customer. This is always a variance from specifications, but may be an attribute desired

by the user of the product. However, it is considered a defect because it’s a variance from

the existing requirements.

Figure:

What is the difference between white box, black box and gray box testing??

Black box testing is a testing strategy which is based solely on the requirements and
specifications. Black box testing requires no knowledge of the internal paths, structure, or implementation of the software under test.

White box testing is a testing strategy which is based on the internal paths, code structure, and implementation of the software under test. White box testing generally requires detailed programming skills.

There is one more type of testing is called gray box testing. In this we look into the "box"
under test just long enough to understand how it has been implemented. Then we close up
the box and use our knowledge to choose more effective black box tests.


Below figure shows how both the types of testers view an accounting application during testing. In case of black box tester they view in terms of pure accounting application. While in terms of White box testing the tester know about the internal structure of the application. In most scenarios white box testing is done by developers as they know the
internals of the application. In Black box testing we check the overall functionality of the
application while in white box we do code reviews , view the architecture , remove bad
code practices and component level testing.