ISTQB - Static Testing
-
Static testing is a type of software testing where the code or documentation is examined without actually running the program. It's like reviewing the work to find mistakes early in the development process.
-
It involves reviewing and analyzing the code, design documents, or requirements before the code is executed. This can be done manually or using tools.
Types of Static Testing
Reviews
- What it is
- Example
- This involves people going through documents or code to spot mistakes. It can be done in a formal meeting (formal review) or just as a quick check (informal review).
- A team sits down to review a project's requirements document to make sure it’s clear and correct.
Static Analysis
- What it is
- Example
- This is an automated way of analyzing the source code without running it. Static analysis tools scan the code to find errors like security vulnerabilities or poor coding practices.
- A tool checks your code for possible security issues or bugs. ie: Like missing semicolons or unused variables.
Benefits of Static Testing
-
Early detection of errors, since it happens before the software is executed, you can catch problems early when they are cheaper and easier to fix.
-
Saves time and money, finding and fixing bugs early means less rework later on.
-
Static testing is like inspecting and reviewing code or documents to find issues before the system is actually run. It's a proactive way to improve quality early in the process.
Categories of Test Design Techniques
Specification-based (Black-box) Techniques
- What it is
- Example
- Analogy
- Common techniques
- Testing is based on the requirements or specifications of the software, without looking at the internal workings (code) of the system. You only care about the inputs and expected outputs.
- If you’re testing a calculator app, you check if entering 2 + 3 gives you the correct output of 5 based on the specification. You don't care how the code inside processes the addition, just that it gives the correct result.
- Imagine testing a vending machine. You input money and select an item, and check if you get the right snack. You don’t care how the machine processes your request internally.
Equivalence Partitioning: Dividing input data into valid and invalid groups to reduce the number of test cases.
Boundary Value Analysis: Testing at the edges of input ranges (like minimum and maximum values).
Structure-based (White-box) Techniques
- What it is
- Example
- Analogy
- Common techniques
- Testing that looks at the internal structure or code of the system. You design tests based on how the code is written to ensure all parts of the code are exercised.
- You test a function in the calculator app by checking if every line of code inside the addition function is executed. You might create special inputs to trigger certain code paths that could be missed in black-box testing.
- It’s like opening the vending machine to see the wiring and mechanisms inside, and testing each part to make sure everything works perfectly.
Statement Coverage: Ensuring that each line of code is executed at least once.
Branch Coverage: Ensuring that every possible path or decision in the code is tested.
Experience-based Techniques
- What it is
- Example
- Analogy
- Common techniques
- Testing is based on the experience, intuition, and knowledge of the testers. This method doesn't rely on formal specifications or code but uses the tester's understanding of where bugs are likely to be found.
- Based on experience, a tester might know that login features are prone to security issues. They will focus on testing the login functionality rigorously, even if the requirements don’t mention specific edge cases like entering very long passwords or special characters.
- It’s like someone who has worked with vending machines for years and knows that certain parts are more likely to break. They focus on testing those parts more thoroughly, even without opening the machine or reading the manual.
Exploratory Testing: Testers actively explore the system without predefined test cases to find defects.
Error Guessing: Testers use their intuition and past experiences to "guess" where bugs might be and design tests around those areas.
Summary
-
Specification-based (Black-box): You test based on the inputs and expected outputs, without looking at the code. You only care if the system works as described in the requirements.
-
Structure-based (White-box): You test based on how the system is built internally, focusing on code coverage and execution paths.
-
Experience-based: You rely on your knowledge and experience to focus testing on areas most likely to have problems, often without formal guidelines.
Common Testing Techniques
Equivalence Partitioning
- What it is
- Example
- Type
- This technique involves dividing input data into groups (or partitions) that are expected to behave the same way. Instead of testing every possible input, you test one representative value from each group.
If a form asks for a user's age, and the valid range is 18 to 60, you could divide the inputs into three partitions:
Below 18 (invalid)
18 to 60 (valid)
Above 60 (invalid) You would then test one value from each group (like 17, 25, and 61).
- Black-box testing, You don’t care about how the system processes the data internally, just the outcomes for each partition.
Boundary Value Analysis
- What it is
- Example
- Type
- This technique focuses on testing the boundaries of input ranges. Since bugs often occur at the edges of input limits, you test values right on, just below, and just above the boundaries.
Using the same age input (valid range: 18 to 60), you would test:
Boundary values: 18 and 60 (valid)
Just outside the boundaries: 17 and 61 (invalid)
- Black-box testing, You focus on the system’s behavior at boundary values, without knowing how the code handles it.
Decision Table Testing
- What it is
- Example
- Type
- This technique is used when there are multiple conditions that influence the output. A decision table lists the different possible combinations of inputs and their expected results.
- Imagine a system where a user can either be a "member" or "non-member" and they can pay either "online" or "in-store". You would create a decision table to test all combinations:
Member Type Payment Type Discount Applied Member Online Payment yes Member In-store Payment yes Non-Member Online Payment no Non-Member In-store Payment no
Member + Online payment = Discount
Member + In-store payment = Discount
Non-member + Online payment = No Discount
Non-member + In-store payment = No Discount
- Black-box testing, You’re testing based on the conditions and their outputs, without looking at how the code decides the outcomes.
State Transition Testing
- What it is
- Example
- Type
- This technique tests how a system moves from one state to another, depending on user actions or inputs. You test if the system behaves correctly as it transitions between states.
Think of a login system, You test that the system transitions correctly between these states based on inputs.
Initial State: User is logged out.
Transition 1: User enters correct credentials → Logged in.
Transition 2: User enters wrong credentials → Stay logged out.
- Black-box testing, You are only testing if the system transitions correctly, not how the internal code handles state changes.
Exploratory Testing
- What it is
- Example
- Type
- In this approach, testers explore the system without predefined test cases. You test the application as you go, based on your understanding, intuition, and experience. This is especially useful in discovering unexpected issues.
- While testing a social media app, you might try sending messages, uploading photos, and adjusting privacy settings without a detailed plan, looking for bugs along the way.
- Black-box testing, Testers explore the system's behavior based on experience without focusing on the underlying code.