Static and Dynamic Testing

Static Testing – what is static testing, Types

 

Testing Have Two Types:

Static

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

Review

Static Analysis

Review:

Informal

Walkthrough

Peer Review

Inspection

 

Static Analysis

Data Flow

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.

 Walkthrough:

It is not a formal process.

It is led by the authors.

Author guide the participants through the document according to his or her thought process to achieve a common understanding and to gather feedback.

Useful for the people if they are not from the software discipline, who are not used to or cannot easily understand software development process.

Is especially useful for higher level documents like requirement specification, etc.

The goals of a walkthrough:

To present the documents both within and outside the software discipline in order to gather the information regarding the topic under documentation.

To explain or do the knowledge transfer and evaluate the contents of the document

To achieve a common understanding and to gather feedback.

To examine and discuss the validity of the proposed solutions.

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.

 Inspection:

It is the most formal review type

It is led by the trained moderators

During inspection the documents are prepared and checked thoroughly by the reviewers before the meeting

It involves peers to examine the product

A separate preparation is carried out during which the product is examined and the defects are found

The defects found are documented in a logging list or issue log

A formal follow-up is carried out by the moderator applying exit criteria

The goals of inspection are:

It helps the author to improve the quality of the document under inspection

It removes defects efficiently and as early as possible

It improve product quality

It create common understanding by exchanging information

It learn from defects found and prevent the occurrence of similar defects. 

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. 

 Technical review:

• It is less formal review
• It is led by the trained moderator but can also be led by a technical expert
• It is often performed as a peer review without management  participation
• Defects are found by the experts (such as architects, designers, key users) who focus on the content of the document.
• In practice, technical reviews vary from quite informal to very formal

The goals of the technical review are:

• To ensure that an early stage the technical concepts are used correctly
• To access the value of technical concepts and alternatives in the product
• To have consistency in the use and representation of technical concepts
• To inform participants about the technical content of the document

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.