What is Static Testing?
Static testing is a form of software testing where the software is not actually used. This is in contrast to dynamic testing. It is generally not detailed testing but checks mainly for the sanity of the code, algorithm, or document. It is primarily syntax checking of the code or and manually reading of the code or document to find errors.
This type of testing can be used by the developer who wrote the code, in isolation. Code reviews, inspections, and walkthroughs are also used. From the black box testing point of view, static testing involves the review of requirements or specifications.
This is done with an eye toward completeness or appropriateness for the task at hand. This is the verification portion of Verification and Validation.
Bugs discovered at this stage of development are less expensive to fix than later in the development cycle.
In software development, static testing also called dry run testing, is a form of software testing where the actual program or application is not used. Instead, this testing method requires programmers to manually read their own code to find any errors. Static testing is a stage of White Box Testing.
Static testing involves three major steps. They are
The review is “A process or meeting during which artifacts of the software product are examined by project stockholders, user representatives, or other interested parties for feedback or approval “.
Software Review can be on technical specifications, designs, source code, user documentation, support and maintenance documentation, test plans, test specifications, standards, and any other type of specific to work product, it can be conducted at any stage of the software development life cycle.
The purpose of conducting the review is to minimize the defect ratio as early as possible in the Software Development life cycle. As a general principle, the earlier a document is reviewed, the greater will be the impact of its defects on any downstream activities and their work products.
The magnitude cost of defect fixing after the release of the product is around 60 – 100x. The review can be formal or informal. Informal reviews are referred to as walkthrough and formal as Inspection.
A thorough review of the processes and design of the product/ application. Subject matter specialists and designers perform this exercise. Architectural, Development and Implementation issues are discussed and frozen at this point in time.
Our QA architects get involved at this stage to determine the potential influence of architecture and design on the QA process, platform, and tools selection.
An inspection is a formal, rigorous, in-depth group review designed to identify problems as close to their point of origin as possible. Inspection is a recognized industry best practice to improve the quality of a product and to improve productivity. Inspections are a formal review and generally need is predefined at the start of the product planning.
The objectives of the inspection process are to:
- Find problems at the earliest possible point in the software development process.
- Verify that the work product meets its requirements.
- Ensure that the work product has been presented according to predefined standards.
- Provide data on product quality and process effectiveness.
- Inspection advantages are to build technical knowledge and skill among team members by reviewing the output of other people.
- Increase the effectiveness of software testing.
IEEE 1028 recommends three following roles in an Inspection:
The inspection leader shall be responsible for administrative tasks pertaining to the inspection, shall be responsible for planning and preparation, shall ensure that the inspection conducted in an orderly manner and meets its objectives, should be responsible for collecting inspection data.
The recorder should record inspection data required for process analysis. The inspection leader may be the recorder.
The reader shall lead the inspection team through the software product in a comprehensive and logical fashion, interpreting sections of the work product and highlighting important aspects.
The author shall be responsible for the software product meeting its inspection entry criteria, for contributing to the inspection based on a special understanding of the software product, and for performing any rework required to make the software product meet its inspection exit criteria.
Inspectors shall identify and describe anomalies in the software product. Inspectors shall be chosen to represent different viewpoints at the meeting (for example, sponsor, requirements, design, code, safety, test, independent test, project management, quality management, and hardware engineering).
Only those viewpoints pertinent to the inspection of the product should be present. Some inspectors should be assigned specific review topics to ensure effective coverage. For example, one inspector may focus on conformance with a specific standard or standards, another on syntax, and another for overall coherence. These roles should be assigned by the inspection leader when planning the inspection.
All participants in the review are inspectors. The author shall not act as an inspection leader and should not act as a reader or recorder. Other roles may be shared among the team members. Individual participants may act in more than one role. Individuals holding management positions over any member of the inspection team shall not participate in the inspection.
Following are review phases:
- Examination meeting
Inspection Leader performs the following tasks in the planning phase.
- Determine which work products need to be inspected.
- Determine if a work product that needs to be inspected is ready to be inspected.
- Identify the inspection team.
- Determine if an overview meeting is needed.
The moderator ensures that all inspection team members have had inspection process training. The moderator obtains a commitment from each team member to participate.
This commitment means the person agrees to spend the time required to perform his or her assigned role on the team. Identify the review materials required for the inspection, and distribute materials to relevant stakeholders.
The purpose of the overview meeting is to educate inspectors; the meeting is lead by Inspector lead and is presented by the author, the overview is presented for the inspection, this meeting normally acts as optional meeting, purpose to sync the entire participant and the area to be inspected.
The objective of the preparation phase is to prepare for the inspection meeting by critically reviewing the review materials and the work product, participant drill down on the document distributed by the lead inspector and identify the defect before the meeting.
The objective of the inspection meeting is to identify the final defect list in the work product being inspected, based on the initial list of defects prepared by the inspectors [ identified at
the preparation phase and the new one found during the inspection meeting.
The Lead Auditor opens the meeting and describes the review objectives and area to be inspected. Identify that all participants are well familiar with the content material, Reader reads the meeting material and the inspector finds out any inconsistency, possible defects, and improvement suggestions to the author.
The recorder records all the discussion during the inspection meeting, and mark actions against the relevant stakeholders. The lead Inspector may take the decision that if there is a need for a follow-up meeting. The author updates the relevant document if required on the basis of the inspection meeting discussion.
Rework and follow – up
The objective is to ensure that corrective action has been taken to correct problems found during an inspection.
Method of conducting informal group/ individual review is called walkthrough, in which a designer or programmer leads members of the development team and other interested parties through a software product, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems or may suggest improvement on the article, walkthrough can be pre-planned or can be conducted at-need basis and generally people working on the work product are involved in the walkthrough process.
The Purpose of walkthrough
- Find problems
- Discuss alternative solutions
- Focusing on demonstrating how work product meets all requirements.
IEEE 1028 recommends three specialist roles in a walkthrough:
A leader is who conducts the walkthrough, handles administrative tasks, and ensures orderly conduct (and who is often the Author).
A recorder is who notes all anomalies (potential defects), decisions, and action items identified during the walkthrough meeting, normally generate minutes of session meeting at the end of the walkthrough session.
An author is who presents the software product in step – by – step manner at the walkthrough meeting, and is probably responsible for completing most action items.
The author describes the artifact to be reviewed to the reviewers during the meeting. Reviewers present comments, possible defects, and improvement suggestions to the author. The recorder records all defect, suggestion during the walkthrough meeting.
Based on reviewer comments, the author performs any necessary rework of the work product if required. Recorder prepares minutes of meeting and sends the relevant stakeholders and leader is normally to monitor overall walkthrough meeting activities as per the defined company process or responsibilities for conducting the reviews, generally performs monitoring activities, commitment against action items, etc.
What is Static testing tools?
Program testing is the technical procedure used to recognize the correctness, completeness, stability, and high quality of made computer system software package. Software program testing is executed to test quality-linked facts about analyzed merchandise. Software program testing is a critical portion of application high-quality assurance.
Some of the typical high-quality attributes of products a tester seems for functionality, trustworthiness, performance, portability, maintainability, compatibility and usability. An excellent test not only brings out problems, but it also displays fascinating information new to an undertaking neighborhood.
Computer software testing performs a crucial strategic part in transporting the high-quality of the item higher in the hierarchy in the application progress method. It also underlines the consumer’s specifications all the way via the item cycle.
Some of the vital computer software testing methods concerned in testing a product are useful testing, destructive testing, shopper circumstance testing, worry tests, overall performance testing, scalability testing, intercontinental tests, and much more. The sole function of software testing is to ensure that consumers acquire optimum products of good quality.
Some of the prevalent forms of testing an exam engineer look at while tests a solution are Black box testing, white-box tests, incremental integration testing, user testing,
program tests, conclude-to-finish testing, sanity testing or smoke tests, regression tests,
acceptance testing, acceptance testing, overall performance testing, usability exam, uninstall testing, recovery testing, failover testing, protection testing, exploratory tests, ad-hoc testing, mutation testing and additional.
Although all assignments are profited from testing, some tasks frequently do not require unbiased examination staff members. The necessity of test stuff depends on the size and context of the task, the pitfalls, the advancement methodology, the developer’s ability and experience and additional.
A short expression, minimal risk job managed by skilled programmers employing device tests or test-to start with advancement will not need check engineers. Taking into consideration the distinctive plans in application tests, distinct roles are founded for program testers. They are examination direct / manager, tester, take a look at designer, test automated / automation developer and take a look at administrator.
Static Testing Tools:
Static testing tools play a greater role in software development and testing. It was having higher importance during the waterfall model of development. Nowadays when we are migrating to an agile way of developing software, It also shifted left in the model.
The business and operation employees take a huge role while testers and developers use them less. However, it is worth knowing the Static Testing tool from the ISTQB examination standpoint and for knowledge purposes.
Review tools (also known as review process support tools) may store information about review processes, store and communicate review comments, report on defects and effort, manage references to review rules and/or checklists and keep track of traceability between documents and source code.
They may also provide aid for online reviews, which is useful if the team is geographically dispersed.
Static analysis tools (D)
Static analysis tools support developers, testers and quality assurance personnel in finding defects before dynamic testing. Their major purposes include:
- The enforcement of coding standards.
- The analysis of structures and dependencies (e.g. linked web pages).
- Aiding in understanding the code. Static analysis tools can calculate metrics from the code (e.g. complexity). Which can give valuable information, for example, for planning or risk analysis?
Modeling tools (D)
Modeling tools are able to validate models of the software. For example, a database model checker may find defects and inconsistencies in the data model; other modeling tools may find defects in a state model or an object model.
These tools can often aid in generating some test cases based on the model (see also Test design tools below). The major benefit of static analysis tools and modeling tools is the cost-effectiveness. Of finding more defects at an earlier time in the development process.
As a result, the development process may accelerate and improve by having less rework.