1 / 13

Software Testing

Static Technique. Software Testing. Static Technique - Review. A way of testing software work products Program code, requirement spec., design spec. Test plan, test design, test cases, test script, user guides Early defect detection and correction of software development

katima
Download Presentation

Software Testing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Static Technique Software Testing

  2. Static Technique - Review • A way of testing software work products • Program code, requirement spec., design spec. • Test plan, test design, test cases, test script, user guides • Early defect detection and correction of software development • Development productivity improvements, reduce development time, reduce testing cost and time • Fewer defects and improved communication • Reviews, static analysis and dynamic testing have the same objective – identifying defects • Reviews : find the cause of failures (defect) rather the defect themselve • Static analysis : complexity of code, error in statement, missing parameter, Dead code etc.

  3. Static Technique - Reviews Static Technique Manual Review Static Analysis Formal Review Informal Review Inspection Walkthrough Informal Review Technical Review

  4. Why Review • More efficient detecting defects in review that in dynamic test • Component test period; 2-4 findings per hour • Code review; 6-10 findings per hour • Cost of fixing defects after component test level • 10-14 m/h for finding and fixing defects during integration or system test level • 1 m/h for finding and fixing defect during Inspection • Time and cost efficiency when quick defect correction

  5. Reasons of review • Effective defects detecting • Gaining understanding of documentation • Determining and deciding through the discussion • When auditing is planned • Satisfying requirement or compliance • Needed to be high quality in developing process

  6. Review – roles and responsibility • Manager • Decide on the execution of reviews, allocates time in project schedules and determine if the review objectives had been met • Moderator • Leads the review of the document, planning the review and running the meeting and follow-up after meeting • Author • The writer or person with chief responsibility of the document(s) to be reviewed • Reviewers • Checkers or inspectors • Reviewers should be chosen to represent different perspectives and roles in the review process • Scribe (recorder) • Documents all the issues, problems and open points

  7. Review Process

  8. Informal vs. formal review

  9. Types of review – Informal review • No formal process • There may be pair programming or technical lead reviewing designs and codes • Optionally may be documented • May vary in usefulness depending on the reviewer • Main purpose – inexpensive way to get some benefit

  10. Types of review – Walkthrough • Meeting led by author • Scenarios, dry runs, peer group • Open-ended sessions • Optionally a pre-meeting preparation of reviewers, review report, list of findings and scribe • May vary in practice from quite formal to very formal • Main purporse : learning, gaining understanding, defect finding

  11. Types of review – technical review • documented, defined defect-detection process that includes peers and technical experts; • may be performed as a peer review without management participation; • ideally led by trained moderator (not the author); • pre-meeting preparation; • optionally the use of checklists, review report, list of findings and management participation; • may vary in practice from quite informal to very formal; • main purposes: discuss, make decisions, evaluate alternatives, find defects, solve technical • problems and check conformance to specifications and standards

  12. Types of review - Inspection • led by trained moderator (not the author); • usually peer examination; • defined roles; • includes metrics; • formal process based on rules and checklists with entry and exit criteria; • pre-meeting preparation; • inspection report, list of findings; • formal follow-up process; • optionally, process improvement and reader; • main purpose: find defects.

  13. Success factors for reviews Each review has a clear predefined objective. The right people for the review objectives are involved. Defects found are welcomed, and expressed objectively. People issues and psychological aspects are dealt with (e.g. making it a positive experience for the author). Review techniques are applied that are suitable to the type and level of software work products and reviewers. Checklists or roles are used if appropriate to increase effectiveness of defect identification. Training is given in review techniques, especially the more formal techniques, such as inspection. Management supports a good review process (e.g. by incorporating adequate time for review activities in project schedules). There is an emphasis on learning and process improvement.

More Related