1. Module Based Regression Test Selection Strategy for Web applications Author: Annamariale Chandran Honeywell Technology Solutions For International Conference on Software Engineering 19 th Dec 2009

2. Software Life cycle Requirements Specification Document Design Document Implementation Source Code Acceptance Testing Final System Maintenance Software Requirements High Level Design Low Level Design Unit/Integration testing Unit Test cases System testing System Test cases Update Traceability

3. Testing Vs Regression Testing Testing aided by Requirement spec & design document Regression aided by Collation of available artifacts and proper impact Analysis 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 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 -> 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 Should reduce test design time Should reduce application knowledge transfer time Should provide inputs on impact to pre- system phases to improve DRE Quality of derived Impacts Productivity factor in achieving the quality

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 Current Difficulties Expectations 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. Basis -> 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 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. Future value of dependent Variable (any change) is Identified in terms of its related dependent variables

12. Regression Logic Module relation with primary dependent variables y(m) = f(x(p), β) -----------------(1) Where, y(m) -> modules derived in the application under test x(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) Where Yd(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)

13. Sample Application Employee Request Management System Login Request type1 Request type2 Request type3 Request type.. n User applying for specific request Approval Process Keep track Of records Start End

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 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)

16. Step2: Identify primary dependent variable1 (that varies based on the domain nature) Extract dependent variable1-Fields/Sections

17. Extract dependent variable2-Common functionality Step2: Identify primary dependent variable2

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 -> 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