Module Based Regression Test Selection Strategy for Web applications

1
Module Based Regression Test SelectionStrategy
for Web applications
Author Annamariale Chandran Honeywell Technology
Solutions For International Conference on
Software Engineering
19th Dec 2009
2
Software Life cycle
Software Requirements
Update Traceability
High Level Design Low Level Design
3
Testing Vs Regression Testing
Testing aided by Requirement spec design
document

• How far test cases and execution
• are performed in terms of spec
• Applied testing techniques

In terms of Quality
Regression aided by Collation of available
artifacts and proper impact Analysis of new
changes

• Depends also on what extent
• earlier documents are available
• Analysis on Impacts
• Regression techniques used to
• derive test cases

4
Regression Testing

• Used 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
5
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 -gt Successive build
• Iteration releases
• Maintenance activities
• Enhancements
• Any software Migration

6
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

7
Factors to be considered

• Quality of derived Impacts
• Productivity factor in achieving the quality

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

8
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

9
In Nutshell

• Expectations

• Current Difficulties

• In reality changes are validated on independent
  test document
• In most cases original test cases (either steps,
  expected output)
• will be changed
• Skill level of resources will not be same in
  understanding the test cases to know high level
  functionality
• To adopt some sort of regression
• guidelines 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)

10
Try for new approach??
Basis -gt Adhoc thought process while deriving
impact
11
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

Future value of dependent Variable (any change)
is Identified in terms of its related dependent
variables
Dependent and independent variables are
considered as modules in the existing
application. To derive the regression curve
between the modules, factors that lead
to Interlink the modules is considered.
12
Regression Logic
Module relation with primary dependent variables
y(m) f(x(p),
ß)
-----------------(1) Where, y(m) -gt modules
derived in the application under
test x(p)-gtprimary dependent variables identified
for the derived modules ß -gt 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(a)
------------------- (2) Where Yd(M)
-gtdependent module that will get impacted another
module in the application yid(m) -gtindependent
module referred at that instant a -gt
derived function from equation (1) to
differentiate Yd(M) and yid(m)
13
Sample Application

• Employee Request Management System

Request type1
Login
Approval Process
End
Request type2
User applying for specific request
Start
Request type3
Keep track Of records
Request type.. n
14
Step1a Identify Modules
15
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 users
  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)

16
Step2 Identify primary dependent variable1
Extract dependent variable1-Fields/Sections

• (that varies based on the domain nature)

17
Step2 Identify primary dependent variable2
Extract dependent variable2-Common functionality
18
Step3 Module Linkage for dependent variables
19
Step4 Final regression plot
20
In Practice..
21
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

22
Results
23
MBRT-Effectiveness

• Deriving primary dependent variables
• Review on derived impacts -gt 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

24
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

25
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

26
(No Transcript)