SlideShare a Scribd company logo
1 of 44
Download to read offline
Regression Testing in an Agile World
Angela Goodbar Mellanie Taylor
About Us
2
Angela
• Manual Software Test
Engineer for the Sample
Processing team
• Team Lead for the
Sample Processing Lab
sub-team
• Myridian for 7 years
• Testing software for 10+
years
• Enjoy wakeboarding and
being Grandma!
Mellanie
• Manual Software Test
Engineer for the Result
Generation Team
• Myriadian for 9 years
• Testing for 5+ years
• Salsa aficionado
• Future Carny
To Be Covered
3
1. WHAT is Regression Testing?
2. WHY we should Regression Test
3. CHALLENGES of fitting Regression
Testing into our Agile processes
4. HOW we can be more effective
5. WHEN we should Regression Test
6. WHERE we should Regression Test
7. WHO should Regression Test
WHAT is Regression Testing?
5
Regression Testing is the re-testing
of a previously tested program
following modification to ensure
that faults have not been
introduced or uncovered as a
result of the changes made.
What
Why
How
When
Where
Who
WHY we should Regression Test
7
What
Why
How
When
Where
Who
Fix One Bug,
Introduce New Ones
8
Trust
What
Why
How
When
Where
Who
9
Avoid Rollbacks &
Emergency Fixes
What
Why
How
When
Where
Who
CHALLENGES of fitting Regression Testing
Into our Agile processes
11
Time
Cut Corners
12
Habit
13
Documentation Overload
14
HOW we can be more effective
Automation
• To get early and instant feedback
• Regression tests only
• Safety net to save time which is reinvested
into manual testing
• NOT to replace manual testing
16
What
Why
How
When
Where
Who
Know What Was Changed
17
What
Why
How
When
Where
Who
Utilize Risk Based Testing
18
What
Why
How
When
Where
Who
1. Test fixes promptly
2. Watch for side
effects of fixes
3. Write a regression
test for each bug
fix
19
What
Why
How
When
Where
Who
Build & Groom your Test Suite
1. Get rid of less
effective tests
2. Identify tests that
consistently pass
and archive them
3. Focus on
Function, not
Design
20
What
Why
How
When
Where
Who
Run Every Test
21
What
Why
How
When
Where
Who
Pare Down the Details
22
What
Why
How
When
Where
Who
WHEN we should Regression Test
Any Modification
24
What
Why
How
When
Where
Who
Part of the SDLC
25
What
Why
How
When
Where
Who
Each Time a
Feature is Completed
26
What
Why
How
When
Where
Who
WHERE we should Regression Test
Consistent Location
28
What
Why
How
When
Where
Who
Test Management Tool
29
What
Why
How
When
Where
Who
WHO should Regression Test
Developer
31
What
Why
How
When
Where
Who
Automation Test Engineer
32
What
Why
How
When
Where
Who
Manual Test Engineer
33
What
Why
How
When
Where
Who
Summary
The retesting of a previously tested
program following modification to
ensure that faults have not been
introduced or uncovered as a result of
the changes made.
WHAT is Regression Testing?
35
What
Why
How
When
Where
Who
WHY should we
Regression Test?
36
1. Catch new or re-introduced bugs in
unchanged areas
2. Maintain trust
3. Avoid Rollbacks and Emergency Fixes
What
Why
How
When
Where
Who
WHAT are the Challenges?
37
1. Time
2. Cut Corners
3. Habit
4. Documentation Overload
HOW can we be
more effective?
38
1. Automation
2. Know What Was Changed
3. Utilize Risk Based Testing
4. Build & Groom your Test Suite
5. Run Every Test
6. Pare Down The Details
What
Why
How
When
Where
Who
WHEN should we
Regression Test?
1. Any modification
2. Part of the Release Cycle
3. Each time a feature is complete
39
What
Why
How
When
Where
Who
WHERE should we
Regression Test?
1. Consistent Location
2. Test Management Tool
40
What
Why
How
When
Where
Who
WHO should
Regression Test?
1. Developer
2. Automation Test Engineer
3. Manual Test Engineer
41
What
Why
How
When
Where
Who
1. http://www.softwaretestingtricks.com/2007/03/how-important-is-
regression-testing.html
2. http://www.softwaretestinghelp.com/regression-testing-tools-
and-methods/
3. http://msdn.microsoft.com/en-
us/library/aa292167(v=vs.71).aspx
4. http://www.stickyminds.com/article/test-documenting-over-cliff
5. http://www.wrox.com/WileyCDA/Section/Regression-Testing.id-
291252.html
6. https://blog.frogslayer.com/manual-regression-testing-and-test-
cases/
7. http://www.softwaretestinggenius.com/know-the-regression-
testing-and-its-best-practices
References
42
DISCUSSION
THANK YOU

More Related Content

More from Informatics Summit

PSYCHOLOGY, MOTIVATION AND THE SOFTWARE ENGINEER
PSYCHOLOGY, MOTIVATION AND THE SOFTWARE ENGINEERPSYCHOLOGY, MOTIVATION AND THE SOFTWARE ENGINEER
PSYCHOLOGY, MOTIVATION AND THE SOFTWARE ENGINEERInformatics Summit
 
BUSINESS INTELLIGENCE — HOW DATA DRIVES BUSINESS
BUSINESS INTELLIGENCE — HOW DATA DRIVES BUSINESSBUSINESS INTELLIGENCE — HOW DATA DRIVES BUSINESS
BUSINESS INTELLIGENCE — HOW DATA DRIVES BUSINESSInformatics Summit
 
READING THE HUMAN GENOME IS HARD WORK!
READING THE HUMAN GENOME IS HARD WORK!READING THE HUMAN GENOME IS HARD WORK!
READING THE HUMAN GENOME IS HARD WORK!Informatics Summit
 
THE SCIENCE AND ART OF BACKWARDS COMPATIBILITY
THE SCIENCE AND ART OF BACKWARDS COMPATIBILITYTHE SCIENCE AND ART OF BACKWARDS COMPATIBILITY
THE SCIENCE AND ART OF BACKWARDS COMPATIBILITYInformatics Summit
 
GENETIC VARIANTS: SIMPLE ENOUGH FOR MY DAUGHTER’S 4TH GRADE CLASS
GENETIC VARIANTS: SIMPLE ENOUGH FOR MY DAUGHTER’S 4TH GRADE CLASSGENETIC VARIANTS: SIMPLE ENOUGH FOR MY DAUGHTER’S 4TH GRADE CLASS
GENETIC VARIANTS: SIMPLE ENOUGH FOR MY DAUGHTER’S 4TH GRADE CLASSInformatics Summit
 
Informatics Summit Oct, 30 2015
Informatics Summit Oct, 30 2015Informatics Summit Oct, 30 2015
Informatics Summit Oct, 30 2015Informatics Summit
 

More from Informatics Summit (7)

PSYCHOLOGY, MOTIVATION AND THE SOFTWARE ENGINEER
PSYCHOLOGY, MOTIVATION AND THE SOFTWARE ENGINEERPSYCHOLOGY, MOTIVATION AND THE SOFTWARE ENGINEER
PSYCHOLOGY, MOTIVATION AND THE SOFTWARE ENGINEER
 
LOGGING FOR FUN, AND PROFIT
LOGGING FOR FUN, AND PROFITLOGGING FOR FUN, AND PROFIT
LOGGING FOR FUN, AND PROFIT
 
BUSINESS INTELLIGENCE — HOW DATA DRIVES BUSINESS
BUSINESS INTELLIGENCE — HOW DATA DRIVES BUSINESSBUSINESS INTELLIGENCE — HOW DATA DRIVES BUSINESS
BUSINESS INTELLIGENCE — HOW DATA DRIVES BUSINESS
 
READING THE HUMAN GENOME IS HARD WORK!
READING THE HUMAN GENOME IS HARD WORK!READING THE HUMAN GENOME IS HARD WORK!
READING THE HUMAN GENOME IS HARD WORK!
 
THE SCIENCE AND ART OF BACKWARDS COMPATIBILITY
THE SCIENCE AND ART OF BACKWARDS COMPATIBILITYTHE SCIENCE AND ART OF BACKWARDS COMPATIBILITY
THE SCIENCE AND ART OF BACKWARDS COMPATIBILITY
 
GENETIC VARIANTS: SIMPLE ENOUGH FOR MY DAUGHTER’S 4TH GRADE CLASS
GENETIC VARIANTS: SIMPLE ENOUGH FOR MY DAUGHTER’S 4TH GRADE CLASSGENETIC VARIANTS: SIMPLE ENOUGH FOR MY DAUGHTER’S 4TH GRADE CLASS
GENETIC VARIANTS: SIMPLE ENOUGH FOR MY DAUGHTER’S 4TH GRADE CLASS
 
Informatics Summit Oct, 30 2015
Informatics Summit Oct, 30 2015Informatics Summit Oct, 30 2015
Informatics Summit Oct, 30 2015
 

Recently uploaded

Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Adtran
 
GenAI and AI GCC State of AI_Object Automation Inc
GenAI and AI GCC State of AI_Object Automation IncGenAI and AI GCC State of AI_Object Automation Inc
GenAI and AI GCC State of AI_Object Automation IncObject Automation
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxMatsuo Lab
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.francesco barbera
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8DianaGray10
 
Introduction to Quantum Computing
Introduction to Quantum ComputingIntroduction to Quantum Computing
Introduction to Quantum ComputingGDSC PJATK
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationIES VE
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer ServicePicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer ServiceRenan Moreira de Oliveira
 
Spring24-Release Overview - Wellingtion User Group-1.pdf
Spring24-Release Overview - Wellingtion User Group-1.pdfSpring24-Release Overview - Wellingtion User Group-1.pdf
Spring24-Release Overview - Wellingtion User Group-1.pdfAnna Loughnan Colquhoun
 
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataCloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataSafe Software
 

Recently uploaded (20)

Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™Meet the new FSP 3000 M-Flex800™
Meet the new FSP 3000 M-Flex800™
 
GenAI and AI GCC State of AI_Object Automation Inc
GenAI and AI GCC State of AI_Object Automation IncGenAI and AI GCC State of AI_Object Automation Inc
GenAI and AI GCC State of AI_Object Automation Inc
 
Introduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptxIntroduction to Matsuo Laboratory (ENG).pptx
Introduction to Matsuo Laboratory (ENG).pptx
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.Digital magic. A small project for controlling smart light bulbs.
Digital magic. A small project for controlling smart light bulbs.
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8
 
Introduction to Quantum Computing
Introduction to Quantum ComputingIntroduction to Quantum Computing
Introduction to Quantum Computing
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer ServicePicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
 
Spring24-Release Overview - Wellingtion User Group-1.pdf
Spring24-Release Overview - Wellingtion User Group-1.pdfSpring24-Release Overview - Wellingtion User Group-1.pdf
Spring24-Release Overview - Wellingtion User Group-1.pdf
 
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataCloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
 

REGRESSION TESTING IN AN AGILE WORLD

Editor's Notes

  1. It is important to do regression testing frequently, because the code as a whole may easily "regress" to a lower level of quality after making a change. Regression testing is necessary, even though a change appears to be working correctly and is believed not to affect the rest of the software. When we regression test, we re-execute previously ran tests and compare current results with those previously executed.
  2. When you fix one bug, new bugs can be introduced. Regression testing decreases bugs escaped to production. The rate of defect introduction is quite high. It is always best to identify the underlying cause and understand how the software is used rather than tackling the symptom. Not to mention the time spent chasing and resolving bugs introduced.
  3. If software is deployed to production without regression testing, and new bugs are introduced, or old bugs are re-introduced, the trust the users have for developers and testers is damaged.
  4. Regression testing decreases rollbacks and emergency fixes to production, which (admit it) is embarrassing.
  5. If regression testing is executed manually, it takes more and more time testing every day, every iteration. In order for testing to keep pace with coding, either the developers have to take time to help with manual regression, or the team has to hire more testers. In case of limited time, try to purchase more time. Consider turning the testing over for UAT while continuing regression testing. If you are not able to get more time, inform in advance about the inability to cover possibly risky areas.
  6. If the team is facing a tight deadline, there’s a temptation to cut corners, and the result is a missed problem.
  7. When iterations don’t proceed smoothly and the team can’t complete all of the development and testing tasks by the end of the iteration, team members may panic. It has been observed that when people go into panic mode, they fall into comfortable old habits, even if those habits never produced good results.   Example: “We are supposed to deliver on February 1. If we want to meet that date, we don’t have time to execute all the regression tests; let alone write new ones. We’ll have to run what can be done in that amount of time and hope for the best. We can always write the regression tests later.”   This is the road to perdition. Some tests get ran, but maybe not the important tests that would have found the bug that cost the company hundreds of thousands of dollars in lost sales. Then, because we didn’t finish with our testing documentation tasks, those tasks carry over to the next iteration, reducing the amount of business value we can deliver. As iterations proceed, the situation continues to deteriorate.
  8. Unless you're in a test role where full, complete documentation is necessary in order to be federally compliant or to keep people from dying or losing a limb, attempting to document every little thing is a fool's errand. Software changes. A lot. With constant change, what we document one day may be obsolete the next. The overload exists right at the point where we've documented so many manual regression tests that the test suite is no longer manageable, so testers don't run the tests at all. Whatever value we're seeking to generate with all those artifacts doesn't just taper off at that point, it nosedives into oblivion.    All documented manual regression tests should be ran in each major round of regression testing. Many teams have hundreds of regression tests that required hundreds of man-hours to write, yet the tests sit around collecting dust like cheap trinkets at a yard sale. What value does a so-called regression test have if we don't need to run it in every major regression run?
  9. Agile development cannot work without automation. Test Driven Development can help identify if a regression tests can be automated, thus eliminating the need for a manual regression test. The benefits of automated testing are significant cost and time savings. Automated tools run tests significantly faster than human testers; freeing them up to more effectively manage testing of the new components.
  10. How much regression testing is needed can be effectively decided by the tester getting input from the developer about the scope, nature and amount of change. Modularization, good design, and good record keeping can minimize regression testing. It can be argued that certain modules do not need regression if they were not changed. Knowing what was changed is essential.
  11. Adequate coverage without wasting time should be a primary consideration when conducting regression tests. Risk based testing can save many hours of testing something that has a low risk of failure. Testing the high risk areas give you the most value for your time. Once again knowing what was changed is essential.
  12. 1. Test fixed bugs promptly. The programmer might have handled the symptoms but not have gotten to the underlying cause. 2. Watch for side effects of fixes. The bug itself might be fixed but the fix might create other bugs. 3. Write a regression test for each bug fixed. Bugs commonly get re-introduced into the code.
  13. If two or more tests are similar, determine which is less effective and get rid of it. Identify tests that the program consistently passes and archive them. Focus on functional issues, not those related to design. Focus on excessively used functions (20% of functions used 80% of the time). Develop a suite of tests that can be run every time you build a new version of the program. The most difficult aspect involved in building a suite of test cases is determining which test cases to include. The most common suggestion from authorities in the field of software testing is to avoid spending excessive amounts of time trying to decide and err on the side of caution. Automated tests, as well as test cases involving boundary conditions and timing almost definitely belong in your suite. Some software development companies include only tests that have actually found bugs. The problem with that rationale is that the particular bug may have been found and fixed in the distant past.   Groom the regression test suite often to eliminate redundant or unnecessary tests. Duplication is quite common when more than one person is writing test code. An example that causes this problem is the concentration of tests that often develop when a bug or variants of it are particularly persistent and are present across many cycles of testing. Numerous tests might be written and added to the regression test library. These multiple tests are useful for fixing the bug, but when all traces of the bug and its variants are eliminated from the program, select the best of the tests associated with the bug and remove the rest from the library.   Regression test cases need to be selected very carefully so that a minimum set of test cases cover maximum functionality.   Test Design should be used to focus on the most appropriate regression tests to keep; utilizing as much automation as possible.   Next time you do a manual regression run, see how many tests were not run. Are these tests really worth keeping? Will they ever deliver any real value? What will you do with your answers—delete tests or spend more time regression testing next time? Groom the test suite to ensure regression tests remain accurate and do not get out of date due to enhancements and bug-fixes. Instead of having one large regression test, it is better to create a logical batch of unit or component test cases in a comprehensive test suite. This provides flexibility of execution in cases of urgency or time-pressure.
  14. Practicing the discipline of running every test helps avoid the messy complications of over-documentation, because it forces us to answer questions and make decisions—two tasks that excessive documentation tends to inhibit. In order to keep the regression test suite light enough that it can feasibly be run when required, testers must learn their product well enough so they can answer, "What are the most important things to test in order to supply information about the product to those who make decisions about it?" To answer this question, testers must think about the product's innards, how the components integrate with each other, the customer's needs, how the product will be used in the wild, how it is most likely to fail, and so on. It requires testers to be smart, rather than simply be able to follow dumbed-down directions for checking that the product "works" exactly as someone documented it to work in the past.
  15. Don’t over-specify the manual regression test cases. Since testers are more than animated poking sticks, we can assume that they know something about the product area they are testing, they can figure out minor details and intents, and they can form and ask questions, if needed. Indicating the intent of a test rather than specifying each and every step makes the tests more maintainable and, again, utilizes the tester's mind—creativity, experience, and intelligence. If you have bloated regression test suites and you’d like to increase the cognitive input of your test team, start by paring down the details in your existing regression test cases. Consider what value tests have that only confirm well-known details. Judge whether or not steps that were copied and pasted across multiple test cases really need to be in that many artifacts.
  16. Any time code is modified, regression testing should be done. Regression testing should be tightly linked to functional testing, and be built from the successful test cases developed and used in functional testing. The best time to write test cases for manual regression testing is when the software is still in the early stages of development. Once the functionality of the program has been set in stone, the documentation can be used as a source for the test cases. Instead of looking at an early, unfinished version of the software, use clearly defined documentation of the end-goal functionality to avoid the creation of flawed test cases.
  17. Regression testing should be the part of release cycle and must be considered in test estimation. But what if there is more than one story for a particular application?
  18. Feature acceptance, integration, and system testing are performed each time a feature is completed. Regression testing should be performed as well. If there are multiple stories for an application, regression testing should occur after all have them have been completed; and should include tests for those stories. Angela e.g. - RQ bug escape to production: Story #1: Establish RQ Path for myRisk Single Sites. Affected Amplicon, Accession and SubBatch requeues. Story #2: RQ Combined_myRisk Containers. Affected Batch, SubBatch and Container requeues. No regression was executed for Amplicon and Accession requeues because only regression for user story #2 was considered. There was a bug in Amplicon requeue that we had to address with an emergency fix. Mellanie to present MS3/SS bug caught in regression.
  19. Where do we keep and execute our regression tests? Currently, each team is different. Commercial - I drive. Word documents.
  20. When we are all consistent, it removes the guesswork out of where our regression tests and their execution results can be found.
  21. Test results need to be compared to the previous time they were ran to ensure nothing has regressed. What better tool than a test management tool that is designed for this specific purpose? List of tools:
  22. Additionally, developer-written unit tests are a part of your Regression Suite. Testers should be familiar with the unit tests to avoid duplication with a manual test case.
  23. Regression testing in an Agile shop cannot be successful without automation. The Automation Test Engineers and the tests they maintain are crucial.
  24. As a cross-functional team, anyone performing in the tester (whether Automated or Manual) role should evaluate regression needs. This could be execution, or writing regression tests.