Test Process – Foundation Level 2018 ISTQB

1.4 Test Process

The test process for each organisation and any given project will very much depend on each system’s situation, and there are no one-fits-all test processes. However, there are some basic principles activities the ISTQB lays out that are more common, and without these exercises, the test objectives may likely not be achieved. These activities are the test process. It needs to be discussed and aligned with the organisation’s test strategy to adjust accordingly.

1.4.1 Explain the impact of context on the test process (Test Process in Context)

Let’s break down the “1.4.1 Test Process in Context” section from the syllabus, as this is quite big to understand and remember. Still, hopefully, with a bit of explanation and association with experience, we can relate to these, and it will be easier to remember when taking the exam.

“Contextual factors that influence the test process for an organization, include but are not limited to:

• Software development lifecycle model and project methodologies being used
• Test levels and test types being considered
• Product and project risks
• Business domain
• Operational constraints, including but not limited to:
  • Budgets and resources
  • Timescales
  • Complexity
  • Contractual and regulatory requirements
• Organizational policies and practices
• Required internal and external standards”

  ISTQB 2018 Foundation Level

“Software development lifecycle model and project methodologies used.”

There are many methodologies in the market, for example, Agile, Scrum, and Waterfall, to name a few. It will also determine how often and by whom the software will go through the development cycle. Is it an in-house development, an off-shore third-party, or an out-of-shelf type of software that requires following certain restrictions and regular upgrades from the source? These many different situations and circumstances will determine which one is more appropriate.

“Test levels and test type to consider.”

Here are some tests levels and types that can be used in testing.

Test Level

• Unit
• Integration
• System
• Acceptance

Test Types

• Functional
  • Unit tests
  • Unit integration tests, component integration tests, microservices testing
  • E2E (end-to-end) test
  • UAT tests, alpha/beta testing
• Non-Functional
  • Load, stress, security, code coverage(metric)
  • Load, stress, security, contract test
  • Load, stress, security, reliability, scalability, maintainability

“Product and project risks”

This is just a generic graph for you to understand the possibilities and discussions from the project team led by the project manager and what you have (you don’t have to but nice to know).

“Business Domain”

A tester will get more creative and check for more bugs by knowing the software testing domains. This is just one of how domain knowledge improves a Tester’s judgments on Business Procedures, Work Flows, and User Interface Features. Domain knowledge also helps improve Judgments on Back-End Processing: how viably/proficiently information or code is taken care of. Learning about technology domains can likewise help QA testers classify defects; this means understanding precisely what type of defect it is (minor, huge or essential).

Read more, 8 Ways Domain Knowledge Can Help You Become a Better Software Tester.

“Operational constraints, including but not limited to:

Budgets and resources

Timescales

Complexity

Contractual and regulatory requirements.” TThere’sudget that would directly affect the number of resources needed to complete a test phase or a project altogether. This typically is told upfront so the team can plan accordingly.

The timescales are often based on estimation, and there’s a possibility the time is limited and it must be delivered within a fixed timescale.

Depending on the project, it can be very complex, affecting the performance of the tests and team directly.

In most cases, there’s a contractual obligation to the project, and in some cases, there’s a regulatory obligation attached to it.

“Organisational policies and practices”

“Required internal and external standards”

The following sections describe general aspects of organizational test processes in terms of the following:

• Test activities and tasks
• Test work products
• Traceability between the test basis and test work products

It is very useful if the test basis (for any level or type of testing that is being considered) has measurable coverage criteria defined. The coverage criteria can act effectively as key performance indicators (KPIs) to drive the activities that demonstrate the achievement of software test objectives (see section 1.1.1 Identify Typical Objectives of Testing).

For example, for a mobile application, the test basis may include a list of requirements and a list of supported mobile devices. Each requirement is an element of the test basis. Each supported device is also an element of the test basis. The coverage criteria may require at least one test case for each element of the test basis. Once executed, the results of these tests tell stakeholders whether specified requirements are fulfilled and whether failures were observed on supported devices.

ISO standard (ISO/IEC/IEEE 29119-2) has further information about test processes.

ISTQB 2018 Foundation Level

This is a high-level overview for when working on test activities where it would serve as a basis and aid you through your test plan. This is a short version of the one I mentioned above about organisational policies and practices.

1.4.2 Describe the test activities and respective tasks within the test process (Test Activities and Tasks)

Per the syllabus, the test process consists of the following main activities: test planning, test monitoring and control, test analysis, test design, test implementation, test execution and test completion.

Don’t get caught thinking it should always follow the logical step-by-step path you may already encounter; if you have already been working as a tester each project ends up having its way of following this structure as it is very much dependent on the context mentioned in 1.4.1 Explain the impact of context on the test process (Test Process in Context) here’s the snip cut from the syllabus.

“A test process consists of the following main groups of activities:

• Test planning
• Test monitoring and control
• Test analysis
• Test design
• Test implementation
• Test execution
• Test completion

Each main group of activities is composed of constituent activities, which will be described in the subsections below. Each constituent activity consists of multiple individual tasks, which would vary from one project or release to another.

Further, although many of these main activity groups may appear logically sequential, they are often implemented iteratively. For example, Agile development involves small iterations of software design, build, and test that happen on a continuous basis, supported by on-going planning. So test activities are also happening on an iterative, continuous basis within this software development approach. Even in sequential software development, the stepped logical sequence of main groups of activities will involve overlap, combination, concurrency, or omission, so tailoring these main groups of activities within the context of the system and the project is usually required.”

ISTQB 2018 Foundation Level

Test Planning

We will not go into much detail in this section, as suggested by the ISTQB syllabus. Here is the quote from the syllabus.

“Test planning involves activities that define the objectives of testing and the approach for meeting test objectives within constraints imposed by the context (e.g., specifying suitable test techniques and tasks, and formulating a test schedule for meeting a deadline). Test plans may be revisited based on feedback from monitoring and control activities. Test planning is further explained in section 5.2.”

ISTQB 2018 Foundation Level

I’ll expand a lot more when we get to it but to give you a flavour of what to expect in a typical test plan, it is a common practice to follow this template, gathering these details in a test plan:

Risks – A bullet point list of risks related to the project.

Milestones – A list of milestone dates expected to achieve related to the project working on.

People – The names of people involved in testing, Testers, Test Analysts, Developer in testing and the Test lead.

Environment – Integration, configuration, tools, acceptance, etc.

Standard Operating Procedures – Stand-up meeting, triage, priorities, login bugs (Bug Life Cycle), escalation, sign-off.

Introduction – Project, type, level.

Scope – What is in scope (functional, non-functional) and what is not in scope (also functional, non-functional).

Approach – Test requirements, test design, test development, automation, test execution.

Again, more details down in section 5.2.

Test Monitoring And Control

It is a common practice to provide contract updates on the progress. It is not ideal to wait for too long down the line to give the progress report. These days there are excellent tools to support real-time reports, daily reports, milestone reports and completion reports. That’s what, in summary, what ISTQB syllabus says here. The question you got to ask constantly is: “Is there any deviation from what was planned?”. The most common methodology that explores this into tall is Agile.

Test monitoring involves the ongoing comparison of actual progress against planned progress using any test monitoring metrics defined in the test plan. Test control involves taking actions necessary to meet the objectives of the test plan (which may be updated over time). Test monitoring and control are supported by the evaluation of exit criteria, which are referred to as the definition of done in some software development lifecycle models (see Foundation Level Agile Tester ISTQB-CTFL-AT). For example, the evaluation of exit criteria for test execution as part of a given test level may include:

• Checking test results and logs against specified coverage criteria.
• Assessing the level of a component or system quality based on test results and logs.
• Determining if more tests are needed (e.g., if tests originally intended to achieve a certain level of product risk coverage failed to do so, requiring additional tests to be written and executed).

Test progress against the plan is communicated to stakeholders in test progress reports, including deviations from the plan and information to support any decision to stop testing.

Test monitoring and control are further explained in section 5.3.

ISTQB 2018 Foundation Level

Test Analysis

It is the early stage when testers can contribute when not a single line of code is complete. As early testers can get involved, better it is to support the test analysis and progress throughout the development lifecycle. In this stage, testers can start the analysis on what is going to get tested, requirements, environment, functional and non-functional, and the area testers can excel in this phase is evaluating test basis and test items identifying ambiguities, omissions, inconsistencies, and much more, as described in the ISTQB 2018 Foundation Level Syllabus here.

During test analysis, the test basis is analyzed to identify testable features and define associated test conditions. In other words, test analysis determines “what to test” in terms of measurable coverage criteria.

Test analysis includes the following major activities:

• Analyzing the test basis appropriate to the test level being considered, for example:
  • Requirement specifications, such as business requirements, functional requirements, system requirements, user stories, epics, use cases, or similar work products that specify desired functional and non-functional components or system behaviour.
  • Design and implementation information, such as system or software architecture diagrams or documents, design specifications, call flow graphs, modelling diagrams (e.g., UML or entity-relationship diagrams), interface specifications, or similar work products that specific component or system structure.
  • The implementation of the component or system itself, including code, database metadata and queries, and interfaces.
  • Risk analysis reports may consider functional, non-functional, and structural aspects of the component or system.
• Evaluating the test basis and test items to identify defects of various types, such as:
  • Ambiguities
  • Omissions
  • Inconsistencies
  • Inaccuracies
  • Contradictions
  • Superfluous statements
• Identifying features and sets of features to be tested.
• Defining and prioritizing test conditions for each feature based on analysis of the test basis, and considering functional, non-functional, and structural characteristics, other business and technical factors, and levels of risks.
• Capturing bi-directional traceability between each element of the test basis and the associated test conditions (see sections 1.4.3 and 1.4.4).

The application of black-box, white-box, and experience-based test techniques can be useful in the process of test analysis (see chapter 4) to reduce the likelihood of omitting important test conditions and to define more precise and accurate test conditions.

In some cases, test analysis produces test conditions that are to be used as test objectives in test charters. Test charters are typical work products in some types of experience-based testing (see section 4.4.2). When these test objectives are traceable to the test basis, coverage achieved during such experience-based testing can be measured.

The identification of defects during test analysis is an important potential benefit, especially where no other review process is being used and/or the test process is closely connected with the review process. Such test analysis activities not only verify whether the requirements are consistent, properly expressed, and complete, but also validate whether the requirements properly capture customer, user, and other stakeholder needs. For example, techniques such as behaviour-driven development (BDD) and acceptance test-driven development (ATDD), involve generating test conditions and test cases from user stories and acceptance criteria prior to coding. These techniques also verify, validate, and detect defects in the user stories and acceptance criteria (see ISTQB-CTFL-AT).

ISTQB 2018 Foundation Level

In these examples of working with Waterfall and V-Model methodologies, each has its phase to cover the analysis phase.

Test analysis in a Waterfall methodology approach.

Test analysis in a V-Model methodology approach.

Test Design

Earlier in the test analysis, we thought about “what to test?” and the test design phase is all about “How to Test?” in mind. At this stage, the paramount vantage is the potential discovery of early bugs from its documentation and requirements from the analysis phase.

Read more details from the test design ISTQB Foundation Level Syllabus 2018…

During test design, the test conditions are elaborated into high-level test cases, sets of high-level test cases, and other testware. So, test analysis answers the question “what to test?” while test design answers the question “how to test?”

Test design includes the following major activities:

• Designing and prioritizing test cases and sets of test cases
• Identifying necessary test data to support test conditions and test cases
• Designing the test environment and identifying any required infrastructure and tools
• Capturing bi-directional traceability between the test basis, test conditions, and test cases (see
• section 1.4.4)

The elaboration of test conditions into test cases and sets of test cases during test design often involves using test techniques (see chapter 4).

As with test analysis, test design may also result in the identification of similar types of defects on the test basis. Also, as with test analysis, the identification of defects during test design is an important potential benefit.

ISTQB 2018 Foundation Level

In this example of working in a V-Model methodology, each has its phase to cover the design phase.

Test analysis in a V-model methodology approach.

As mentioned in the quoted ISTQB lines above, we’ll cover this in more detail in chapter 4, but here is a snip view of a test design technique to help you understand better how to test when designing the test cases having these test types in mind.

Test Implementation

This is the phase where you are asked, “do we have everything we need to be able to test the system?”. It’s when you’ll have the test procedures, test scripts for automation, test suites, test plan, environments ready, data set and ready, etc.

Also, remember that exploratory may and may not have written test cases, and they can be documented as you go along with the exploratory tests.

It often overlaps with the test design and the test execution.

Read more details from the test implementation ISTQB Foundation Level Syllabus 2018…

During test implementation, the testware necessary for test execution is created and/or completed, including sequencing the test cases into test procedures. So, test design answers the question “how to test?” while test implementation answers the question “do we now have everything in place to run the tests?”

Test implementation includes the following major activities:

• Developing and prioritizing test procedures, and, potentially, creating automated test scripts
• Creating test suites from the test procedures and (if any) automated test scripts
• Arranging the test suites within a test execution schedule in a way that results in efficient test execution (see section 5.2.4)
• Building the test environment (including, potentially, test harnesses, service virtualization, simulators, and other infrastructure items) and verifying that everything needed has been set up correctly
• Preparing test data and ensuring it is properly loaded in the test environment
• Verifying and updating bi-directional traceability between the test basis, test conditions, test cases, test procedures, and test suites (see section 1.4.4)

Test design and test implementation tasks are often combined.

In exploratory testing and other types of experience-based testing, test design and implementation may occur and may be documented, as part of test execution. Exploratory testing may be based on test charters (produced as part of test analysis), and exploratory tests are executed immediately as they are designed and implemented (see section 4.4.2).

ISTQB 2018 Foundation Level

Test Execution

This time around is where everything that you’ve planned for you will then execute according to the schedule.

Recording the IDs and versions of the items in test or test object(s), the test tools, if you are carrying out a manual or automation test, the results reports, analysing anomalies, failures, defects, and so on.

Read more details from the test implementation ISTQB Foundation Level Syllabus 2018…

During test execution, test suites are run in accordance with the test execution schedule.

Test execution includes the following major activities:

• Recording the IDs and versions of the test item(s) or test object, test tool(s), and testware.
• Executing tests either manually or by using test execution tools.
• Comparing actual results with expected results.
• Analyzing anomalies to establish their likely causes (e.g., failures may occur due to defects in the code, but false positives also may occur (see section 1.2.3).
• Reporting defects based on the failures observed (see section 5.6).
• Logging the outcome of test execution (e.g., pass, fail, blocked).
• Repeating test activities either as a result of action taken for an anomaly, or as part of the planned testing (e.g., execution of a corrected test, confirmation testing, and/or regression testing).
• Verifying and updating bi-directional traceability between the test basis, test conditions, test cases, test procedures, and test results.

ISTQB 2018 Foundation Level

Test Completion

Criteria you set at the beginning of a project determine when it is safe to stop testing. The exit criterion is connected to the test coverage, the test case design technique adopted, and the risk level of the product varies from one test level to another.

In the final phase of testing, the completion is the end report, where you have to produce a TER (Test Exit Report) to capture all the testing activities, consolidating all the relevant information. The completion of a milestone for a system to go ahead with a release into production (live environment). Part of these activities is to check that all the defects (bugs) are now closed or accepted by the business, summarise to communicate to the stakeholders, archive any valuable information for later releases, hand over any helpful information for the maintenance team, analyse lessons learned and use the experience and knowledge gathered to help improve the test process maturity.

Read more details from the test implementation ISTQB Foundation Level Syllabus 2018…

Test completion activities collect data from completed test activities to consolidate experience, testware, and any other relevant information. Test completion activities occur at project milestones such as when a software system is released, a test project is completed (or cancelled), an Agile project iteration is finished, a test level is completed, or a maintenance release has been completed.

Test completion includes the following major activities:

• Checking whether all defect reports are closed, entering change requests or product backlog items for any defects that remain unresolved at the end of test execution.
• Creating a test summary report to be communicated to stakeholders.
• Finalizing and archiving the test environment, the test data, the test infrastructure, and other testware for later reuse.
• Handing over the testware to the maintenance teams, other project teams, and/or other stakeholders who could benefit from its use.
• Analyzing lessons learned from the completed test activities to determine changes needed for future iterations, releases, and projects.
• Using the information gathered to improve test process maturity.

ISTQB 2018 Foundation Level

Here is an example using a progress report from the Azure DevOps tool from the test plan extension.

1.4.3 Differentiate the work products that support the test process (Test Work Products)

Depending on the organisation you are working on and the tool, these can be called ‘work items’ and could be a feature or a user story that you would have in your test process to cover the phases that we have been talking about so far. This is a high-level explanation; each of these items here will get even more expanded in detail as you move along with your studies for the ITQB exam.

I think it is an excellent basis for you to follow; I do follow this structure when working with my clients. I work as a consultant.

Read more details from the test implementation ISTQB Foundation Level Syllabus 2018…

Test work products are created as part of the test process. Just as there is significant variation in the way that organizations implement the test process, there is also significant variation in the types of work products created during that process, in the ways those work products are organized and managed, and in the names used for those work products. This syllabus adheres to the test process outlined above, and the work products described in this syllabus and in the ISTQB® Glossary. ISO standard (ISO/IEC/IEEE 29119-3) may also serve as a guideline for test work products.

Many of the test work products described in this section can be captured and managed using test management tools and defect management tools (see chapter 6).

ISTQB 2018 Foundation Level

Test planning work products

The test plan is where it all begins. You got to find out all the information about the test basis, the product you are testing and the traceability information linking back to the exit criteria while working on your test plan.

Read more details from the test implementation ISTQB Foundation Level Syllabus 2018…

Test planning work products typically include one or more test plans. The test plan includes information about the test basis, to which the other test work products will be related via traceability information (see below and section 1.4.4), as well as exit criteria (or definition of done) which will be used during the test monitoring and control. Test plans are described in section 5.2.

ISTQB 2018 Foundation Level

Test monitoring and control work products

Ideally, to build/configure a dashboard in your test management tool, I know Azure DevOps and others like Jira and Test Complete also have the facility so you can report the progress dynamically as you go along. There are options to write more statically. If you don’t have access to the organisation’s tools (budget, security, etc.) you can use a spreadsheet to report the progress.

On the completion of work,, a summary report, typically or called TER (Test Exit Report), can be produced with the export of data from the progress of the test management tool or the spreadsheet that will cover more of a milestone, going live with an approved change.

In this part, the task completion, resource allocation and effort spent on the work items are also considered for project management-related reports.

Read more details from the test implementation ISTQB Foundation Level Syllabus 2018…

Test monitoring and control work products typically include various types of test reports, including test progress reports produced on an ongoing and/or a regular basis, and test summary reports produced at various completion milestones. All test reports should provide audience-relevant details about the test progress as of the date of the report, including summarizing the test execution results once those become available.

Test monitoring and control work products should also address project management concerns, such as task completion, resource allocation and usage, and effort.

Test monitoring and control, and the work products created during these activities, are further explained in section 5.3 of this syllabus.

ISTQB 2018 Foundation Level

Test analysis work products

In this phase, you work on defining and prioritising test conditions. Make it traceable to the specific elements of the test basis you are working on and link it back to the requirements that could be in a user story format or a work item, depending on the type of requirement management tool you are using.

Capture project attributes and considers these:

• The number of verification points.
• The number of transactions.
• Interface.
• Baseline test data.
• Testing type.
• The application is under testing.

Read more details from the test implementation ISTQB Foundation Level Syllabus 2018…

Create high-level tests when going through exploratory tests in the test analysis phase. You may discover and report bugs (defects) to the test basis in this phase too.

Test analysis work products include defined and prioritized test conditions, each of which is ideally bi-directionally traceable to the specific element(s) of the test basis it covers. For exploratory testing, test analysis may involve the creation of test charters. Test analysis may also result in the discovery and reporting of defects on a test basis.

ISTQB 2018 Foundation Level

Test design work products

The output of the test design work is test cases and a set of tests called a suite, divided by test phases and test types to apply the test conditions defined in the test analysis work. Create a test plan in your test management tool at your disposal or a spreadsheet in case you don’t have one.

Start with high-level scenarios and expand as you move into environments and types of tests, which can mostly be reused. Identify the necessary data to cover your tests. Also, the domain you will test has it all linked back to the test basis (user stories > requirements > acceptance criteria).

Once it is decided in your test plan which approaches (es) you are going to take, there are two parts to designing the work products, the Statis and Dynamic and the following:

• Static
  • Static Analysis
    • Data Flow
    • Control Flow
  • Informal Reviews
  • Walkthroughs
  • Technical Review
  • Inspection
• Dynamics
  • Structured-based
    • Statement
    • Decision
    • Condition
    • Multiple Condition
  • Experience-based
    • Error Guessing
    • Exploratory Testing
  • Specification-based
    • Equivalence Partitioning
    • Boundary Value Analysis
    • Decision Tables
    • State Transition
    • Use Case Testing

Read more details from the test implementation ISTQB Foundation Level Syllabus 2018…

Test design results in test cases and sets of test cases to exercise the test conditions defined in test analysis. It is often a good practice to design high-level test cases, without concrete values for input data and expected results. Such high-level test cases are reusable across multiple test cycles with different concrete data, while still adequately documenting the scope of the test case. Ideally, each test case is bidirectionally traceable to the test condition(s) it covers.

Test design also results in:

• the design and/or identification of the necessary test data.
• the design of the test environment.
• the identification of infrastructure and tools.

Though the extent to which these results are documented varies significantly.

ISTQB 2018 Foundation Level

Test implementation work products

This is how the tests will be carried out and the sequence of events of defined tests. The test suite is ready and good to go.

In the case of test automation, the execution schedule is ready.

You may re-define the test cases from those created in the analysis phase.

Read more details from the test implementation ISTQB Foundation Level Syllabus 2018…

Test implementation work products include:

• Test procedures and the sequencing of those test procedures.
• Test suites.
• A test execution schedule.

Ideally, once test implementation is complete, achievement of coverage criteria established in the test plan can be demonstrated via bi-directional traceability between test procedures and specific elements of the test basis, through the test cases and test conditions.

In some cases, test implementation involves creating work products using or using tools, such as service virtualization and automated test scripts.

Test implementation also may result in the creation and verification of test data and the test environment.

The completeness of the documentation of the data and/or environment verification results may vary significantly.

The test data serve to assign concrete values to the inputs and expected results of test cases. Such concrete values, together with explicit directions about the use of the concrete values, turn high-level test cases into executable low-level test cases. The same high-level test case may use different test data when executed on different releases of the test object. The concrete expected results which are associated with concrete test data are identified by using a test oracle.

In exploratory testing, some test design and implementation work products may be created during test execution, though the extent to which exploratory tests (and their traceability to specific elements of the test basis) are documented may vary significantly.

Test conditions defined in test analysis may be further refined in test implementation.

ISTQB 2018 Foundation Level

Test execution work products

This is when you have to document the status of individual and overall test cases. It is when you set the quality to ready to run, pass, fail, blocked, deliberately skipped and so on.

Bug (defect) reports to stakeholders.

The document which test items, test objects, and test tools were involved in testing. The test report should link back to each test basis (user story, requirements, etc) to demonstrate the complete coverage level and that all tests have passed against the acceptance criteria and planned items that are still waiting to be tested.

Read more details from the test implementation ISTQB Foundation Level Syllabus 2018…

Test execution work products include:

• Documentation of the status of individual test cases or test procedures (e.g., ready to run, pass, fail, blocked, deliberately skipped, etc.).
• Defect reports (see section 5.6).
• Documentation about which test item(s), test object(s), test tools, and testware were involved in the testing.

Ideally, once test execution is complete, the status of each element of the test basis can be determined and reported via bi-directional traceability with the associated test procedure(s). For example, we can say which requirements have passed all planned tests, which requirements have failed tests and/or have defects associated with them, and which requirements have planned tests still waiting to be run. This enables verification that the coverage criteria have been met, and enables the reporting of test results in terms that are understandable to stakeholders.

ISTQB 2018 Foundation Level

Test completion work products

This will include the test summary reports via the TER (Test Exit Report) document. Review the document review meeting for approval with the stakeholder’s management team. It will support the request for CAB approval to go ahead with the release tested successfully.

Read more details from the test implementation ISTQB Foundation Level Syllabus 2018…

Test completion work products include test summary reports, action items for improvement of subsequent projects or iterations, change requests or product backlog items, and finalized testware.

ISTQB 2018 Foundation Level

Here’s an example of a TER (Test Exit Report) I usually use. The format will vary depending on the work’s approach, but it gives a general idea of what is expected of you to produce when completing a piece of work.

1.4.4 Explain the value of maintaining traceability between the test basis and test work products

Test work products and names vary greatly. To make test coverage and management work properly, you must maintain a clear connection between test work products and elements of the test basis throughout the test process, as described above.

By providing traceability, you can also:

• Assess the effects of changes.
• Perform auditing.
• Comply with IT governance standards.
• Enhance the comprehensibility of test progress and test summary reports by including the status of test phases (e.g., requirements that have passed tests, those that have failed, and those with pending tests in addition to measuring test coverage and traceability.
• Expressing the test’s technical roles in terms of vocabulary that stakeholders can understand.

Some test management tools comprehensively match test work products as described in this section, while others match only parts of these test work products. As described in this section, organisations create their own management systems to organise the work products and ensure the information traceability they require.

Here. is a simple example of a Software Testing Traceability Matrix from a template I have available for download.

Read more details from the test implementation ISTQB Foundation Level Syllabus 2018…

As mentioned in section 1.4.3, test work products and the names of those work products vary significantly. Regardless of these variations, in order to implement effective test monitoring and control, it is important to establish and maintain traceability throughout the test process between each element of the test basis and the various test work products associated with that element, as described above. In addition to the evaluation of test coverage, good traceability supports:

• Analyzing the impact of changes.
• Making testing auditable.
• Meeting IT governance criteria.
• Improving the understandability of test progress reports and test summary reports to include the status of elements of the test basis (e.g., requirements that passed their tests, requirements that failed their tests, and requirements that have pending tests).
• Relating the technical aspects of testing to stakeholders in terms that they can understand.
• Providing information to assess product quality, process capability, and project progress against business goals.

Some test management tools provide test work product models that match part or all of the test work products outlined in this section. Some organizations build their own management systems to organize the work products and provide the information traceability they require.

ISTQB 2018 Foundation Level

There are a lot of development and test management tools out there, ADO (Azure DevOps) by Microsoft, Jira by Atlassian, TestComplete and Zephyr by SmartBear just to name a few of paid tools that you could use when working in an organisation; these are a few free test management tools as well that you could try out to see how it works to put into practice what you are learning here, or a more modest approach is to use a spreadsheet, there are also a software testing templates out there depending on your system and objectivities you can have one or multiple to cover all your traceability needs.

That’s it for this section. Please tell me what you think. Any feedback is welcome. Thank you and see you at the next one.

If you prefer to watch the whole video about this section in one go instead of parts of the video as I have embedded them above, go and watch it here…

Don’t forget to subscribe, like and share. It will support this channel, help others, and motivate me to create even more content for everyone.