Post on 15-Jan-2016
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