I’m creating these notes to make it easier for myself to learn, remember, and come back to things related to software testing. I’m currently preparing for the Test Analyst exam, so most of the content here will be related to that.
I could write everything by hand, but I know myself well enough to know that the notebook or the pen would eventually be somewhere I’m not. Keeping everything digital just makes more sense.
These notes are mainly for me, but feel free to use them if you find them helpful. I’ll keep adding and updating things as I go.
And since these are study notes, mistakes can happen. If you notice something seriously wrong, feel free to let me know.
That’s pretty much it. Hope you find something useful here.
Six common development models and the key difference between them: how work is organized, delivered and tested.
Plan everything first, then build step by step.
Development happens in a predefined order. One phase is completed before moving to the next.
Best suited for: projects where requirements are stable and well understood.
Main weakness: users may not see working software until late, so incorrect requirements can be expensive to discover.
Testing impact: test analysis and design can start early, but dynamic testing starts when executable software is available.
Link every development activity with a corresponding test activity.
Development and testing activities are planned in parallel, with test levels linked to development work products.
Best suited for: projects with clear requirements and a strong need for verification, validation and traceability.
Main weakness: the model is relatively rigid, and late changes can be costly.
Testing impact: test analysis and design start early, before the corresponding executable software exists.
Build, test and improve through repeated cycles.
The solution is developed through repeated cycles. Each iteration revisits and improves what already exists.
Best suited for: projects where requirements may evolve and feedback is needed during development.
Main weakness: rework may be needed, and total effort can be harder to predict.
Testing impact: testing happens in every iteration, and regression testing becomes increasingly important.
Deliver the product in small, usable parts.
Each increment adds new functionality to the existing product until the system becomes complete.
Best suited for: projects where early delivery of working functionality is important.
Main weakness: integration becomes more complex and good architecture is essential.
Testing impact: each increment is tested together with existing functionality, increasing the need for regression testing.
Focus on risk and refine the solution through cycles.
Development proceeds through repeated cycles driven by risk analysis and evaluation.
Best suited for: large, complex or high-risk projects.
Main weakness: it is complex and costly and requires strong risk-management expertise.
Testing impact: testing and prototyping can be used early to reduce uncertainty and evaluate risks.
Adapt quickly and deliver in short cycles.
Development is iterative and incremental, with frequent delivery, collaboration and feedback.
Best suited for: projects where requirements change or are not fully known.
Main weakness: scope and estimates may change, and strong collaboration and discipline are required.
Testing impact: testing is continuous throughout iterations, with strong emphasis on fast feedback and regression testing.
| Model | Main idea | Pros | Cons | Testing impact |
|---|---|---|---|---|
| Waterfall | Sequential | Simple, predictable | Inflexible, testing starts late | Dynamic testing later |
| V-Model | Development ↔ Testing | Early test planning, traceability | Rigid, costly changes | Testing planned from the start |
| Iterative | Improve | Early feedback, adapts over time | Rework possible, harder to estimate | Testing in every iteration |
| Incremental | Add | Early value, smaller deliveries | Integration complexity | Each increment tested + regression |
| Spiral | Risk | Strong risk management | Complex, expensive | Testing helps evaluate risks |
| Agile | Adapt | Flexible, fast feedback | Scope and estimates may change | Continuous testing |
The Test Analyst is involved throughout the test process: analyzing what needs to be tested, designing how it should be tested, preparing testware for execution and evaluating the results.
What should we test?
During test analysis, the Test Analyst evaluates the test basis to identify what needs to be tested.
The test basis is not limited to written documentation. It may include requirements, user stories, specifications, business processes, verbal information and other relevant sources of knowledge.
The Test Analyst evaluates the test basis for completeness, consistency, correctness and testability. Gaps, inconsistencies or changes may affect the test scope, test conditions and planned testing.
Relevant test planning information should be available before detailed test analysis proceeds.
The Test Analyst uses appropriate test techniques to identify test conditions. These conditions are then prioritized based on the testing objectives, product risks and other relevant factors.
Product risks are an important input. Higher-risk areas normally require greater testing effort, stronger coverage or higher priority.
Test analysis answers WHAT to test. Test conditions are identified from the test basis while considering objectives and product risks.
How should we test it?
During test design, the Test Analyst transforms test conditions into test cases and other testware.
The way test design is performed and the required level of detail depend on the project context.
Depending on the context, the Test Analyst may design high-level or low-level test cases.
Describes what should be tested without specifying every concrete input or execution step.
Verify that a registered user can reset their password.
Provides concrete information such as preconditions, inputs, actions and expected results so that the test can be reproduced.
Request a password reset for a registered account, open a valid reset link, enter a valid new password and verify that the old password is no longer accepted.
Experienced testers may work effectively with less detailed test cases. More detailed testware may be needed when reproducibility, traceability or support for less experienced testers is important.
The Test Analyst also identifies the required test data and test environment requirements.
Time, budget, available skills and tools may constrain test design. The goal is not to create as many test cases as possible, but to achieve appropriate coverage of the objectives and risks.
Test design answers HOW to test. Test conditions are transformed into test cases, test data requirements and environment requirements.
Are we ready to execute?
During test implementation, the testware required for execution is completed and organized.
The Test Analyst contributes to ensuring that the required testware, test data and test environment are ready for test execution.
Product risk is an important prioritization factor, but it is not the only one. Dependencies, business priority, test environment availability and other constraints may also affect the execution order.
Test implementation prepares testing for execution. Testware is finalized, organized and made ready to run.
Execute, observe, compare and evaluate.
Tests are executed according to the planned test execution schedule.
During execution, the Test Analyst performs tests, observes the actual results and compares them with the expected results.
Test execution may include testing new functionality, regression testing, confirmation testing, exploratory testing and the execution of predefined test procedures.
Tests may be executed manually or using automation. The Test Analyst may identify suitable automation candidates and provide domain and test-design knowledge, while automated test implementation may involve technical testers, automation engineers or developers.
Test execution is not only about following existing test cases. The Test Analyst should also evaluate the information discovered during testing.
Execution produces new information. Test results can reveal defects, new risks and coverage gaps and may therefore lead back to test analysis and test design.
Test analysis, test design, test implementation and test execution may overlap and repeat. Information discovered during execution can result in new test conditions, additional test cases, changed priorities or newly identified risks.