Static Testing – what is static
testing, Types
Testing Have Two Types:
1)
Static
2)
Dynamic
Static Testing:
Static Testing is performed to check the defect in software
without using code.
Static testing techniques do not execute the
software and they do not require the bulk cases. This type of testing is also
known as non-computer based testing or human testing static testing can be
applied for most of the verification activities discussed earlier. Since
verification activities are required at every stage of SDLC till coding. Static
testing can also be applied at all these phases. The objectives of static
testing can be summarized as follows:
·
To identify errors in any phase of SDLC as
early as possible.
·
To verify that the components of software are
in conformance with its requirements.
·
To provide information for project monitoring.
·
To improve the software quality and increase
productivity
·
Less cost.
Types of static testing
1)
Review
2)
Static Analysis
Review:
1)
Informal
2)
Walkthrough
3)
Peer Review
4)
Inspection
Static Analysis
1)
Data Flow
2)
Control Flow
Review: It is process to detect and remove errors and
defects in the different supporting documents like software requirements
specifications. People examine the documents and sorted out errors,
redundancies and ambiguities.
Review is of four types:
Informal:
In informal review the creator of the documents put the contents
in front of audience and everyone gives their opinion and thus defects are
identified in the early stage.
Walkthroughs:
Walkthrough is a less formal and less vigorous technique as
compared to inspection. The typical walkthrough team consists of the members –
co-coordinator, developer, recorder tester, maintenance oracle, standard
beaver, and agent. A walkthrough has fewer steps and does not use a check to
guide or a written report to document the teams work. The person designated as
a tested comes to the meeting armed with small set of paper test cases. The
walkthrough should have a follow up process similar to that described in the
inspection process.
Software
inspections: Software inspections can be used to tackle software
quality problem quality problem because they allow the detection and removal of
defects after each phase of the software development process. For the inspection
process, a minimum of four members are required –
·
Author/owner/producer: A programmer or designer responsible
for producing the program or document.
·
Inspector: A peer member of the team, not manager or
supervisor.
·
Moderator: A team member who manages the whole inspection.
·
Recorder: A member who records all the results of inspection.
1. Planning – In this phase, the product to be inspected
is identified. A moderator is assigned. A moderator assures that the product is
ready for inspection. Selects inspection team and assigns roles. Schedules the
meeting venue and time.
2. Overview – The inspection team is provided with
background info for inspection. This information is necessary for inspection
team to perform a successful inspection. The opening meeting may also be called
by moderator, to explain the objective of inspection to the team members. The
idea is that every member should be familiar with overall process of
inspection.
3. Individual preparation – The review as individually
prepare themselves for the inspection process by studying the documents
provided to them in the overview session. They point out potential errors or
problems found and record them in a log. This log is then submitted to the
moderator. Where he complies the logs of different members and gives copy of
this complied list to the author of inspected item.
4. Inspection meeting – The inspection meeting starts
with the author of the inspected item who has created it. The basic goal of the
inspection meeting is to uncover any bug in the product. However, no effort is
made in the meeting to fix the bug. It means that bugs are only being notified
to the author, which he will fix later.
5. Rework – The summary list of the bugs that arise
during the inspection meeting needs to be rewarded by the author. The author
fixes all these bugs and reports back to the moderator.
6. Follow-up – It is the responsibility of the moderator
to check if all the bugs found in the last meeting have been addressed and
fixed. He prepares a report and ascertains that all issues have been resolved
and if not unresolved issues are mentioned in report.
Peer review:
Peer review means checking documents of one-another to detect
and fix the defects. It is basically done in a team of colleagues.
Technical reviews - Technical reviews is intended to evaluate the software
in the light of development standards, guidelines and specifications and to
provide the management with evidence that development process is being carried
out according to stated objectives. A review is similar to inspector or walk
through except that the review team also includes management. Review agendas
show focus less on technical issues and move on oversight than an inspection.
The moderator gather and distribute the documents to all the team members for
examination before the review. The of the review should be a document recording
the events of the meeting, deficiencies identified and review team
recommendation
Static
Analysis is of three types:
·
Data Flow:
Data flow is related to the stream processing.
·
Control Flow:
Control flow is basically how the statements or instructions are executed.
·
Cyclomatic Complexity:
Cyclomatic complexity is the measurement of the complexity of the program that
is basically related to the number of independent paths in the control flow
graph of the program.
Comments
Post a Comment