ISTQB CTFL Syllabus Uncovered: Your Ultimate Guide Vol3
3.1. Static Testing Basics
Static testing is like checking a recipe without actually cooking the meal. You examine the recipe, ingredients, and steps on paper or use tools to ensure everything looks good. The goal is to improve the recipe, catch mistakes, and ensure it’s easy to understand and follow.
In software, people like testers, business folks, and developers review and refine plans and documents before running tests. They collaborate to ensure that the software meets certain criteria. This review helps find problems before actual testing and can be done more efficiently. It’s like spell check for software, making it better and safer.
3.1.1. Work Products Examinable by Static Testing
Static testing can be applied to many types of documents and plans. You can review things like requirement documents, code, test plans, and more to make sure they’re good. If something can be read and understood, you can review it. However, for more technical checks called static analysis, the things you’re looking at need to have a structured format. For example, code or text with a specific structure that can be checked by tools. Some things are not suitable for static testing, like stuff that’s hard for people to understand or things that you legally can’t check, like third-party code.
3.1.2. Value of Static Testing
Static testing is like finding mistakes in a storybook before you even start reading it. It helps to catch problems early in the software development process. It can find errors that dynamic testing, which is testing the software when it’s running, can’t catch.
Static testing also helps make sure that what’s written in the requirements matches what people want. It’s like making sure a recipe matches what you want to cook.
By doing static testing early, everyone working on the project can understand and talk to each other better. This saves time and money because it’s easier to fix problems when they’re found early. It’s like making sure a car is well-built before driving it to avoid costly repairs later.
Static analysis is like using a special tool to find mistakes in the writing or code. It’s usually faster and finds more problems than dynamic testing, which is like testing a car while it’s moving.
3.1.3. Differences between Static Testing and Dynamic Testing
Static testing and dynamic testing are two different ways to check for mistakes in software, and they work well together. They have similar goals, like finding errors, but they have some differences:
- Static testing finds mistakes directly, while dynamic testing finds mistakes when the software is running and then figures out what went wrong.
- Static testing is good at finding errors in parts of the software that are rarely used or hard to test with dynamic testing.
- Static testing can be used on documents and plans, while dynamic testing needs the software to be running.
- Static testing can measure things like how easy the software is to maintain, while dynamic testing checks things like how fast it runs.
Static testing is great at finding certain types of mistakes, like errors in requirements, bad designs, coding problems, and security issues. It can also help check if the software is following standards and if the tests cover everything they should. It’s like having a proofreader for your work before you test it in action.
3.2. Feedback and Review Process
3.2.1. Benefits of Early and Frequent Stakeholder Feedback
Getting feedback early and often in software development is like talking with the people who want the software as it’s being built. If you don’t involve them enough, you might end up with a product that doesn’t match what they want. This can lead to lots of problems, like redoing work, missing deadlines, and blaming each other, and it might even make the whole project fail.
But if you talk with the people who want the software regularly, you can avoid misunderstandings about what they need. You can also make changes to the project early, so it’s easier to understand and build. This way, the development team can focus on making the most important and useful parts of the software, which is good for everyone. It’s like making sure you’re on the same page with a team to build something great.
3.2.2. Review Process Activities
The ISO/IEC 20246 standard provides a way to review and check the quality of different work items or documents in a structured but flexible manner. It’s like a process for making sure everything is in order before moving forward.
Here are the steps in this review process:
- Planning: This is where you decide what you’re going to review, why you’re reviewing it, what qualities you’re looking for, and how you’ll do it. You also set criteria for when the review will be finished.
- Review initiation: This is like getting everyone ready for the review. You make sure everyone has access to the thing you’re reviewing, they know what they need to do, and they have the tools they need.
- Individual review: Each person involved in the review checks the thing and looks for issues or improvements. They use different methods like checklists or scenarios to guide them. They write down any problems or questions they find.
- Communication and analysis: Not everything they find is necessarily a problem. In this step, you talk about the issues that were found, decide if they are real problems, and figure out what to do about them. This often happens in a meeting.
- Fixing and reporting: If there are real problems, you create reports about them so they can be fixed. Once all the criteria are met and the issues are resolved, the work item can be accepted, and the results of the review are reported to the relevant people. It’s like making sure everything is fixed and documented before moving on.
3.2.3. Roles and Responsibilities in Reviews
When you have a review of something, like a document or a project, there are different people involved, and they each have specific jobs:
Manager: The manager decides what needs to be reviewed and makes sure there are enough people and time to do the review.
Author: This is the person who created the thing that’s being reviewed, and they may need to make changes based on the review.
Moderator (or Facilitator): The moderator makes sure the review meetings go smoothly. They help manage time, keep things on track, and make sure everyone can express their thoughts comfortably.
Scribe (or Recorder): The scribe keeps a record of what happens during the review. They write down any issues people find and the decisions made during the meeting.
Reviewer: Reviewers are the people who review the work. They could be team members, experts, or anyone involved in the project who checks for problems.
Review Leader: The review leader is in charge of the entire review process. They decide who should be involved, when and where the review will happen, and oversee the whole review.
There could be more specific roles depending on the situation, but these are the main ones. It’s like having a team of people with different jobs to make sure the review is done well.
3.2.4. Review Types
There are different ways to review and check work, and the choice of how formal the review is depends on things like the project’s stage, how complicated the work is, and the rules that need to be followed. You can review the same thing in different ways, like starting with a casual check and later doing a more formal one.
Picking the right type of review is important, and it’s based on what you want to achieve, your project’s needs, the resources you have, and other factors like the kind of work and the risks involved.
Here are a few common review types:
Informal Review: This is a simple check without strict rules or formal records. The main goal is to find problems.
Walkthrough: The author guides this review. It helps with many things, like improving the work, educating reviewers, and discussing ideas.
Technical Review: Technical experts lead this review to solve problems, find issues, and build confidence in the work.
Inspection: This is the most formal review type. It follows a complete process, aims to find the most issues, and gathers data to improve future reviews and projects. The author can’t lead this type of review.
The type of review you choose depends on what you want to achieve and the situation you’re in. It’s like picking the right tool for the job.
3.2.5. Success Factors for Reviews
The success of reviews, or checks, in a project, depends on a few things:
Clear Goals and Exit Criteria: You need to know what you want to achieve with the review, and how you’ll know when it’s done. But remember, the goal should not be evaluating or grading the people involved.
Choosing the Right Type: Pick the type of review that matches your goals, the work you’re checking, the people involved, and the project’s needs.
Breaking it Down: Reviews should be done in smaller parts so that the people checking things don’t get tired or lose focus.
Feedback: Make sure the feedback from the reviews gets to the right people, so they can make the work better.
Time to Prepare: Give everyone enough time to get ready for the review.
Support from Management: It helps a lot when the bosses support the review process.
Culture of Reviews: Make it a normal thing in the organization to do reviews. It helps everyone learn and make the process better.
Training: Make sure everyone knows how to do their part in the review.
Facilitating Meetings: When you have review meetings, make sure they run smoothly and everyone can talk freely. It’s like making sure the game plan is clear and everyone knows their role.
4.1. Test Techniques Overview
Test techniques help testers decide what and how to test. They are classified into black-box (based on behavior), white-box (based on design), and experience-based (using tester knowledge). Black-box tests work without knowing the internal structure. White-box tests need structure details and come after design. Experience-based tests rely on tester skills and can find unique issues not caught by other techniques.
4.2. Black-Box Test Techniques
4.2.1. Equivalence Partitioning
Equivalence Partitioning (EP) divides data into groups based on how the software should treat them. Each group should have the same testing approach. For full coverage, every group, even those with invalid values, needs testing. This method is useful for various data elements, but it requires careful planning. The goal is to cover all these groups, and it’s measured by the percentage of groups covered. In complex cases with multiple sets of groups, you use “Each Choice” coverage to ensure each group from each set gets tested.
Equivalence Partitioning is like sorting items into different boxes based on certain characteristics. For example, let’s say you are testing a simple login system with a username field, and the valid usernames are supposed to be between 4 and 10 characters. Here’s how it works:
- Valid Partition: You create one box for valid usernames, which are between 4 and 10 characters. For example, “JohnDoe” (7 characters) and “Jane” (4 characters) go into this box.
- Invalid Partition: You create another box for invalid usernames, which don’t meet the criteria. For example, “Bob” (3 characters) and “ElizabethSmith” (15 characters) go into this box.
Now, in testing:
- You need to have test cases to check valid usernames. So, you’d create a test case for “JohnDoe” and another for “Jane” to make sure the system accepts them.
- You also need test cases to check invalid usernames, so you’d create test cases for “Bob” and “ElizabethSmith” to make sure the system rejects them.
By doing this, you’re covering both valid and invalid cases, ensuring that the system behaves as expected. Equivalence Partitioning simplifies the testing process by focusing on specific groups of data and their expected behavior.
4.2.2. Boundary Value Analysis
Boundary Value Analysis (BVA) focuses on testing the edges or boundaries of data groups. It’s useful for finding mistakes near those edges. There are two types: 2-value BVA tests the boundary values and their closest neighbors, while 3-value BVA includes the neighbors of boundary values. The 3-value BVA is more thorough and can catch errors that the 2-value BVA might miss, especially when it comes to finding mistakes near the edges.
Imagine testing a login system with username and password fields.
For usernames:
Check a username with 4 characters (minimum valid length).
Check a username with 10 characters (maximum valid length).
Also, check a 3-character username (just below the valid range) and an 11-character username (just above the valid range) to ensure it handles invalid usernames.
For passwords:
Test a 6-character password (minimum valid length).
Test a 12-character password (maximum valid length).
Also, check a 5-character password (just below the valid range) and a 13-character password (just above the valid range) to ensure it handles invalid passwords.
This way, you’re testing the boundaries to make sure the login system behaves correctly and securely.
4.2.3. Decision Table Testing
Decision tables help test complex logic and business rules. In these tables, conditions and actions are defined, and each column represents a unique combination of conditions with associated actions. The “T” stands for true, “F” for false, and “-” means irrelevant. In testing, we aim to cover all feasible condition combinations. Decision tables ensure systematic testing, finding gaps, and addressing contradictions in requirements. If there are many conditions, it can be time-consuming, and you may use a minimized table or a risk-based approach to reduce testing efforts.
Let’s use a simplified decision table for testing whether a user is eligible for a discount at an online store based on their membership status and purchase total:
Conditions:
Membership Status (M):
“Yes” (user has a membership)
“No” (user does not have a membership)
Purchase Total (P):
“High” (total purchase amount is above $100)
“Low” (total purchase amount is $100 or below)
Actions:
Eligible for Discount (D):
“Yes” (user is eligible for a discount)
“No” (user is not eligible for a discount)
In this case, we have four possible combinations:
If a user has a membership (M = “Yes”) and their purchase total is high (P = “High”), then they are eligible for a discount (D = “Yes”).
If a user has a membership (M = “Yes”) and their purchase total is low (P = “Low”), then they are not eligible for a discount (D = “No”).
If a user does not have a membership (M = “No”) and their purchase total is high (P = “High”), then they are not eligible for a discount (D = “No”).
If a user does not have a membership (M = “No”) and their purchase total is low (P = “Low”), then they are not eligible for a discount (D = “No”).
You’d test each of these four combinations to ensure that the discount eligibility logic works correctly. The decision table helps you systematically cover all possible scenarios.
4.2.4. State Transition Testing
State transition testing uses diagrams or tables to model how a system changes states when events occur. Test cases are sequences of events that lead to state changes.
Three coverage criteria are discussed:
All States Coverage: Ensures all system states are visited in test cases.
Valid Transitions Coverage: Covers all valid state transitions.
All Transitions Coverage: Tests all state transitions, including invalid ones.
Achieving full “All Transitions Coverage” is a robust approach, as it guarantees full coverage of states and valid transitions.
Let’s consider a simple example of a vending machine:
States:
Idle (the initial state)
Ready (when a customer selects a product)
Dispensing (while the machine dispenses the product)
Complete (after the product is dispensed)
Events:
The customer selects a product
Coin inserted
Coin rejected (if the wrong coin is inserted)
Product dispensed
Now, let’s create a simplified state transition diagram:
From Idle, when a customer selects a product, it transitions to Ready.
From Ready, when a coin is inserted, it stays in the Ready state (waiting for more coins).
From Ready, if the wrong coin is inserted, it transitions back to Idle.
From Ready, when the correct amount of coins is inserted, it transitions to Dispensing.
From Dispensing, after the product is dispensed, it transitions to Complete.
Actions:
In the Ready state, the machine waits for the correct amount of coins.
In the Dispensing state, the machine dispenses the selected product.
A test case might look like this:
Start in the Idle state.
Select a product (transition to Ready).
Insert the correct amount of coins (stay in Ready).
Dispense the product (transition to Dispensing).
Wait for the product to be dispensed (transition to Complete).
This test case covers various state transitions and ensures that the vending machine behaves correctly during the purchase process.
4.3. White-Box Test Techniques
Some advanced testing methods exist for critical systems, but we won’t cover them here. These methods are used in high-stakes situations or for different types of testing, like neural networks.
4.3.1. Statement Testing and Statement Coverage
Statement testing aims to test each executable statement in the code. Achieving 100% statement coverage means every statement is tested at least once, but it doesn’t guarantee all defects are found. Some issues are data-dependent, and it doesn’t cover all decision logic, like branches in the code.
Let’s consider a simple code snippet in a programming language:
def divide(a, b):
result = 0
if b != 0:
result = a / b
return result
In this code, there are four executable statements:
result = 0
if b != 0:
result = a / b
return result
To achieve 100% statement coverage, you would need to design test cases that execute each of these statements at least once. For example, you might have test cases like:
Test Case 1:
a = 10
b = 2
Test Case 2:
a = 5
b = 0
In Test Case 1, you execute all four statements. In Test Case 2, you execute the first two statements but not the third one because of the condition if b != 0. This way, you ensure that all statements are covered by your test cases.
4.3.2. Branch Testing and Branch Coverage
Branch testing focuses on testing the different paths that code can take. It aims for 100% branch coverage, meaning all possible paths through the code are tested. This includes both unconditional and conditional branches, but it doesn’t guarantee finding all defects. Branch coverage includes statement coverage but not the other way around.
Let’s use a simple Python code snippet to illustrate branch coverage:
def get_grade(score):
if score >= 90:
grade = ‘A’
elif score >= 80:
grade = ‘B’
else:
grade = ‘C’
return grade
In this code, there are three branches:
The first branch is the if score >= 90: statement.
The second branch is the elif score >= 80: statement.
The third branch is the else: statement.
To achieve 100% branch coverage, you would design test cases to cover all possible paths:
Test Case 1:
score = 95 (covers the first branch, resulting in ‘A’ grade)
Test Case 2:
score = 85 (covers the second branch, resulting in ‘B’ grade)
Test Case 3:
score = 75 (covers the third branch, resulting in ‘C’ grade)
These test cases ensure that all three branches are exercised, achieving 100% branch coverage.
4.3.3. The Value of White-box Testing
White-box testing examines the entire software code and can find defects even with incomplete specifications. It’s useful for reviewing code before execution. It also measures code coverage objectively, helping generate more tests for better confidence.
4.4. Experience-based Test Techniques
4.4.1. Error Guessing
Error guessing involves anticipating errors, defects, and failures based on experience and knowledge. It helps identify problems related to inputs, outputs, logic, computation, interfaces, or data. Fault attacks are a systematic way to apply error guessing by creating a list of possible issues and designing tests to find them
4.4.2. Exploratory Testing
Exploratory testing involves learning and testing simultaneously. It’s useful when specs are lacking, time is tight, or to complement other techniques. Testers use charters, debriefs, and test sessions for structured exploration. Experienced testers with domain knowledge excel in this method.
4.4.3. Checklist-Based Testing
Checklist-based testing uses lists of questions or conditions to guide tests. These checklists can be created based on experience or knowledge of common issues. They are helpful for various types of testing, but they need to be updated to stay effective. They provide guidance and consistency when detailed test cases are lacking.
4.5. Collaboration-based Test Approaches
4.5.1. Collaborative User Story Writing
User stories describe valuable features, including a card (medium), conversation (usage details), and confirmation (acceptance criteria). They typically follow the format “As a [role], I want [goal] so that I can [business value]. Collaborative authorship and following INVEST principles are key to effective user stories. If a user story isn’t clear or valuable, it may need improvement.
4.5.2. Acceptance Criteria
Acceptance criteria outline conditions a user story must meet for approval. They define scope, build consensus, cover both positive and negative cases, guide testing, and assist in planning. They can be written in different formats, like scenarios (Given/When/Then) or rules (verification list). The chosen format should be clear and precise.
4.5.3. Acceptance Test-driven Development (ATDD)
ATDD is a test-first approach where team members create test cases before developing a user story. They clarify the story and write examples that define its behavior. These test cases serve as both examples and tests, ensuring the software works as intended. Positive, negative, and non-functional aspects are covered. Test cases are written in plain language, and automation is used for execution.
