ISTQB Study Centre

 What are the differences between Static and Dynamic Software Testing The complex and time-consuming nature of software development has made it essential for organizations to implement a comprehensive software testing strategy. Some enterprises still use conventional and manual testing methods , whereas others automate software testing to save both time, efforts and cost. However, the software testing plan of each organization must concentrate on a number of additional points to improve both efficiency and productivity. The software application verification activities can be divided into static and dynamic testing.               Under static testing, the QA Testers refer to a checklist to ensure that the process is going according to pre-set standards including coding, deployment and integration. Some of the widely used static testing methodologies are inspection, r...

What are the defects found in Static Test Analysis?   Defects found by Static Test Analysis could be: Referencing a variable with an undefined value; Inconsistent interface between modules and components; Variables that are never used; Unreachable (dead) code; Programming standards violations; Security vulnerabilities; Syntax violations of code and software models.

 The main objective of static testing is: The objective of static analysis is to find defects in software source code and software models. Static analysis is performed without actually executing the software being examined by the tool; dynamic testing does execute the software code. Static analysis can locate defects that are hard to find infesting. As with reviews, static analysis finds defects rather than failures. Static analysis tools analyse program code (e.g. control flow and data flow), as well as generated output such as HTML and XML.     

In software Testing a successful review consists of: 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.  

The key characteristics of an Inspection consists of: Led by trained moderator (not the author); Usually peer examination; Defined roles; Includes metrics; Formal process based on rules and checklists with entry and exit criteria; Pre-meeting preparation; Inspection report, list of findings; Formal follow-up process; Optionally, process improvement and reader; Find defects.  

In Software Testing a Technical Review consists of: Documented, defined defect-detection process that includes peers and technical experts; May be performed as a peer review without management participation; Ideally led by trained moderator (not the author); Pre-meeting preparation; Optionally the use of checklists, review report, list of findings and management participation; May vary in practice from quite informal to very formal; Main purposes: discuss, make decisions, evaluate alternatives, find defects, solve technical Problems and check conformance to specifications and standards.  

In Software Testing a n  Informal Review consists of: No formal process; There may be pair programming or a technical lead reviewing designs and code; Optionally may be documented; May vary in usefulness depending on the reviewer Main purpose: inexpensive way to get some benefit

A walkthrough is a review technique in software testing where the author of a work product (such as requirements, designs, test cases, or code) leads a group of peers through the material to build shared understanding and uncover potential defects early. Key Features of a Walkthrough Author‑led session The creator guides participants through the document or artefact, explaining logic, intent, and decisions. Use of scenarios and dry runs The group may step through example workflows or test scenarios to validate completeness and accuracy. Peer‑group discussion Walkthroughs encourage open, exploratory conversation, allowing reviewers to ask questions, challenge assumptions, and highlight risks. Optional preparation and documentation Depending on the level of formality, the session may include: Pre‑reading by reviewers A structured review report A list of findings A scribe to capture actions and observations Formality Levels Walkthroughs can range from informal knowledge‑shar...