Capability Maturity Model (CMM)

• Level l : Initial
• Level 2: Repeatable
• Level 3: Defined
• Level 4: Managed
• Level 5: Optimizing

Level 1: Initial

– adhoc, chaotic, few process defined, success depends on individual

efforts

Level 2: Repeatable

– Project management to track cost,schedule and functionality.

Disciplined to repeat earlier success.

Level 3: Defined

– Management and engineering activities are

documented, standardized and integrated into an organization-wide SW process.

Level 4: Managed

– Detailed measures of SW process and product quality are collected.

Level 5: Defined

– Continuous process improvement by quantitative feedback form process and from testing innovative ideas and technologies.

Change Management & Testing

Reasons for change:

- Elimination of existing defects.

- Adaptation to di erent application environments.

- Alteration in order to improve the quality of the product.

- Extensions in order to meet new requirements.

Testing for change:

- Determine if changes have regressed other parts of the software - regression testing.

- Cost-risk analysis: full regression testing or partial regression testing?

- Effectiveness: automation and persistent test-points.

Software Testing Life Cycle

Test Requirements

· Requirement Specification documents

· Functional Specification documents

· Design Specification documents (use cases, etc)

· Use case Documents

· Test Traceability Matrix for identifying Test Coverage

Test Planning

· Test Scope, Test Environment

· Different Test phase and Test Methodologies

· Manual and Automation Testing

· Defect Mgmt, Configuration Mgmt, Risk Mgmt. Etc

· Evaluation & identification? Test, Defect tracking tools

Test Environment Setup

· Test Bed installation and configuration

· Network connectivity

· All the Software/ tools Installation and configuration

· Coordination with Vendors and others

Test Design

· Test Traceability Matrix and Test coverage

· Test Scenarios Identification & Test Case preparation

· Test data and Test scripts preparation

· Test case reviews and Approval

· Base lining under Configuration Management

Test Automation

· Automation requirement identification

· Tool Evaluation and Identification.

· Designing or identifying Framework and scripting

· Script Integration, Review and Approval

· Base lining under Configuration Management

Test Execution and Defect Tracking

· Executing Test cases

· Testing Test Scripts

· Capture, review and analyze Test Results

· Raised the defects and tracking for its closure

Test Reports and Acceptance

· Test summary reports

· Test Metrics and process Improvements made

· Build release

· Receiving acceptance

Boundary Value Analysis

• Based on experience / heuristics

-Testing boundary conditions of equivalence classes is more effective

• Choose input boundary values as equivalence classes representatives
• Choose inputs that invoke output boundary values

Examples:

(0, 10] ⇒ validate using 0, 1, 2, 9, 10, 11

Read up to 5 elements ⇒ validate reading 0, 1, 4, 5, 6 elements

White Box Testing

It is the process of giving the input to the system and checking, how the system processes the input, to generate the output. It is mandatory for a tester to have the knowledge of the source code.

Unit Testing: This type of testing is done at the developer's site to check whether a particular piece/unit of code is working fine. Unit testing deals with testing the unit as a whole.

Static and Dynamic Analysis: In static analysis, it is required to go through the code in order to find out any possible defect in the code. Whereas, in dynamic analysis the code is executed and analyzed for the output.

Statement Coverage: This type of testing assures that the code is executed in such a way that every statement of the application is executed at least once.

Decision Coverage: This type of testing helps in making decision by executing the application, at least once to judge whether it results in true or false.

Condition Coverage: In this type of software testing, each and every condition is executed by making it true and false, in each of the ways at least once.

Path Coverage: Each and every path within the code is executed at least once to get a full path coverage, which is one of the important parts of the white box testing.

The Incremental Model

The Incremental Model combines elements of the Linear Sequential Model (applied repetitively) with the iterative philosophy of prototyping. When an Incremental Model is used, the first increment is often the “core product”. The subsequent iterations are the supporting functionalities or the add-on features that a customer would like to see. More specifically, the model is designed, implemented and tested as a series of incremental builds until the product is finished.

Increment 1: Analysis-->Design-->Code-->Test (Delivery of 1st Increments. Normally '''Core Product''')

Increment 2: Analysis-->Design-->Code-->Test (Delivery of 2nd Increments)

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Increment n: Analysis-->Design-->Code-->Test (Delivery of nth Increments)

Advantages:

• It is useful when staffing is unavailable for the complete implementation.
• Can be implemented with fewer staff people.
• If the core product is well received then the additional staff can be added.
• Customers can be involved at an early stage.
• Each iteration delivers a functionally operational product and thus customers can get to see the working version of the product at each stage.

Functional Analysis:

• Analyze the expected behavior of the system according to its functional specification

• Generate a test procedure for each of the possible usage scenarios

- Corresponds to use case scenarios

- Analyze how a change in one part of the system affects other parts

- “Grand tour” test cases: the result of one test case produces the data that is the input to the next test case