Software Testing Foundations Part 3 - Static Testing


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software Testing Foundations Part 3 - Static Testing

  1. 1. Software Testing Foundations #3Static TestingNikita Knyshnknysh@gmail.com
  2. 2. Agenda• Reviews• Static Analysis
  3. 3. Reviews in brief figures• Cost of reviews is 10-15% of development budget• Savings are about 14-25% (calculation includes review efforts).• More than 70% of defects in documents can be found before they go to next work steps.
  4. 4. Review Objective and TypesObjective• To decide if the review object has met the requirements and complies with the standards, as well as to find defects.Major types of reviews:• Reviews of tech products• Project review aka Management review
  5. 5. Review Steps• Planning• Overview (Kick-off)• Preparation• Review Meeting (Examination)• Re-work• Follow-up
  6. 6. Review Roles• Manager• Moderator• Author• Reviewer (Inspector)• Recorder
  7. 7. Review Types• Walkthrough• Inspection• Technical review• Informal review
  8. 8. Review Type: Walkthrough• Informal procedure where author presents document to reviewers (and chairs the meeting).• Main focus is on meeting.• Preparation is smallest among review types or omitted; follow-up is optional.• Suitable for small teams (<=10 members). Can be used for checking ‘non-critical’ documents.
  9. 9. Review Type: Inspection• Most formal review process – uses formal evaluation criteria.• Checklists with formal inspection criteria (entry- and exit-criteria) are used.• Focus: finding unclear points and possible defects, measuring document quality, improving quality of the product, development and inspection processes.• Follow-up and re-inspection are formally regulated.
  10. 10. Review Type: Technical Review• Focus: assessing document’s compliance with specification, fitness for its intended purpose and compliance to standards.• Some of reviewers should not be project participants. Management does not participate.• Based on only ‘official’ specs and specified review tasks.• Most effort lies in the preparation work.• Review meeting normally not attended by author.• Consequences of review result are decided by management but not by review participants.
  11. 11. Review Type: Informal Review• Follows general review procedure in a simplified way. Usually initiated by author.• Is a kind of cross-read of one or more colleagues.• Examples: pair programming, buddy testing, code swapping.• Results should not be explicitly documented – a list of remarks or revised document is enough.• Very common review type. Takes little effort.
  12. 12. Static Analysis• Commonly, only program code can be static-analyzed, but sometimes there are also models (UML). Outputs in e.g. XML or HTML can be static-analyzed as well.• Only makes sense with support of tools – documents must follow certain formal structure.• Best practice is to perform it before review as it is automated and so cheaper to perform.• Usually practiced by developers in component (by coding guidelines) and integration (by interface guidelines) testing.
  13. 13. Flaws Detected by Static Analysis• Syntax violation• Deviation from conventions and standards• Control flow anomalies• Data flow anomalies
  14. 14. Data Flow AnalysisVariables can be defined (d), referenced (r) andundefined (u).Anomalies:• ur – undefined then read or used• du – defined then gets invalid or undefined without use• dd – defined twice without use of first value
  15. 15. Control Flow Analysis• Cyclomatic (McCabe) number: c(G) = e – n + 2 where e - graph edges, n - graph nodes.• If c(G) > 10 then rework of program code needed.• c(G) specifies number of independent paths in the program part.• c(G) used to estimate testability & maintainability.
  16. 16. Thank you!