Training by ISTQB Leaders

2012 Course Calendar Training by the President of the CSTB

Training by ISTQB Leaders SELA Canada is excited to have Mr. Gary Mogyorodi, the President of the CSTB teach the following classes: 1) ISTQB Certified Tester Foundation Level Dates: January 11-13, 2012 | 9am - 5pm Course Overview: This course provides test engineers and test team leaders with the main ideas, processes, tools and skills they need in order to set themselves on a path for true testing professionalism. This hands-on course covers the major test design techniques with lecture and exercises. 2) ISTQB Certified Tester Advanced Level Test Manager Dates: January 23 - 27, 2011 | 9am - 5pm Course Overview: Being a technical manager is hard enough, but managing the testing process is a unique challenge, requiring judgment, agility, and organization. The course covers the essential tools, critical processes, significant considerations, and fundamental management skills for people who lead or manage development and maintenance test efforts. 3) ISTQB Certified Tester Advanced Level Test Analyst Dates: February 27 - March 2, 2011 | 9am - 5pm Course Overview: This training course gives detailed information on the specifics of different testing techniques: specification based techniques; defect and experience based test techniques, their characteristics, their boundaries – all is done while extending the range of their usage.

Best Practices For Regression Testing

SDLC defines that when a defect is fixed, two forms of testing are to be done on the fixed code. The first is confirmation testing to verify that the fix has actually fixed the defect and the second is a regression test to ensure that the fix itself, hasn't broken any existing functionality. It is important to note that the same principle applies when a new feature or functionality is added to the existing application. In the case of new functionality being added, tests can verify that the new features work as per the requirement and design specifications while regression testing can show that the new code hasn't broken any existing functionality.


It is possible that a new version of the application will have fixed previously reported defects as well as having new functionality. For the 'fixes' we would normally have a set of  Test Scripts (Test cases) which are run to confirm the fixes, while for the new functionalities we would have a set of  Functionality test cases.

Overtime, as the software application becomes bigger and bigger in terms of new functionality and more components are added, a regression pack, which is a bank of test cases, is developed to be run on new version of the application which is to be released.

Selecting tests for regression packs

As explained earlier, for each new release of software application, three sets of test suites are executed; Regression Tests, Release Specific Tests and Defect Test Scripts. Choosing test cases for regression packs is not a trivial exercise. Careful thoughts and attention need to be paid on choosing the sets of tests to include in the regression packs.

One would expect that as each new test case written for Release Specific Tests, they will become part of the regression pack to be executed after the next version of the code is arrived. So, in other words, the regression pack becomes bigger and bigger as more and more new versions of the code is developed. If we automate regression testing, this should not be a problem, but for a manual execution of large regression packs, this can cause time constraints and the new functionalities may not be tested due to lack of time.

These regression packs often contain tests that cover the core functionality that will stay the same throughout the evolution of the application. Having said that, some of the old test cases may not be applicable anymore as those functionalities may have been removed and replaced by new functionality. Therefore, the regression test packs need to be updated regularly to reflect changes to the application.

The regression packs are a combination of scripted tests that have been derived from the requirement specifications for previous versions of the software as well as random or ad-hoc tests. A regression test pack should, at a minimum, cover the basic workflow of typical use case scenarios. "Most Important Tests" i.e. tests which are important to the application domain should always be included in the regression packs. Successful test cases, i.e. tests which have revealed defects in the previous versions of the application are also a good candidate to be included in the regression packs.