1 / 13

Static testing Elena Rudovol February, 13, 2014

Static testing Elena Rudovol February, 13, 2014. What is static testing?. Static Testing do not execute code. It manually checks work documents to find errors in early stage . Review work documents: Requirement specifications Design document Source Code Test Plans Test Cases

eldora
Download Presentation

Static testing Elena Rudovol February, 13, 2014

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 testing Elena Rudovol February, 13, 2014

  2. What is static testing? Static Testingdo not execute code. It manually checks work documents to find errors in early stage. • Review work documents: • Requirement specifications • Design document • Source Code • Test Plans • Test Cases • Test Scripts • Help or User document • Web Page content • … Static Testing Techniques (ISTQB): Individual: - desk-checking, data-stepping, proof-reading  Group: - Reviews (informal & formal): for consensus - Walkthrough (guide a group): for education - Inspection (most formal): to find faults

  3. Static VS dynamic testing Note: Both types of testing are important.

  4. Requirements specification review “Most of the bugs in software are due to incomplete or inaccurate functional requirements” Requirements: • should be clear and specific with no uncertainty, • should be related to project goal, • should be measurable in terms of specific values (e.g. “response in 2 seconds” instead of “works fast”), • should be testable having some evaluation criteria for each requirement, • should be complete and consistent, without any duplicates and missing requirements Good practices: • Write good-structured requirements or user stories (easy-to-find), • Use techniques of model-based testing in requirements (decision tables, state transition diagrams), • Supplement with examplesof scenarios how to use a system, • BDD is a good approach for writing good specification. It includes all best practices above.

  5. Why do we need manual code review? • Knowledge sharing: • Easier to make bug-fix • Easier to get started for newcomers • Easier to support the code • Less work in the future: • Less amount of mistakes • Less time to understand the code • Easier to support the code • Adoption: • Frequently changed requirements require fast adoption to them

  6. Manual code review Main goals: • Finding potential bugs on the cheap: • “obvious” mistakes, • mistakes that difficult to find “after-the-fact” (e.g. thread synchronization, resource leaks etc.), • ensuring that unit tests cover all code paths, • Well-documented software: • consistent end-user documentation (It’s important for Sitecore to provide well-documented API!), • adequate comments in code, • Software that complies with enterprise coding standards: • following code standards and OOP practices, • no “anti-patterns” in code and database structure, • Teaching and sharing knowledge between developers. Good practices: • review can to be done by any team member (not only lead developer), • add a status “Ready for Review” into bug-tracking system.

  7. Main metrics in Sonar Code coverage - % of code which is covered by unit tests: • Line Coverage - % of rows which run and tested (e.g. 80%) • Branch coverage - % of conditionals (true/false) run and tested (e.g. 80%) Branch coverage is more important because it shows real coverage of business logic Comments in code: • API should be well documented (feedback from marketing department) • tools for comments generating (e.g. GhostDoc, Doxygen) • most public methods should be documented (E.g. metric is 80%) • no commented rows in code Duplications: We should achieve 0% of copy-paste in code. Violations: We should pay attention on Sonar violations and fix blockers, critical and major.

  8. LCOM4 metric Lack of Cohesion of Methods (LCOM4) metric: The more cohesion the higher probability to fail if functionality is changed.

  9. Package tangle index metric Package tangle index: Dependencies should flow in one direction. No cyclomatic dependencies. Example:

  10. Code complexity The complexity is measured by the number of if, while, do, for, ?:, catch, switch, case statements, and operators && and || (plus one) in the body of a constructor, method, static initializer, or instance initializer. Complexity = number of decisions + 1. E.g. Following flow has complexity 3. Generally: - up to 7 for method - up to 15 for class

  11. Static Testing Techniques Benefits of reviews: • Development productivity improvement • Reduced development timescales • Reduced testing time and cost • Lifetime cost reductions • Reduced fault levels • Improved customer relations etc.

  12. Code review in Sitecore

  13. Code review in Sitecore Demo & questions

More Related