static testing1
DESCRIPTION
static testing techniqueTRANSCRIPT
Static testingElena Rudovol
February, 13, 2014
Sitecore. Compelling Web Experiences
www.sitecore.net Page 2
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• 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
Sitecore. Compelling Web Experiences
www.sitecore.net Page 3
Static VS dynamic testing
Note: Both types of testing are important.
Static testing Dynamic testing
Without executing the program By executing the program
Verification process Validation process
Prevention of defects Finding and fixing the defects
Evaluates code/documentation Finds dugs/bottlenecks in the system
Cost of defect is less Cost of defect is high
Return on investment will be high (early stage) Return on investment will be low (after development phase)
Sitecore. Compelling Web Experiences
www.sitecore.net Page 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 examples of scenarios how to use a system,
BDD is a good approach for writing good specification. It includes all best practices above.
Sitecore. Compelling Web Experiences
www.sitecore.net Page 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
Sitecore. Compelling Web Experiences
www.sitecore.net Page 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.
Sitecore. Compelling Web Experiences
www.sitecore.net Page 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.
Sitecore. Compelling Web Experiences
www.sitecore.net Page 8
LCOM4 metric
Lack of Cohesion of Methods (LCOM4) metric:
The more cohesion the higher probability to fail if functionality is changed.
Bad LCOM4 example:
public class Client
{
public string FirstName;
public string LastName;
public string Street;
public string City;
public string ZipCode;
public string GetFullName()
{
return this.FirstName + " " + this.LastName;
}
public string GetFullAddress()
{
return this.Street + " " + this.City + " " + this.ZipCode;
}
}
Good LCOM4 example:
public class ClientData
{
public string FirstName;
public string LastName;
public string GetFullName()
{
return this.FirstName + " " + this.LastName;
}
}
public class ClientAddress
{
public string Street;
public string City;
public string ZipCode;
public string GetFullAddress()
{
return this.Street + " " + this.City + " " + this.ZipCode;
}
}
Sitecore. Compelling Web Experiences
www.sitecore.net Page 9
Package tangle index metricPackage tangle index:
Dependencies should flow in one direction. No cyclomatic dependencies.
Example:
UI Business logic Database
Sitecore. Compelling Web Experiences
www.sitecore.net Page 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
Sitecore. Compelling Web Experiences
www.sitecore.net Page 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.
Sitecore. Compelling Web Experiences
www.sitecore.net Page 12
Code review in Sitecore
Sitecore. Compelling Web Experiences
www.sitecore.net Page 13
Code review in Sitecore
Demo & questions