Testing mistakes

Views:
 
     
 

Presentation Description

Presentation describes ..what are most common mistakes done by Testers and other general issues like when to stop testing,Test Strategy for tight schedule

Comments

By: dravidum (126 month(s) ago)

Hi this presentation is good, can I download it

By: tushar89 (130 month(s) ago)

I like this presentation,can i please download it?

By: puneetsharma20 (131 month(s) ago)

not Bad !! ;) ..... kidding ..... it's a very useful lesson to all the techies !!

By: sudheer_vytla (168 month(s) ago)

By: Manchanda (169 month(s) ago)

hi

See all

Presentation Transcript

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

authorStream Live Help