Custom Search

Static Testing

Static Testing
 
Important Terms:
Static techniques and the test process
dynamic testing, static testing, static technique
Review process
entry criteria, formal review, informal review, inspection, metric, moderator/inspection leader, peer review, reviewer, scribe, technical review, walkthrough.
Static analysis by tools
Compiler, complexity, control flow, data flow, static analysis

I) Phases of a formal review

1) Planning
Selecting the personal, allocating roles, defining entry and exit criteria for more formal reviews etc.
2) Kick-off
Distributing documents, explaining the objectives, checking entry criteria etc.
3) Individual preparation
Work done by each of the participants on their own work before the review meeting, questions and comments etc.
4) Review meeting
Discussion or logging, make recommendations for handling the defects, or make decisions about the defects etc.
5) Rework
Fixing defects found, typically done by the author Fixing defects found, typically done by the author
6) Follow-up
Checking the defects have been addressed, gathering metrics and checking on exit criteria

II) Roles and responsibilities

Manager
Decides on execution of reviews, allocates time in projects schedules, and determines if the review objectives have been met
Moderator
Leads the review, including planning, running the meeting, follow-up after the meeting.
Author
The writer or person with chief responsibility of the document(s) to be reviewed.
Reviewers
Individuals with a specific technical or business background. Identify defects and describe findings.
Scribe (recorder)
Documents all the issues, problems


 III) Types of review

Informal review
No formal process, pair programming or a technical lead reviewing designs and code.
Main purpose: inexpensive way to get some benefit.
Walkthrough
Meeting led by the author, 'scenarios, dry runs, peer group', open-ended sessions.
Main purpose: learning, gaining understanding, defect finding
Technical review
Documented, defined defect detection process, ideally led by trained moderator, may be performed as a peer review, pre meeting preparation, involved by peers and technical experts
Main purpose: discuss, make decisions, find defects, solve technical problems and check conformance to specifications and standards

Inspection
Led by trained moderator (not the author), usually peer examination, defined roles, includes metrics, formal process, pre-meeting preparation, formal follow-up process
Main purpose: find defects.

Note: walkthroughs, technical reviews and inspections can be performed within a peer group-colleague at the same organization level. This type of review is called a "peer review".

IV) 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.
V) Cyclomatic Complexity

The number of independent paths through a program

Cyclomatic Complexity is defined as: L – N + 2P

L = the number of edges/links in a graph
N = the number of nodes in a graphs
P = the number of disconnected parts of the graph (connected components)

Alternatively one may calculate Cyclomatic Complexity using decision point rule
Decision points +1

Cyclomatic Complexity and Risk Evaluation
1 to 10a simple program, without very much risk
11 to 20 a complex program, moderate risk
21 to 50, a more complex program, high risk
> 50an un-testable program (very high risk

3 comments:

Andy said...

I'm glad you included an inspection with the non-author. One of the interesting things about static analysis is that judgment on whether a static analysis result is a call typically left to the author/developer (and not a bug reported by the field, for example). Ensuring that the developer took the time to make the right judgment call is necessary for effective use of the tool. Otherwise, valid results can slip through and poor usage, particularly unintentionally poor usage can be corrected.

Software testing videos  said...

Great description. I think you have provided sufficient information in this regard. I love to read your blog and will keep visiting it in future.

Kevin Lee said...

Aloha,

Grazie! Grazie! Grazie! Your blog is indeed quite interesting around Static Testing! I agree with you on lot of points!

I have one hierarchy query for tables exchange_grp and node.
Second hierarchy query for tables node and node_side.

A cursor declared in a package specification is global and can be accessed by other procedures or procedures in a package. A cursor declared in a procedure is local to the procedure that cannot be accessed by other procedures.

SELECT E.P_K, E.I4030_EXCH_GRP_CD, N.P_K, N.I4020_NODE_ID, N.I4020_NODE_CAT, LEVEL
FROM WORK_REP.EXCHANGE_GRP E, WORK_REP.NODE N
WHERE E.P_K = N.FK_S_EXGRP_NODE
AND E.I4030_EXCH_GRP_TYPE = 'SVX'
START WITH N.P_K IN E.NK_S_EXGRP_NODE
CONNECT BY NOCYCLE N.P_K = PRIOR N.NK_S_EXGRP_NODE

and

SELECT N.P_K, NS.P_K, NS.FK_S_NODE_NSIDE, NS.I4040_SIDE_TYPE, LEVEL
FROM WORK_REP.NODE N, WORK_REP.NODE_SIDE NS
WHERE N.P_K = NS.FK_S_NODE_NSIDE
START WITH NS.P_K IN N.NK_S_NODE_NSIDE
CONNECT BY NOCYCLE NS.P_K = PRIOR NS.NK_S_NODE_NSIDE

Can we combine these two queries into one.

It was cool to see your article pop up in my google search for the process yesterday. Great Guide.
Keep up the good work!
`
Thanks a heaps,
Kim