ISTQB FOUNDATION 4.0 | Tutorial 39 | Checklist Based Testing | Test Techniques | ISTQB Tutorials
Summary
TLDRThis tutorial on ISTQB Foundation Level certification focuses on checklist-based testing, a technique used in both static and dynamic testing. The video explains how checklists, composed of specific questions, help testers ensure product quality by verifying functional and non-functional requirements. It emphasizes the importance of regularly updating checklists to reflect new features and defects, while cautioning against overly long or overly high-level checklists. The tutorial provides practical examples and underscores the balance needed for effective checklist design.
Takeaways
- 📝 A checklist in testing is a questionnaire with questions about a particular product, used for both static and dynamic testing.
- 🔍 Checklists are designed for specific work products, such as user stories, and can help identify defects through a series of yes/no questions.
- 🛠️ In dynamic testing, checklists are preferred for standard products like TV remotes, avoiding the need to write detailed test cases for each feature.
- 📋 Checklists should be based on experience, knowledge about user importance, and understanding of common software failure points.
- 🚫 Checklists should exclude items that can be automated, are too general, or better suited for entry/exit criteria.
- ❓ Checklist items are phrased as questions, allowing for direct and separate verification of each item.
- 🔄 Checklists can support various test types, including both functional and non-functional testing.
- 🔄 The effectiveness of checklist entries may decrease over time, necessitating regular updates to reflect new defects and remove outdated items.
- 📉 A common drawback of checklists is the lack of regular updates, which can lead to checklists becoming outdated as products evolve.
- 📈 Checklists should be reviewed and updated with each version change of a product to ensure they remain relevant and effective.
- 🔍 The balance of a checklist should be moderate, not too long to maintain consistency, but detailed enough to provide clear guidelines for testing.
Q & A
What is the main topic of this tutorial?
-The main topic of this tutorial is the 'Checklist Based Testing' technique, which is part of the ISTQB Foundation Level certification course, specifically covered in Chapter 4, Section 4.4.
What is a checklist in the context of testing?
-A checklist in testing is a questionnaire consisting of several questions that are asked about a particular product during testing. It is widely used in static testing and is designed specifically for a work product.
How is a checklist used in static testing?
-In static testing, a checklist is used to review work products like user stories. It contains questions related to the work product, such as clarity, understandability, and acceptance criteria, which are answered with yes or no to determine if the product is ready for implementation.
Can you provide an example of how a checklist is used in dynamic testing?
-In dynamic testing, a checklist can be used to test standard products like a TV remote control. Instead of writing detailed test cases, testers use a checklist with questions about the product's features and functionality to ensure it works as expected and identify any defects.
What are some characteristics of checklist-based testing?
-Characteristics of checklist-based testing include the tester designing, implementing, and executing tests to cover conditions from a checklist. Checklists are based on experience, knowledge about user importance, or understanding of software failure reasons. They should not contain items that can be checked automatically or are too general.
Why is it important for a checklist to be regularly updated?
-It is important for a checklist to be regularly updated to reflect newly found defects, added features, and to remove items that are no longer applicable. This ensures the checklist remains effective and relevant to the product being tested.
How can checklists support various test types, including functional and non-functional testing?
-Checklists can support various test types by including questions that pertain to both functional and non-functional requirements. They can be used to review different aspects of the product, ensuring a comprehensive testing approach.
What is a common drawback of using checklists in any industry?
-A common drawback of using checklists is that they are often not updated regularly. Once created, checklists can become outdated as products evolve, leading to inefficiencies and missed defects.
Why is it crucial to avoid letting the checklist become too long?
-It is crucial to avoid letting the checklist become too long to maintain its effectiveness and ease of use. A lengthy checklist may become cumbersome and reduce the consistency and repeatability of testing.
How can a checklist help in mapping to requirements and measuring coverage?
-A checklist can help in mapping to requirements by ensuring that each test condition is addressed. It can also assist in measuring coverage by providing a clear view of which areas of the product have been tested and which have not.
What is the final advice given in the tutorial regarding the use of checklists?
-The final advice is to ensure that checklists are reviewed and updated frequently, especially when there are changes in the product version. It also emphasizes the importance of maintaining a balance in the checklist's level of detail to ensure it is useful for testers and can be repeated if necessary.
Outlines
📝 Introduction to Checklist-Based Testing
This paragraph introduces the concept of checklist-based testing as part of the ISTQB Foundation Level certification tutorial. It explains that a checklist is a questionnaire used in both static and dynamic testing to evaluate a product. The tutorial focuses on how checklists are designed for work products, such as user stories, and how they are used to identify defects by answering a series of yes-or-no questions. The speaker also contrasts the use of checklists with writing detailed test cases, emphasizing the efficiency and standardization that checklists bring to testing common products like TV remotes. The paragraph concludes by discussing the importance of a tester's experience in creating a relevant and effective checklist.
🔍 Characteristics and Considerations of Checklist-Based Testing
The second paragraph delves into the characteristics of checklist-based testing, highlighting its reliance on a tester's experience to create checklists that cover important test conditions. It mentions that checklists should exclude items that can be automated or are too general, focusing instead on functionality and validation. The paragraph also addresses the versatility of checklists, applicable to both functional and non-functional testing. The importance of regularly updating checklists to reflect new defects and features is underscored, along with the common pitfall of checklists becoming outdated. The speaker uses the analogy of a car service center's checklist to illustrate the need for regular updates. The paragraph concludes with a discussion on the balance needed in creating checklists—to be high-level enough for broad application but detailed enough to ensure consistency and repeatability in testing.
Mindmap
Keywords
💡ISTQB Foundation Level Certification
💡Test Analysis and Design
💡Experience Based Test Technique
💡Checklist Based Testing
💡Static Testing
💡Dynamic Testing
💡Work Product
💡Acceptance Criteria
💡Defect
💡Consistency
💡Repeatability
Highlights
Introduction to the tutorial on ISTQB Foundation level certification, focusing on Chapter 4 about test analysis and design.
Explaining the concept of a checklist as a questionnaire for testing a product, commonly used in static testing.
Checklist design tailored for specific work products, such as user stories, with example questions provided.
Use of checklists in dynamic testing for standard products like a TV remote, avoiding the need for detailed test cases.
Characteristics of checklist-based testing, including the tester's role in designing and executing tests from a checklist.
Checklists should be based on experience, knowledge about user importance, or understanding of software failure reasons.
Checklist items should not include automated checks, entry/exit criteria, or overly general items.
Items in a checklist are often phrased as questions, allowing for direct and separate verification.
Checklists can support various test types, including functional and non-functional testing.
The importance of regularly updating checklists based on defect analysis to maintain their effectiveness.
The drawback of checklists being infrequently updated and the need for regular review and updates.
The analogy of a car service center using a checklist to emphasize the importance of regular updates.
The necessity of adapting checklists to evolving software products and new features.
Balancing checklist length to provide guidelines and consistency without being overly detailed or too high-level.
The challenge of maintaining repeatability when using high-level checklists without detailed test cases.
The tutorial's conclusion emphasizing the importance of understanding checklist-based testing techniques.
Invitation for viewers to comment with queries and an encouragement to continue learning and exploring.
Transcripts
Hello friends and greetings for the day
welcome back to another tutorial on
istqb Foundation level certification we
are in chapter 4 talking about test
analysis and design and continuing ahead
with our same segment that is 4.4
experience based test technique and as a
part of today's tutorial we'll be
talking about the next technique which
is checklist based
testing
so before we start talking about this
technique in detail let me just give you
a quick outline of what is meant by a
checklist so checklist is basically a
questionnaire which consists of several
questions which you ask about a
particular product when you're testing
it however this is very widely even used
in static testing but the checklist will
be designed specially for a work product
then for an example if I have to review
a user story I will have questionss
related to user story for example I can
talk about things like um whether the
user user story is clear understandable
achievable has a clear set of acceptance
criteria whether user Persona is
identified whether user story is
independent U testable small and sort of
thing so I will have some 15 to 20
questions which I generally have to
answer it as yes or no given that if all
all the questions have an answer as yes
the story is reviewed ready for
implementation or picking up in the
Sprint same way if any question turns
into no then that's a defect in the
review of the user story now that's same
checklist based testing but used for
static testing but when it comes to
Dynamic testing as a technique then it
is more about the product so say for
example if I'm trying to test a
particular remote control like you might
certainly have a TV at home so you can
just imagine your TV remote in your hand
now certainly we don't write an Excel
sheet to test a TV remote we rather
prefer having a checklist because these
are very standard products and certainly
comes with standard features so I don't
really have to write a test case that
pick the remote in hand then step two
click on the red button it should have a
circle with another circle with a hyphen
no that's a waste of time so when it
comes to a hardcore product things like
you know a microwave oven refrigerator
or probably an iron box or you know TV
and whatnot all the appliances
equipments Etc we did not write detailed
test cases we make use of checklist
where checklist consist of all that
question which should be answered in
terms of making sure the product is
working dynamically fine and then
finding any defect so say for example if
remote I'm testing I would make sure
that the questions are like whether the
remote has power button red in color
whether all of the buttons are black in
color whether the numbers are printed
clearly whether the numbers are clearly
or readable by the user so people will
pick up a remote and perform all this
act actually on the product same way if
the you know the volume button has a
plus or minus icon on it and whether the
channel channel button has a plus or
minus icon on it so all these will
become my question and will put together
be called as a checklist a checklist is
basically a questionnaire which is used
instead of test cases to tester system
okay so now let's talk about the
characteristics of these this technique
that what exactly a checklist based
testing is all about so the most
important thing in checklist based
testing a tester again designs
implements and execute test to cover
test conditions from a checklist
checklist can be built based on
experience knowledge about what is
important for the user or an
understanding of why and how the
software fails so the most important
Point here is hey if you want you can
create a oneliner uh test cases test
case from here as well but not detailed
again high level oneliner but but the
most important thing is what is
checklist who prepares it so of course a
tester's experience is very much
important in order to define the
checklist now additionally checklist
should not contain items that can be
checked automatically items better
suited for entry or exit criteria or
items that are too General so of course
it's very important that we should only
include the things what is applicable
for checklist because it's not that if
things are being automated then let this
be covered by automation or things which
are basically related to entry and exit
criteria then it should be included in
entry and exit criteria so all we are
trying to say that what we already have
as a document should not be a part of
checklist checklist should be uniquely
talking about the functionalities and
validating them now right here checklist
items are often phrased in form of
questions it should be possible to check
each item separately and directly these
items May refer to requirement graphical
interface properties quality character
characteristics or other form of test
condition so it can be any type of
requirement which you can review by
checklist but again it has to be written
in the form of question which you ask to
the product and if it is true yes if it
is not it's a defect next checklist can
also be created to support various test
types including functional and
non-functional quite often people think
that checklist are only limited to
functional testing but indeed it can be
very helpful in non-functional testing
also further to add of course
some checklist entries May gradually
become less effective over time because
the developers will learn to avoid
making the same errors new entries may
also need to be added to reflect newly
found High severe defects therefore
checklist should be regularly updated
based on defect analysis now let me tell
you something very important the only
drawback of checklist or only drawback
of having checklist being used in any
industry is that they are not time to
time updated we just created once and
most often they are left as it is I'm
not sure if you have been to a service
of your vehicle recently Let It Be two-
wheeler four-wheeler whatever right a
car or a bike the person from the
service center comes with a checklist he
starts your ignition checks the horn
indicator lights Etc tires and
everything and he has a checklist in his
hand to be frank and he keeps scking yes
no yes no whether it is working or not
and whatever is not working working he
will let you know that so that he claims
that it was already not functioning well
do you want me to fix it if you say no
no that's fine I don't want to invest
right now then he says yeah just sign it
here that it's not working right and all
the dents and scratches will be all
mentioned now that checklist is exactly
the same thing what you saw 5 years ago
in his hand so most most often things
like checklist are left unattended
however the product has revolved around
over a period of time
and let me tell you something you go to
a car service center they will bring the
same checklist no matter which model car
it is correct the same company has so
many models of car but they still use a
very common checklist why because they
cannot maintain that it's difficult to
maintain multiple things but it doesn't
happen in our industry given that things
are different because they're managing
it and we don't manage it so make sure
that when it comes to our software or
product which evolves every year you
know renews adds new features then make
sure those new features are added common
mistakes are added the things which are
no longer in the product should be
removed so check list should be reviewed
and updated quite often as in when the
version changes finally to add here that
however care should be taken to avoid
letting the checklist become too long in
the absence of detailed test cases
checklist space testing can provide
guidelines and some degree of
consistency for testing if the checklist
are high level some variability in the
actual testing is likely to occur
resulting in potentially greater
coverage but less repeatability however
we know that all these are
experience-based test techniques so we
don't expect the things like
documentation like uh checklist to be as
long as possible we try to make it as
high level as possible so that it is
very to the point and just catters the
need of the tester but sometime making
this very very high level could only be
understandable by the tester thus
repeating these test cases would become
very difficult you need the same person
to perform this again or you will really
need the detailed test cases which will
be against the informal techniques so
point being made is that make sure that
you have a very moderate thing not too
long but at the same time not so high
level that it becomes difficult for
repeating the test cases if in case you
need however it will still help you to
map to the respective requirements and
measure the required coverage what you
may need in order to Define find the
coverage measurement so that's all from
the checklist based testing techniques
team and uh I hope you have got a good
understanding of that to so that's all
from this particular tutorial 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
[Music]
learning
[Music]
Ver Más Videos Relacionados
ISTQB FOUNDATION 4.0 | Tutorial 18 | Test Types | Functional Testing | Non-Functional Testing | CTFL
ISTQB FOUNDATION 4.0 | Tutorial 7 | 1.5 Essentials Skills and Practices in Testing (Part-1) | CTFL
ISTQB FOUNDATION 4.0 | Tutorial 46 | Entry Criteria & Exit Criteria | Test Management | CTFL
ISTQB FOUNDATION 4.0 | Tutorial 57 | Tool Support for Testing | Test Tools | ISTQB Tutorials
ISTQB FOUNDATION 4.0 | Tutorial 36 | Value of White Box Test Techniques | CTFL Tutorials | TM SQUARE
ISTQB FOUNDATION 4.0 | Tutorial 29 | Test Techniques Overview | Test Design Techniques | CTFL
5.0 / 5 (0 votes)