Static Testing : Types with Explanation

 

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