Download
smart testing and recycling testing n.
Skip this Video
Loading SlideShow in 5 Seconds..
Smart Testing and Recycling Testing PowerPoint Presentation
Download Presentation
Smart Testing and Recycling Testing

Smart Testing and Recycling Testing

164 Vues Download Presentation
Télécharger la présentation

Smart Testing and Recycling Testing

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Smart Testing and Recycling Testing Aarti Gupta

  2. Why this topic ? • Testing process is tedious, elaborate BUT is necessary. • How we currently test our system • Acceptance testing • Regression testing • Value based tests first • Check on boundary conditions • Equivalence partitioning • Requirements to test case mapping

  3. Testing lifecycle • Concurrent testing with development • Testing features based on iterations and value of the tests. • Ok so I am the tester, the developers have not finished working on the functionalities yet, what do I test ? • How do I co-ordinate the tests to be conducted, and determine the best, (most stable) time to test the system ? • When do I automate tests?

  4. Why developer-tester co-ordination is difficult. Solution that ICM suggests- Role and responsibility of project manager to team developers and testers. • “us” verses ‘them” • Multiple developers • Evolving, unstable interfaces • Concurrent work schedules • Only one environment • Delay in implementing functionalities “as planned”. • No formal process in place

  5. How can you be a smart tester? We tried, and I am sure you did too.

  6. Introduction of testing milestones within iterations.

  7. Proposed Milestones • Milestone 1: Feature complete: • completion of development of the code and test cases related to the promised features in the given iteration • Testing-Code Freeze 1: • Use this period to build automated test scripts. • Milestone 2: Code complete: stop writing code, and concentrate only on bug fixes • Testing-Code Freeze 2: no code check ins, concentrate on automated script rebuilding. • Milestone 3: Development ‘Code Freeze’: all major bug fixes complete, from hereon either minor fixes or “wont fix.” • Testing code Freeze 3: automated test scripts must be completed, refined, reported. • Milestone 4: Internal Alpha Testing: Ad-hoc testing and scenario based testing is carried out. Encourage all success critical stakeholders to test internal product.

  8. Wait! How is this recycling? • Recycling, the act of processing used or abandoned materials for use in creating new products. • We can both reduce and recycle testing, by test automation. • Automation has become easy, with the use of “Front end based” automation tools like evalid. We already use these in this class. • But do we recycle? • Did you know that an automated test written, prior to a change in code, is bound to fail. Processing and eliminating these errors is difficult and time consuming. Writing new tests is always simpler than editing older ones. • The “testing code freeze” gives the tester, frequent and stable script building time, where tests developed in a previous milestone are now refined, to the much more stable version, since certain functionalities have been frozen and completed. • Regression-…Did we break anything, by this fix/build? Wait! You don’t need to perform all tests again, simply run your automated scripts.

  9. Benefits • Prevents wasted effort • Fine-grains the planning of each iteration, all features within an iteration, may have the same value ,but different developers may be on different notes. Milestones bring them back on the road! • The iteration plan lays down a specific, list of expected features within each iteration, and these milestones specify the degree of expected readiness of the features • If a feature is not ready past code complete, then re-scope. • Prevents delay in deadlines and convergence from concurrent testing and development to waterfall based approach. • Prevents loss or overlooking of bugs, generally caused by constant changes in code configurations, due to which some bugs may not be reproducible.

  10. How do “we” tackle bugs, as opposed to “I” THE ‘TRI’AGE

  11. Manager-Technical Lead-Tester • “Triage is actually a French word meaning “Sorting.” In medical triage, patients, on a battlefield or at the scene of an emergency, are evaluated to determine which are in need of immediate care, and which can wait. • These three stakeholders meet primarily to discuss the status of open bugs, which bugs need to be fixed first, in terms of “Priority and Severity”. • “ Sort ” your open bugs, developers and testers may have conflicting understanding of the bug itself. • PM bridges the gap. • Bugs with same priority should be fixed by solving the most severe, and then least costly ones first. • developers commit to which functionality is ready to test, and the testers go ahead and test those functionalities, until the list is updated in the next triage.

  12. Benefits of TRI-AGE • Key stakeholders are now on the same page, specially for the most contradictory issue- BUGS • PM can revise cost estimates based on information gained about project delays and effort required to fix bugs. • Triage increases team coordination and teaming of testers and developers. • Lays down expectations from both the developers and the testers, and helps in fine grained planning of each iteration • Most importantly- Triage tells testers, “When to test a functionality”

  13. Do these improvements blend in with IICM in 577 a, b ? • Yes, because COCOMO cost estimates can be updated more frequently and more accurately. • Value based Testing spread sheet can be used in TRI-ages. • Lay emphasis on value based testing. • Involve key stakeholders. • Still use the iteration plan, simply more fine grained with milestones.