Test Methodologies

There are numerous methodologies available for developing and testing software. The methodology you choose depends on factors such as the nature of project, the project schedule, and resource availability. Although most software development projects involve periodic testing, some methodologies focus on getting the input from testing early in the cycle rather than waiting for input when a working model of the system is ready. Those methodologies that require early test involvement have several advantages, but also involve trade offs in terms of project management, schedule, customer interaction, budget, and communication among team members

1. Waterfall model                                              2. Prototype Model 
3. Iterative Model                                               4. RAD Model 
5. Agile Methodology                                         6. ‘V’ Model

Test Scenario

A set of test cases that ensure that the business process flows are tested from end to end. They may be independent tests or a series of tests that follow each other, each dependent on the output of the previous one. Test Scenarios are prepared by reviewing functional requirements and preparing logical groups of functions that can be further broken into test procedures. Test Scenarios are designed to represent both typical and unusual situations that may occur in the application. Test Scenarios are executed through the use of test procedures or scripts. Test procedures may cover multiple test scenarios.

Testing Techniques

Black Box/Functional Testing Techniques:

Equivalence Partitioning:

Equivalence partitioning is the process of methodically reducing the huge(infinite)set of possible test cases into a much smaller, but still equally effective set. when looking for equivalence partitions, think about ways to group similar inputs, similar outputs, and similar operations of the software. These groups are the equivalence partitions

For example:

Bank account can be 500 to 1000 or 0 to 499 or 2000 (the field type is integer). What are the equivalence classes?

• Valid class: 0 <= account <= 499
• Valid class: 500 <= account <= 1000
• Valid class: 2000 <= account <= 2000
• Invalid class: account < 0
• Invalid class: 1000 < account < 2000
• Invalid class: account > 2000

Boundary Value Analysis
If software can operate on the edge of its capabilities, it will almost certainly operate well under normal conditions. This technique consist of developing test cases and data that focus on the input and output boundaries of a given function. 

The boundary value analysis can have 6 text cases.
n, n-1,n+1 for the upper limit and n, n-1,n+1 for the lower limit.

For Example:
Username field should take only 5 - 15 characters.  If we apply BVA rule then we need to do field validation in 6 ways as follows

Username with 4 characters (Invalid)
Username with 5 characters (Valid)
Username with 6 characters (Valid)
Username with 14 characters (Valid)
Username with 15 characters (Valid)
Username with 16 characters (Invalid)

Error Guessing
This is based on the theory that test cases can be developed based upon the intuition and experience of the Test-Engineer.

For Example: 
In the example of date, where one of the inputs is the date, a test may try February 29, 2000 or 9.9.99 

White Box/Structural Testing Techniques:
 

Statement Coverage - Executes all statements at least once

 

Decision Coverage - Executes each decision direction at least once

Condition Coverage - Executes every condition in the program with all possible outcomes at least once  

Cyclomatic Complexity - he complexity M is then defined as M = E − N + 2P where 
 E = the number of edges of the graph 
N = the number of nodes of the graph 
P = the number of connected components

Test Plan

• Test plan is defined as an overall document providing direction for all testing activity. Test planning process is a critical step in the testing process. Without a documented test plan, the test itself cannot be verified, coverage cannot be analyzed and the tet process is not repeatable.
• Test Planning should begin at the same time requirements definition starts. The plan will be detailed in parallel with application requirements. Writing a test plan allows you to collect your thoughts, your ideas.  

  Sample test plan includes:

  1. Overview 
  2. Bounds 
  

  2.1.Scope and Objectives 

  2.2.Definitions 

  2.3.Assumptions 

  3.Quality Risks 
  4.Proposed Schedule and Milestones 
  5.Transitions 
  

  5.1.Entry Criteria 

  5.2.Discontinuation Criteria 

  5.3.Exit Criteria 

  6.Test configuration and Environment 
  7.Test Design and Test Tools 
  8.Test Execution 
  

  8.1.Resources 

  8.2.Tracking and Management of Tests and Bugs 

  8.3.Bug isolation and classification 

  8.4.Release Management 

  8.5.Test Cycles 

  9.Test Data Management 
  10.Risks and Contingencies 
  11.Change History 
  12.Referenced Documents

Verification and Validation

Verification ensures that various work products (requirement specification document, design document, test plan etc) are complete and consistent with respect to the other related work products and customer needs.  

Are we building the product right?  

Validation is the process of evaluating the software at the end of software development process to determine compliance with the user requirements. Are we building the right product?

Quality Assurance and Testing

• Testing is an activity to determine the status of the product during and after the build. The goal of software Tester is to find bugs and find them as early as possible and notify the same to developers so that they get fixed
• A Software Quality assurance person's main responsibility is create and enforce standards and methods to improve the development process/ testing process so that bugs can be prevented.

Error, Defect, Bug, Failure

Error : These are human mistakes which produces incorrect results. (Example : Typographical error / syntactical error)

Defect : These are improper program conditions that are generally the result of one or more multiple errors. All errors may not produce defects. A typical example would be error in the logo of the splash screen coming up on product start up!

Bug : A bug or fault is program defect that is encountered while operating the product either under test or while in use. Bug result from defects but all defects do not cause bugs.

Failure : A failure is a manifestation of an error. It may results from a bug, incorrect installation, a communication line fault, a hardware problem etc.

Defect Metrics

Product quality is usually measured by the number of "bugs" that a software product may have. Two metrics typically used in this context are defect density, defect rate and Defect Injection Rate

Defect Density: (at System Testing Stage) Total number of defects identified during system testing / Actual size of the component 

Defect Rate : It is the expected number of defects over a certain time period specified. It is important for cost and resource estimates of the maintenance phase of the software life cycle.

Defect Injection Rate: # of defect introduced (aggregated by root cause)/ Total defects

Quality Control Vs Quality Assurance

Quality Control is Corrective where as Quality Assurance is Preventive.
Quality Control is Product and Quality Assurance is Process
Quality Control gives Confidence to Producer but Quality Assurance gives Confidence to Customer
Main function of Quality Control is to Find Defects and Quality Assurance is to Prevent Defects

Examples:
Quality Control : Desk Check,Walk through, Inspection, Testing
Quality Assurance: Defining Process, Quality Audit, Training

Meaning of Quality: Defining Quality

"Achieving high levels of user satisfaction, portability, maintainability, robustness and fitness for use" "Software Quality means being on time, within budget and meeting user needs" "High levels of user satisfaction and low defect levels, often associated with low complexity" "high levels of user satisfaction and adherence to requirements" 

Quality must meet two important criteria:  

1. Quality must be measurable when it occurs  

2. Quality should be predictable when it occurs