Static testing
Elena Rudovol
February, 13, 2014
Sitecore. Compelling Web Experiences
What is static testing?
Static Testing do not execute code.
Review work documents:
It manually checks work documents to find errors in early stage.
•
•
•
•
•
•
•
•
•
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
www.sitecore.net
Page 2
Sitecore. Compelling Web Experiences
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)
www.sitecore.net
Page 3
Sitecore. Compelling Web Experiences
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 measurable in terms of specific values (e.g. “response in 2 seconds” instead of “works fast”),
should be related to project goal,
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),

BDD is a good approach for writing good specification. It includes all best practices above.
Use techniques of model-based testing in requirements (decision tables, state transition diagrams),
Supplement with examples of scenarios how to use a system,
www.sitecore.net
Page 4
Sitecore. Compelling Web Experiences
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
www.sitecore.net
Page 5
Sitecore. Compelling Web Experiences
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.
www.sitecore.net
Page 6
Sitecore. Compelling Web Experiences
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.
www.sitecore.net
Page 7
Sitecore. Compelling Web Experiences
LCOM4 metric
Lack of Cohesion of Methods (LCOM4) metric:
The more cohesion the higher probability to fail if functionality is changed.
Good LCOM4 example:
public class ClientData
{
public string FirstName;
public string LastName;
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 GetFullName()
{
return this.FirstName + " " + this.LastName;
}
public string GetFullAddress()
{
return this.Street + " " + this.City + " " + this.ZipCode;
}
public class ClientAddress
{
public string Street;
public string City;
public string ZipCode;
public string GetFullAddress()
{
return this.Street + " " + this.City + " " + this.ZipCode;
}
}
}
www.sitecore.net
Page 8
Sitecore. Compelling Web Experiences
Package tangle index metric
Package tangle index:
Dependencies should flow in one direction. No cyclomatic dependencies.
Example:
UI
Business
logic
www.sitecore.net
Database
Page 9
Sitecore. Compelling Web Experiences
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
www.sitecore.net
Page 10
Sitecore. Compelling Web Experiences
Static Testing Techniques
Benefits of reviews:


Development productivity improvement


Reduced testing time and cost


Reduced fault levels
Reduced development timescales
Lifetime cost reductions
Improved customer relations etc.
www.sitecore.net
Page 11
Sitecore. Compelling Web Experiences
Code review in Sitecore
www.sitecore.net
Page 12
Sitecore. Compelling Web Experiences
Code review in Sitecore
Demo & questions
www.sitecore.net
Page 13