ISTQB FOUNDATION 4.0 | Tutorial 6 | 1.4 Test Activities, Testware & Test Roles (Part-2) | CTFL

Summary

This tutorial delves into the ISTQB Foundation certification, focusing on test activities, testware, and test roles. It outlines essential documentation created during the testing process, such as test plans, schedules, and risk registers, emphasizing the importance of traceability for effective test monitoring and control. The video also highlights the two principal roles in testing: test management and test engineering, detailing their responsibilities and the impact of their tasks on the project's success.

Takeaways

• 📘 Testware refers to documentation created as an output of test activities, including planning, analysis, design, implementation, execution, and completion.
• 📈 Test activities may vary across organizations, but common work products include test plans, schedules, risk registers, and entry/exit criteria.
• 🔍 Test monitoring and control involve tracking progress through test progress reports and managing risks and control directives.
• 📝 Test analysis phase work products include prioritized test conditions, acceptance criteria, and defect reports from static testing.
• 🛠️ Test design phase work products encompass test charters, test data requirements, and test environment requirements.
• 🤖 Test implementation phase produces test procedures, automated test scripts, test suites, and execution schedules.
• 📊 Test execution phase documents include test logs and defect reports, which record the outcomes and issues encountered during testing.
• 📑 Test completion phase work products consist of a test completion report, action items for improvement, documented lessons learned, and any change requests.
• 🔗 Traceability is crucial for mapping test basis with work products, aiding in coverage evaluation, change impact analysis, and facilitating test audits.
• 👥 There are two principal roles in testing: test management, responsible for overseeing the test process and team, and test engineer, focused on the technical aspects of testing.
• 🔑 The distribution of responsibilities between test manager and test engineer can vary and may overlap, depending on the project context and organizational structure.

Q & A

What is the main topic of this tutorial?

The main topic of this tutorial is the fundamentals of testing, specifically focusing on test activities, testware, and test roles in the context of ISTQB Foundation certification.

What does the term 'testware' refer to in the context of this tutorial?

In this tutorial, 'testware' refers to any documentation that is an output of test activities, including planning, analysis, design, implementation, execution, and completion.

What are some examples of work products created during the test planning phase?

Examples of work products created during the test planning phase include the test plan, test schedule, risk register, entry and exit criteria, and documentation of risk analysis outcomes.

What is the purpose of a risk register in the test planning phase?

The risk register serves as a list of identified risks along with their likelihood, impact, and mitigation steps, helping the testing team to manage and address potential risks effectively.

Can the same documentation be used for all testing projects?

No, the creation of documentation can vary depending on the factors influencing the test process. The provided list of work products is not exhaustive and can be more or less depending on the organization's needs.

What is the significance of traceability in the testing process?

Traceability is crucial for mapping the basis of work products, ensuring consistency, and supporting coverage evaluation, test monitoring and control, as well as facilitating test audits and meeting governance criteria.

How does traceability help in evaluating the level of residual risk?

Traceability of test results to risks can be used to evaluate the level of residual risk by determining if the risk has been mitigated or at least reduced from its initial level.

What are the two principal roles in testing according to the ISTQB syllabus?

The two principal roles in testing according to the ISTQB syllabus are test management and test engineer.

What responsibilities does the test management role typically have?

The test management role is responsible for the overall test process, the test team, and leadership of test activities, focusing mainly on test planning, monitoring and control, and test completion.

What are the main activities of the test engineer role?

The test engineer role is focused on the technical aspect of testing, including activities such as analysis, design, test implementation, and test execution.

Can one person take on both test management and test engineer roles?

Yes, in small-scale organizations or depending on the context, it is common for one person to take on both the test management and test engineer roles.

Outlines

00:00

📚 Introduction to Testware and Test Roles

This paragraph introduces the topic of testware and test roles within the context of ISTQB Foundation certification. It outlines the purpose of test activities such as planning, analysis, design, implementation, execution, and completion. The paragraph emphasizes the importance of understanding the documentation produced by these activities, which can vary across organizations. It also introduces the concept of testware as the output of test activities and hints at the significance of proper configuration management for consistency and integrity of these work products. The speaker reassures that the list of work products discussed is not exhaustive but aims to cover common items found across different industries.

05:02

📝 Breakdown of Test Documentation and Traceability

The second paragraph delves into the specifics of test documentation, detailing the various work products created during different phases of the testing process. It covers the planning phase, which includes test plans, schedules, risk registers, and entry/exit criteria. The paragraph also discusses monitoring and control products like test progress reports and risk information. Moving on to test analysis, it mentions prioritized test conditions and defect reports. The design phase involves test charters, data requirements, and environment requirements. The implementation phase's work products include test procedures, automated scripts, test suites, and environment elements. The execution phase yields test logs and defect reports, while the completion phase results in a test completion report and documented lessons learned. The paragraph concludes with an introduction to traceability, explaining its role in mapping test basis to work products and its importance for effective test monitoring and control.

10:02

🔗 The Significance of Traceability in Testing

This paragraph focuses on the concept of traceability, highlighting its benefits and applications within a testing environment. It explains how traceability supports coverage evaluation by linking test cases to requirements, enabling the measurement of test objectives' achievement. The paragraph also discusses how traceability helps in determining the impact of changes, facilitating test audits, and meeting governance criteria. It further elaborates on how traceability makes test progress and completion reports more understandable to stakeholders by providing the status of test bases elements. The benefits of traceability extend to assisting in communicating technical aspects of testing and providing information to assess product quality, process capabilities, and project progress against business goals.

15:04

👥 Roles and Responsibilities in Testing

The final paragraph discusses the standard roles in testing, as identified by the ISTQB Foundation certification. It simplifies the roles into two principal ones: test management and test engineer. The test management role is responsible for overseeing the test process, team, and leadership of test activities, focusing on planning, monitoring, control, and completion. The test engineer role, on the other hand, is responsible for the technical aspects of testing, including analysis, design, implementation, and execution. The paragraph clarifies that these roles can be performed by different individuals depending on the project context, skills, and organizational structure. It also notes that one person can take on both roles, especially in smaller organizations, and emphasizes the importance of adhering to the syllabus for understanding the distribution of responsibilities.

Keywords

💡Testware

Testware refers to the documentation and work products generated as a result of test activities. It includes test plans, schedules, risk registers, and other artifacts that are essential for the planning, execution, and monitoring of testing processes. In the video, testware is discussed as the output of test activities such as planning, analysis, design, implementation, execution, and completion, emphasizing its importance in ensuring the consistency and integrity of test processes.

💡Test Activities

Test activities are the various stages or phases involved in the testing process, including planning, analysis, design, implementation, execution, and completion. These activities form the backbone of the testing lifecycle and are crucial for creating testware. The script mentions these activities as the foundation for generating the set of deliverables and documentation that a testing team should create.

💡Risk Register

A risk register is a document that lists potential risks, their likelihood, impact, and mitigation strategies. It is a key component of the test planning phase, helping teams to identify, assess, and manage risks throughout the testing process. The script explains that the risk register is part of the test plan and includes details on risk likelihood, impact, and mitigation, which are further elaborated in chapter 5.

💡Test Schedule

A test schedule is a document that outlines the timing and sequence of test activities. It is part of the test plan and helps in coordinating and managing the testing process effectively. The script mentions the test schedule as an integral part of the planning phase, which may include entry and exit criteria and is often included within the test plan document.

💡Test Progress Report

A test progress report is a document that provides an update on the status of testing activities, including what has been completed and any issues or blockers. It is used for monitoring and control purposes, allowing stakeholders to stay informed about the testing process. The script discusses the creation of test progress reports at certain milestones, especially in agile methodologies, to keep stakeholders informed.

💡Traceability

Traceability is the ability to track the relationship between different elements of a project, such as requirements and test cases. It is crucial for ensuring that all aspects of a project are covered and for evaluating the effectiveness of testing. The script highlights the importance of traceability in mapping test cases to requirements, facilitating test audits, and assessing product quality and project progress.

💡Test Management

Test management involves overseeing the testing process, including planning, monitoring, and controlling test activities. It is a principal role in testing, with responsibilities that include leadership and coordination of the test team. The script describes test management as a role focused on the overall responsibility for the test process and team, with tasks that vary depending on the project and organizational context.

💡Test Engineer

A test engineer is responsible for the technical aspects of testing, including analysis, design, implementation, and execution of tests. This role is focused on the hands-on activities of testing and is a principal role in the testing process. The script explains that test engineers perform tasks such as writing test cases, preparing automation scripts, and executing tests, which are distinct from the managerial tasks of test management.

💡Test Plan

A test plan is a document that outlines the strategy and approach for conducting tests. It includes details such as test objectives, test environments, resources, and schedules. The script mentions the test plan as a key deliverable in the planning phase, which may encompass risk registers, test schedules, and entry and exit criteria.

💡Test Completion Report

A test completion report is a document that summarizes the outcomes of the testing process, including the results, any defects found, and recommendations for future improvements. It is a work product of the test completion phase. The script describes the test completion report as including action items for improvement and documented lessons learned, which are crucial for enhancing the testing process in subsequent projects or iterations.

💡Test Roles

Test roles refer to the different responsibilities and functions performed by individuals involved in the testing process. The script simplifies these roles into two principal ones: test management and test engineering. These roles dictate the activities and tasks assigned to team members, which can vary based on the project context, individual skills, and organizational structure.

Highlights

Introduction to the ISTQB Foundation certification tutorial series.

Discussion on Chapter 1: Fundamentals of Testing, focusing on test activities, testware, and test roles.

Explanation of testware as documentation output from test activities such as planning, analysis, design, implementation, execution, and completion.

Variation in how organizations produce and manage test process work products.

Importance of proper configuration management for consistency and integrity of work products.

List of common work products in the test process, which is not exhaustive.

Description of work products created during the planning phase, including the test plan, test schedule, risk register, and entry/exit criteria.

Details on the risk register as a list of risks with likelihood, impact, and mitigation steps.

Test schedule as part of the test plan, including monitoring and control products.

Discussion on test analysis work products, such as prioritized test conditions, acceptance criteria, and defect reports.

Explanation of test design phase work products, including test procedures, automated test scripts, test suites, and test environment requirements.

Test execution phase yielding test logs and defect reports as documentation.

Test completion phase work products, encompassing the test completion report and action items for improvement.

Introduction to the significance of traceability in mapping test basis to work products for effective test monitoring and control.

Benefits of traceability, including coverage evaluation, impact determination of changes, facilitation of test audits, and meeting governance criteria.

Roles in testing, focusing on two principal roles: test management and test engineer.

Responsibilities of test management, including test process oversight, team leadership, and completion activities.

Responsibilities of the test engineer, focusing on technical aspects of testing such as analysis, design, implementation, and execution.

Flexibility in role distribution, where one person may take on both test management and test engineer roles, especially in smaller organizations.

Transcripts

Hello friends and greetings for the day

welcome back to another tutorial on

istqb Foundation certification we are in

chapter one talking about the

fundamentals of testing and shall be

continuing ahead with our same segment

that is 1.4 the test activities testware

and test roles and now today we will be

covering the part two of this which

talks about the remaining aspects that

is testware and the test roles in

context

[Music]

well to get started with the very first

thing we are talking today about is the

test wear and this test wear basically

refers to any such documentation which

are the output of test activities we

have discussed about the test activities

in our previous tutorial which were

referred to as planning analysis design

implementation execution and completion

now the question is what are the set of

deliverables and documentation what a

testing sh team should be creating at a

part of this particular process so today

in this particular tutorial we'll be

help helping you to understand the high

level set of documentation which we

generally tend to create as a part of

our test process indeed at this point of

time we also like to let you know that

it's not necessary that these are the

only documentation which you create

sometime it could be less than that

sometime it could be more than that as

well depending on all the factors which

influence your test process so let's

have a look on this what exactly does

that even mean so very first thing is

testware is created as a output work

product from the activities which are

the test activities of the test process

there is a significant variation in how

different organization produce shape

name organize and manage their work

products of course it may not be exactly

the same but things may be around the

same thing now proper configuration

management which basically ensures

consistency and integrity of the work

proc products the following list of work

products is not exhaustive which simply

means one thing that this is not the

complete list of things which may happen

across organizations but we just trying

to bring up those confined list of items

which are quite common among different

Industries so to kick start with the

very first thing is of course the

planning phase as a part of the planning

phase the work products which we

generally create or we include is test

plan test schedule the risk register

which means the risk analysis outcomes

and entry and exit criteria which are

very commonly created and as a

documentation as a part of the test

planning also risk register is basically

a list of risks together with risk

likelihood risk impact and information

about the risk mitigation again you

don't have to worry about at this point

of time that what is risk uh likelihood

impact and mitigation steps we will be

talking about this in chapter 5 in more

detail just because we just want don't

want to dump everything to you right in

the chapter one and do nothing in

chapter 5 we just relevantly will go and

talk about them in the right

chapters test schedule which includes uh

the test schedule which is basically the

risk register entry exit criteria are

often a part of the test plan itself

that means they may not be sometime

created as a separate documentation but

given that you will have a test plan

document already created then that would

be just the part of it similarly if I

move on to the next part that is test

monitoring and control products we these

include the test progress report

documentation of control directives and

the risk information again indeed as a

part of monitoring we are keeping an eye

on different matrices as a part of the

progress of the life cycle at any point

of time we may create a test progress

report spe specifically at certain

milestones for example if you're talking

about agile methodology I can create a

progress report every single Sprint and

share it with different stakeholders of

our organization to make sure that they

just get the point and get to know that

what exactly testing team is progressing

with and what are the blockers and many

other things however again as I

mentioned earlier the reports will be

discussed in detail with the example in

chapter 5 so if we talk about the next

phase which is test analysis the work

products which are included here

generally the prioritized test

conditions which includes the acceptance

criteria as well and uh defect report

regarding the defects in the test basis

so here it is more of like static

testing defects which is more of like as

you review the requirements as you

review the designs as you review the

other work products which are basis for

testing you may have found certain

defects related to that so all those

defects will be a part of this

particular documentation or this

particular phase giving you the

information about the list of defects in

turn these defects also help us

understand the effectiveness of the

review because uh if the reviews are not

effective we will look for forward to

improve it over a period of time so

certainly these defects inputs will add

a lot of value towards the Improvement

of the static testing processor as well

continuing on the next we do have our

next phase as test analysis where test

analysis work products include the

prioritized test cases that means not

just not the test cases which we write

but at the end of the day this will be

highly prioritized that means what are

the high priority test cases medium

priority TK cases and low priority desk

cases also as a part of it you will also

produce test Charters just test Charters

are basically a log sheet which is used

in the exploratory testing which is one

type of informal test technique and

we'll talk about this in chapter 4 in

more detail then we do have test data

requirements and the test environment

requirements so anything related to

requirements uh of data anything related

to the environment if you're creating

any sort of documentation that will be

an outcome of test design phase also

when we talk about the next phase that

is test implementation the work products

what we produce here are generally the

test procedure the automated test

scripts the test Suites the data the

execution schedule the environment

elements and if I talk about the example

of test environment elements it includes

stuff driver simulator and service

virtualization so again it's not

necessary that every single organization

can really go ahead and create a

documentation on environment we may just

have it as an environment Al together

but it may be useful for many other

teams or different stakeholders to

perform other testing then we may go

ahead and document it because I as a

functional team member I may be aware of

what exactly environment is but my

non-functional testing team does not

know about it so I may have to

communicate something to them right so

in that context you may go ahead and

create a documentation which talks about

what the environment comprises of and

what does it do so in that context it

certainly helps you to understand what

exactly are the environment details

continuing next of course the test

execution phase it returns us with the

documentations like test logs and defect

reports test logs are the execution

reports which you will have of course

during the execution and if in case of

any failures you do report defects so

the defect reports will also be one of

the work product from here finally

talking about the test completion the

test completion work products basically

includes the test completion report

Action items for improvement of

subsequent projects or iterations

documented Lessons Learned and change

request if any right which is basically

a PBI product backlog items or certainly

the retrospective will become my lessons

learned here so we may look forward to

documented to contain all the

information which helps us to improve in

our upcoming Cycles so put together

these are all the work products which we

generally tend to create as a part of

the testing life cycle but you don't

have to really buy hard them a simple

straightforward tip is to help you

remember this is even if you remember

the process that is the test activities

from the previous tutorial you know

exactly what work products will be there

so all you have to just remember is what

are the set of activities we do and as a

part of the activity of course there is

a byproduct and that by byproduct is

what you call it as a documentation so

if you compare it back with the next

previous tutorial you will pretty much

understand that yes every single

activity is turning into a documentation

and those are the document itself so it

will be easy to remember for you from

the examination point of view in

continuation to the same we are also

trying to talk about the significance of

traceability traceability in simple

words means that we talking about

mapping a basis with that of the work

product what is the example the example

says that if I have created test cases

from a particular set of requirement it

is my responsibility to connect both of

them or map both of them so that at any

point of time if I have to measure the

coverage achieved on the requirement

it'll be easy for me to determine that

of course virtually I can go ahead and

talk about the percentage coverage

achieved on the requirement but in real

time project especially when it comes to

audits they may ask you for a reference

that how did you derive these number of

test cases which requirement did you

refer and I don't see a link associated

with that so we must always have

traceability between any test basis to

that of any work product which we just

covered a moment ago so no matter even

if you're talking about test plan a test

plan should be mapped to the respective

version of the project plan because it

would be necessary for many benefits of

having traceability so let's understand

more about what could be the benefit of

traceability at the same time a little

Deep dive on what do we mean by

traceability in order to implement

effective test monitoring and control it

is important to establish and maintain

traceability throughout the test process

between the basis elements test where

associated with these elements that

means it is really important to do it

between both of them example the test

conditions risk test cases or even if I

talk about the test results and detected

defects should be linked back to their

respective parents accurate traceability

supports coverage evaluation so it is

very useful if measurable coverage

criterias are defined in the test basis

the coverage criteria can function as

key performance indicators to drive the

activities that allow to what extent the

test objectives have been achieved so I

think that totally makes sense that when

it comes to the measure of coverages and

achievement of your goal or to certain

percentage measurement that how much we

are done how much more to go the trace

abilities will help you toine the same

so the examples included here are

basically the traceability of the test

cases to that of requirements can verify

that the requirements are covered by the

test cases whereas with this we call it

as RTM requirement traceability Matrix

and the second is traceability of test

results to risk can be used to evaluate

the level of residual risk in the test

object so yes at this point of time

given that we are not talking about risk

in detail yet we can just let you know

that yes test results helps us to

determine if the risk has been mitigated

or at least the level of risk has been

reduced from high to low or high to

medium and it's not that the

traceability just helps you with the

coverage there are multiple other

benefits of having traceability within

your project or within your

organizations so some of these benefits

are listed here for example a good

traceability makes it possible to

determine the impact of changes for

example if tomorrow requirements gets

modified then I would not be able to

judge if I don't have traceability I

will not be able to judge if my existing

test cases are still enough or I need to

add more test cases to cover the change

in the requirement just by having

traceability you will be able to see

what are the test cases written for it

and as far as the test cases you can see

you can determine that whether you need

to add something more or the existing

test cases will be enough so

traceability will just give you

establishment of the link between the

requirement and the test cases and

anytime you want to see what test cases

are written for this requirement it'll

be very easy to do so at the same time

if I talk about the next example it says

facilitates test Audits and helps meet

it governance criteria Auditors of

course will look forward to understand

that if you did anything in the entire

test process why did you do that and how

is it benefiting the project because

even if you're writing test cases an

auditor would look forward to understand

that how these test cases are helping me

in the project so if you don't have

tracability to that of the requirement

it may not be justifiable right and it

governance criteria simply means that at

some point of time the it governance

criteria requires you to link things

together in terms of having being

measured so as far as like anything is

being linked then it do make sense that

what belongs where or how they're

related to each other for an example if

I have written 40 test cases for a

requirement and exactly same requirement

which is like other requirement with the

same complexity and same priority I've

written only 20 test cases now the

scenario would be that I just have

another uh critical requirement whereas

the other requirement is also critical

but both of them have different number

of test cases now I can go and talk

about that requirement one has a risk

associated whereas requirement two

doesn't have a risk Associated so it

does not really bother you any further

when it comes to the governance criteria

that how did you decide to go different

proportionality of test cases when it

comes to similar type of requirements so

that's one of the example to talk about

how traceability can save your day in

terms of it governance criteria also to

talk about Good traceability Makes test

progress and completion reports more

easily understandable by including the

status of the test bases elements that

means a business stakeholder will not be

able to understand that what did you do

by doing 20 executions until unless I

have a traceability back to the

requirement because they are least

bothered about your test cases they are

mainly bothered about how much

requirement has been completed at that

point of time so from the execution you

can derive it back to the requirement

that hey I did 50 executions today but

these 50 executions have covered 20% of

requirement 20% of requirement and that

totally makes sense to a business right

the next one we have is of course this

can also be assist in communicating the

technical aspects of testing to

stakeholders in an understandable Manner

and traceability provides information to

assess product quality capability of

process and project progress against

business goals so again if you further

Deep dive you would also be able to

understand that it is very very

beneficial in terms of determining how

is my progress happening on the project

level what is my process capabilities

because of having many other information

Associated there so you currently may

not really need that explanation because

it's covered more in detail at the

manager level but on a high level they

just wanted to let you know that

traceability is just not limited to

coverage measurement it can even help at

the organization level to build a better

aspect altoe well moving on to the next

one of course the last segment of this

particular topic that is roles in

testing and here we are just trying to

highlight to you that what are the

standard roles when it comes to testing

within an organization so it's very

simple and easy to understand that in

this syllabus we just consider two

principal roles of testing that is one

is test management and one is the test

engineer so it may be very easy to

understand and correlate because uh

every single project has just two

important roles everyone else is a test

engineer and there'll be one test lead

or test manager but when it comes to our

realtime designations and roles and

responsibility you may see a lot of

different you know designations awarded

to people like like you are a lead

engineer you are a junior engineer you

are a senior software engineer you might

be a technical lead but a for a project

you are either a manager or you're just

an engineer so istqb does not

differentiate between the designations

they say your responsibilities are

generally determined by the designation

which we have understand that is either

you are a test manager or you are just a

tester okay so we just have two standard

roles however when it comes to the

activities and task assigned to these

two roles they depend on factors such as

project and product context the skills

of the people in the roles and the

organizations as well for example the

test management role takes overall

responsibility for the test process the

test team and Leadership of the test

activities the test management role is

mainly focused on the activities of test

planning test monitoring and control and

test completion the way in which the

test management role is carried out and

varies depending on the context so it's

not that like uh it's just that tester

and test manager are exactly the same

the manager will lead the overall team

and take the ownership on defining

determining planning scheduling

selecting Etc and whereas the QC part

that is like performing all the

activities will be done by the test

engineer so there's a quick example

right here so for example in a software

development uh some of the test

management task may be handled by the

agile team the task that span multiple

teams or the entire organization may be

performed by the test managers outside

of the development team right now on the

other hand if I talk about the testing

role it takes overall responsibility of

the engineering which is the technical

aspect of testing the testing role is

mainly focused on activities of analysis

design test implementation and testt

execution which in turn means that going

through the requirements writing the

test conditions the test cases preparing

the automation test Scripts uh the

execution schedule prioritization of the

test cases these are all done by the

test Engineers not the test manager

manager is more from the perspective of

the process also different people may

take on these roles at different times

that means within the team you know

people can go ahead and take ownership

on different responsibilities for

example the test management role can be

performed by a team leader by a test

manager by a development manager Etc

depending on the availability of the

right person within the organization

okay and it is also possible for one

person to take on the role of testing

and test management at the same time

that means in a small scale organization

it is quite often common that a person

who will be playing the role of Team

lead can also be a tester within the

project so I think that pretty much

makes a lot of sense that what exactly

are the distribution of responsibilities

between a test manager and test engineer

and at some point point of time we do

understand that the realistic

distribution of the work and

responsibilities are slightly different

between the members so that's all what

we had from here but of course you have

to stick to the syllabus in order to

answer a question so just stick to that

so that's all from this particular

tutorial team should you have anything

else feel free to comment below I'm

always there to address your queries and

answer them well till then keep learning

keep exploring keep understanding the

context thanks for watching the video

team and happy

learning

[Music]