ISTQB FOUNDATION 4.0 | Tutorial 6 | 1.4 Test Activities, Testware & Test Roles (Part-2) | CTFL
Summary
TLDRThis 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
📚 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.
📝 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.
🔗 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.
👥 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.
Mindmap
Keywords
💡Testware
💡Test Activities
💡Risk Register
💡Test Schedule
💡Test Progress Report
💡Traceability
💡Test Management
💡Test Engineer
💡Test Plan
💡Test Completion Report
💡Test Roles
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]
Weitere ähnliche Videos ansehen
ISTQB FOUNDATION 4.0 | Tutorial 57 | Tool Support for Testing | Test Tools | ISTQB Tutorials
ISTQB FOUNDATION 4.0 | Tutorial 52 | Test Monitoring & Test Control | Test Metrics | ISTQB Tutorials
ISTQB FOUNDATION 4.0 | Tutorial 5 | 1.4 Test Activities, Testware & Test Roles (Part-1) | CTFL
ISTQB FOUNDATION 4.0 | Tutorial 53 | Test Progress Report | Test Summary Report | CTFL Tutorials
ISTQB FOUNDATION 4.0 | Tutorial 44 | Purpose and Context of Test Plan | Test Management | CTFL
ISTQB FOUNDATION 4.0 | Tutorial 55 | Defect Management | Defect Report Template | CTFL Tutorials
5.0 / 5 (0 votes)