Module Based Regression Test SelectionStrategy for Web applications

Author: Annamariale ChandranHoneywell Technology Solutions

For International Conference on Software Engineering

19th Dec 2009

Software Life cycle

Requirements

SpecificationDocument

DesignDesign

Document

ImplementationSourceCode

Acceptance Testing

FinalSystem

Maintenance

SoftwareRequirements

High Level DesignLow Level Design

Unit/Integration testing

Unit Test cases

System testing

System Test cases

Update Traceability

Testing Vs Regression Testing

Testing aided by Requirement spec &

design document

Regression aided by Collation of available artifacts

and proper impactAnalysis of new changes

In terms of Quality

How far test cases and execution are performed in terms of spec

Applied testing techniques

Depends also on what extentearlier documents are available

Analysis on ImpactsRegression techniques used to

derive test cases

Regression TestingUsed to validate software after some modifications are incorporated in the application

Aims at validating not only the changes, but also the impacted functionalities due to those changes

Process of validating modified software to provide confidence that changed parts of software behave as intended and un-hanged parts of the software have

not been adversely affected by the modification

Applicable Regression Testing Areas

Types of Project Development

Project development from Scratch

Contracted software

Adopting some common Framework

Using new trends like SOA, Cloud computing

Full Life cycle -> Successive build

Iteration releasesMaintenance activitiesEnhancementsAny software Migration

General Hurdles

Non-availability of updated spec and test artifacts in a single repository

Allocation of dedicated test resource

Use of specification Vs test case traceability is time consuming when subject under test grows

In practice, use of dedicated effort for deriving impacts is rarely possible as agile environment demands things to move faster

Testers will be allocated for more than one project, more than one task at the same time

Factors to be considered

Should reduce test design timeShould reduce application knowledge transfer timeShould provide inputs on impact to pre-system phases to improve DRE

Quality of derived Impacts

Productivity factor in achieving the quality

As-Is techniques & Drawbacks

Code Based

Re-test All

Specification based with activity diagram

Risk based

Dependency with dev team

Adhoc walkthrough

Scalability problem when size grows

Increase in effort

Downturn in updating new spec items

Depends on individual skill level

Misses in finding Impacts

Ineffective review for the derived Impacts

In Nutshell

Current Difficulties Expectations

In reality changes are validated on independent test document

In most cases original test cases (either steps, expected output)

will be changedSkill level of resources will not be same

in understanding the test cases to know high level functionality

To adopt some sort of regressionguidelines every time to extract impacts

Instant understanding of high level functionalities of derived test cases

The module in which it falls Understanding existing

scenarios from the extracted test suites

The priority & severity of those test cases

To provide impacts automatically (needless to use Guideline every time)

Try for newnew approach??

Basis -> Adhoc thought process while deriving impact

Module Based Regression Testing

What Theory says?

Regression analysis aims at measuring the relation of independent variable to its dependent variable's so as to predict the future value of dependent variable

Derived concept for Web based application to perform Regression Testing

Dependent and independent variablesare considered as modules in the existing application. To derive the regression curve between the modules, factors that lead toInterlink the modules is considered.

Future value of dependentVariable (any change) is Identified in terms of its related dependent variables

Regression Logic

Module relation with primary dependent variables y(m) = f(x(p), β) -----------------(1)

Where, y(m) -> modules derived in the application under testx(p)->primary dependent variables identified for the derived modulesβ -> intelligent guessing function that ensures the correctness of mapping the primary dependent variables to the identified modules

Final parametric relation between modules Yd(M) = yid(m)f(α) ------------------- (2)

WhereYd(M) ->dependent module that will get impacted another module in the application yid(m) ->independent module referred at that instant α -> derived function from equation (1) to differentiate Yd(M) and yid(m)

Sample Application

Employee Request Management System

LoginRequest type1

Request type2

Request type3

Request type.. n

User applying for specific request

Approval Process

Keep trackOf records

Start

End

Step1a: Identify Modules

Step1b: Map High level Functionalities

Objective: Derive test scenarios for the specified modules

‘Request Form’ high-level functionality

User details should be auto-populated from LDAP for the logged in user

Mail Id field should alone be allowed for editing Manager ID should be same as that of user’s portfolio Data requirement validation (Refer to xxx SCM

location) Mail should be sent to the primary approver

when request is submitted and status change to PA (Pending primary approval)

Step2: Identify primary dependent variable1

(that varies based on the domain nature)

Extract dependent variable1-Fields/Sections

Extract dependent variable2-Common functionality

Step2: Identify primary dependent variable2

Step3: Module Linkage for dependent variables

Step4: Final regression plot

In Practice…..

Frequency of

When Module is changed/removed

When identified top level functionality changes

When any fields or sections changed

No Need of

Updating/ linking any user defined test cases

Updating any low level changes in requirements

Ex: Display format change of user name

Any addition of filter fields in reports

Results

MBRT-Effectiveness

Deriving primary dependent variables

Review on derived impacts -> more similar to

Specification/design reviews

Knowledge on frequency of updates

Use of both functional and structural analysis for impacts

Identification

In case of support projects, use of agile practices

in an efficient way to perform reverse engineering

Derived Benefits

Test coverage is high within the limited time frame

Does not demand the resource to have complete understanding of the system

Analyze the related impacts & come up the priority wise modules and scenarios to be executed

Knowledge transfer time is less

Provides input to the code-level impacts (Reverse engineering)

Estimation to validate the changes becomes more accurate

Future Amendments

To roll out an automated selection of impacted modules and scenarios

To apply regression logic for deriving impacted code, by providing the code related information to the requirement database as one more primary dependent variable