Slide1: Testing Mistakes & General issues


Classic Testing Mistakes...: Classic Testing Mistakes... The Role of Testing - Thinking that the purpose of testing is to find more number of bugs with less criticality - Not Reporting Usability Problems - Reporting improper bug details - Sticking to complete the whole test plan


Classic Testing Mistakes...: Classic Testing Mistakes... Planning the complete testing effort - Underestimation of Test Setup Time and Break down time - Documentation of testing not taken in to account in effort estimation - Not planning properly for the parallel activities


Classic Testing Mistakes...: Classic Testing Mistakes... Personnel Issues - Using testing as transitional to become programmers - Physical separation between Developer and Testers - Programmers are neither trained nor motivated to test


Classic Testing Mistakes...: Classic Testing Mistakes... The Tester at Work - Executing test plans blindly without understanding the application - Writing test plans which are understandable only to the owner - Failing to take notes to improve the test cases in Regression testing


Classic Testing Mistakes: Classic Testing Mistakes Test Automation - Attempting to Automate all Tests - Expecting to rerun Manual Tests - Improper Customization of Recorded Test Scripts through Automation Tools - Hard coding of test data and reference file paths


Test Strategy for Tight Schedule..: Test Strategy for Tight Schedule.. Which functionality is most important Which functionality is most visible to user Which functionality have largest safety impact Which aspects of the application can be tested early in the development cycle Which part of the code is more complex


Test strategy for Tight Schedule..: Test strategy for Tight Schedule.. Which part of the application is developed in panic Which aspects of similar / related previous projects caused problems Which part of the project had large maintenance expenses Test weak developer modules


Test strategy for Tight schedule..: Test strategy for Tight schedule.. Which part of the requirements are poorly documented What kind of problems would cause the worst publicity Which tests will have the best high risk coverage to time required ratio


Strategy for Frequent Changes in Requirements...: Strategy for Frequent Changes in Requirements... Work with project management early on to understand how requirements might change so that alternate test plan strategies can be worked out in advance Use rapid prototyping whenever possible to help customers feel sure of their requirements and minimize changes


Strategy for Frequent changes in Requirements...: Strategy for Frequent changes in Requirements... Try to move new requirements to Phase 2 or Next Version of an application Negotiate to allow only easily implemented new requirements in the project Ensure that Customer and Management understand the scheduling impact, inherent risks and costs of significant changes


Strategy for Frequent changes in Requirements: Strategy for Frequent changes in Requirements Try to concentrate more on Automation testing efforts Spend time in Risk Analysis of changes to minimize Regression test efforts Focus less time in writing Test Plans and more on Ad hoc Testing


Comparison of Desktop, Web and System Software...: Comparison of Desktop, Web and System Software... Risk Involved : Low - Medium - High Testing Efforts : Low - Medium - High HW/SW Requirements : Minimum - Moderate - Complex Preparation of Test Plans : Less Efforts - Moderate - High Efforts No. Of Tests : Low - High - High


Comparison of Desktop, Web and System Software: Comparison of Desktop, Web and System Software Test Environment : Simple - More Complex - Medium Complex Dependency on Hardware : Little - High - High Implementation of Change : Simple - More Complex - Medium Complex Un-Known Areas : Minimum - Maximum - Moderate


When to stop Testing: When to stop Testing Deadlines are reached Test cases are completed Test Budget depleted Bug rate falls below a certain level Meeting Testing criteria