ISTQB FOUNDATION 4.0 | Tutorial 26 | Review Types | Informal, Walkthrough, Technical & Inspection

Summary

This tutorial delves into the ISTQB Foundation Level Certification, focusing on Chapter 3.2.4: Review Types. It explains the necessity of different review processes, from informal to formal, based on factors like SDLC, development maturity, and regulatory requirements. The video outlines four main review types: informal reviews, walkthroughs, technical reviews, and inspections, highlighting their unique aspects and objectives. Aimed at helping viewers understand when and how to apply each review type effectively, it emphasizes the importance of selecting the right review process to achieve review objectives and improve the SDLC.

Takeaways

• 📚 The tutorial discusses the ISTQB Foundation level certification, focusing on Chapter 3, specifically the feedback and review process in static testing.
• 🔍 The script delves into the different types of reviews, explaining that not all documentation requires the same level of review formality due to their distinct nature and audience.
• 📈 The necessity of selecting an appropriate review type is emphasized, influenced by factors such as the SDLC model, development process maturity, work product criticality, legal requirements, and the need for AIT trade.
• 🔑 The script highlights that the same work product can undergo different review types at different stages, starting from informal to more formal reviews as needed.
• 👥 The importance of selecting the right review type for achieving the required review objective is stressed, based on project needs, available resources, work product types, risk, business domain, and company culture.
• 🚶‍♂️ The tutorial introduces four main review types: informal review, walk-through, technical review, and inspection, with inspection being the most formal and synonymous with the formal review process.
• 👥 Informal reviews are described as not following a defined process, requiring no formal documented output, and mainly involving two people, often referred to as buddy checks.
• 🚶‍♂️‍👤 Walk-throughs are led by the author, serve multiple objectives, and may or may not include individual reviews before the meeting.
• 👨‍🏫 Technical reviews involve technically qualified reviewers and a moderator, aiming to gain consensus on technical problems and improve work product quality.
• 🔍 Inspections are the most formal type of review, with a complete generic process, entry and exit criteria, and dedicated roles and responsibilities for participants.
• 🎓 The tutorial concludes by encouraging viewers to understand the different review types and their applicability in real-world scenarios, which is crucial for answering related examination questions.

Q & A

What is the main topic of this tutorial?

The main topic of this tutorial is the feedback and review process, specifically focusing on the different types of review in the context of ISTQB Foundation Level certification.

Why is it important to understand different review types in software documentation?

It is important to understand different review types because various documents have different levels of criticality and complexity, and applying a one-size-fits-all review process is not efficient or effective.

What are the factors that influence the selection of the appropriate review type?

Factors influencing the selection of the review type include the SDLC model being followed, maturity of the development process, criticality and complexity of the work product, legal or regulatory requirements, and the need for an audit trail.

What is the difference between a project plan and a test case in terms of review process?

A project plan contains detailed information about the entire project and is typically reviewed with a more formal process, while a test case is limited to the testing team and developers, and may require a less formal review process.

What is an informal review in the context of software documentation?

An informal review is a process that does not follow a defined process and does not require formal documented output. It mainly aims to detect anomalies and often involves just two people, such as a tester and a colleague or a test lead.

What is a walk-through review and who typically leads it?

A walk-through review is a type of review led by the author of the document. It serves various objectives such as evaluating quality, building confidence in the work product, and generating new ideas.

What are the unique aspects of a technical review?

A technical review is conducted by technically qualified reviewers and is led by a moderator. The unique aspects include the use of subject matter experts as reviewers and the focus on gaining consensus and making decisions regarding technical problems.

What is an inspection and how does it differ from other review types?

An inspection is the most formal type of review, following a complete generic process with defined entry and exit criteria, checklists, and standard roles and responsibilities. It aims to find the maximum number of anomalies and is unique in its formal structure and process.

Why is the selection of the right review type crucial for achieving the required review objective?

The selection of the right review type is crucial because it ensures that the review process is tailored to the specific needs of the document being reviewed, taking into account factors such as project needs, available resources, work product types, and risk.

Can the same work product be reviewed using different review types at different stages of the development process?

Yes, a work product can initially be reviewed using an informal review process and later undergo a more formal review process as needed, demonstrating the flexibility in applying different review types based on evolving project requirements.

How do regulatory and contractual requirements influence the review process?

Regulatory and contractual requirements can drive the need for certain types of reviews, such as formal inspections, even if the development process would otherwise prefer a less formal approach. Compliance with these requirements is critical to avoid findings during audits.

Outlines

00:00

📚 Introduction to Review Types in ISTQB Foundation Level

This paragraph introduces the topic of review types within the context of the ISTQB Foundation level certification, focusing on chapter 3.2.4 which discusses feedback and review processes. It emphasizes the importance of understanding different documentation review types due to the varying nature and criticality of documents. The paragraph highlights that not all documents require a formal review process, such as comparing a project plan to test cases, which are fundamentally different in nature and stakeholders' involvement. The tutorial aims to teach the audience about the various review types and how to apply them appropriately based on factors like the SDLC model, development process maturity, work product complexity, legal requirements, and the need for AIT trade-offs.

05:00

🔍 Exploring the Four Major Review Types in Software Testing

The second paragraph delves into the specifics of the four main review types: informal reviews, walk-throughs, technical reviews, and inspections. It begins by discussing informal reviews, which are simple and do not require a formal process or documented output, primarily used for detecting anomalies with minimal participants, often referred to as buddy checks. The paragraph then moves on to describe walk-throughs, which are led by the author and serve multiple objectives such as quality evaluation, consensus building, and idea generation. Technical reviews involve technically qualified reviewers and a moderator, with the unique point being that they are conducted by subject matter experts. Lastly, inspections are the most formal type of review, following a complete generic process with specific roles and objectives, including finding the maximum number of anomalies and using checklists for process improvement.

10:02

👥 Roles and Objectives in Technical Reviews and Inspections

The final paragraph focuses on the unique aspects of technical reviews and inspections, emphasizing the roles and objectives involved in these processes. Technical reviews aim to gain consensus on technical problems, detect anomalies, and evaluate the quality of work products, with the author not leading the review. Inspections, being the most formal, have entry and exit rules, checklists, and clearly defined roles and responsibilities. The author is not allowed to act as a review leader or scribe, and the process is designed to find as many anomalies as possible while also building confidence in the work product and motivating improvements. The paragraph concludes by encouraging the audience to understand these review types for practical application and to be prepared to answer related questions, highlighting the importance of context in the examination.

Keywords

💡ISTQB Foundation Level Certification

The ISTQB Foundation Level Certification is an internationally recognized qualification for software testers. It signifies that the individual has a foundational understanding of software testing principles and practices. In the video, this certification is the overarching theme, as the tutorial is designed to help viewers prepare for the certification exam, specifically focusing on Chapter 3 about static testing.

💡Static Testing

Static testing refers to the evaluation of software programs without executing the code. It involves the review of documents and code to identify defects, inconsistencies, or areas for improvement. In the script, static testing is the main focus of Chapter 3, where different types of reviews within this context are discussed.

💡Feedback and Review Process

The feedback and review process is a critical part of software development where team members provide input on work products to ensure quality and adherence to requirements. The script discusses this process in the context of static testing, emphasizing its importance in identifying issues before the execution phase.

💡Review Types

Review types categorize the various methods of evaluating documentation and code within software development. The script outlines different levels of formality in reviews, from informal to formal, and explains how the choice of review type depends on factors such as the document's criticality and the development process being followed.

💡Documentation

Documentation in software development includes project plans, test cases, and other written materials that guide the development and testing process. The script mentions different types of documentation and how they may require different review processes based on their importance and use within the project.

💡Informal Review

An informal review is a less structured and less formal process where a document is reviewed by a small number of people, often just two, to detect anomalies. The script uses the example of a tester asking a colleague to review their test cases as a form of informal review, highlighting its simplicity and usefulness in agile methodologies.

💡Walkthrough

A walkthrough is a type of review led by the author of the document, with the goal of achieving various objectives such as quality evaluation and consensus building. The script describes the walkthrough as an informal process where the author guides the review, which is different from more formal reviews led by a moderator.

💡Technical Review

Technical review involves subject matter experts or technically qualified reviewers to assess the work product, typically led by a moderator. The script explains that this type of review is meant for gaining consensus on technical issues and detecting anomalies, emphasizing the role of technical expertise in the review process.

💡Inspection

Inspection is the most formal type of review, following a structured process with defined roles and responsibilities. The script equates the formal review process discussed earlier with inspection, noting that its main objective is to find as many anomalies as possible and to evaluate the quality of the work product.

💡SDLC

SDLC stands for Software Development Life Cycle, which refers to the process of creating software, from concept to delivery and maintenance. The script mentions SDLC in the context of how the review process might vary depending on the phase of the SDLC and the maturity of the development process.

💡Criticality

Criticality in the context of software development refers to the importance or priority of a work product or process. The script discusses how the criticality of a document or process can influence the level of formality required in its review, with more critical items potentially necessitating more formal reviews.

Highlights

Introduction to different review types in the context of static testing.

Explanation of why different documents require different review processes.

Differentiating between critical and non-critical documents in the review process.

The importance of selecting the appropriate review type based on various factors.

Overview of the factors influencing the choice of review type, such as SDLC, maturity, criticality, and legal requirements.

Agile methodology's preference for informal reviews due to its lightweight process.

Waterfall model's suitability for formal reviews due to its structured approach.

The concept that the same work product can undergo different review types at different stages.

The significance of achieving review objectives through the right selection of review type.

Description of informal reviews, which do not follow a formal process and involve only two people.

Informal reviews' utility in Agile for preventing defects without heavy formalities.

Explanation of walk-through reviews, led by the author with optional individual review beforehand.

The objectives of walk-through reviews, including quality evaluation, consensus building, and idea generation.

Technical review's requirement of technically qualified reviewers and a moderator.

Technical review's focus on consensus and decision-making regarding technical problems.

Inspection as the most formal review type, following a complete generic process.

Inspection's unique points, including entry/exit rules, checklists, and defined roles and responsibilities.

The importance of understanding different review types for practical application and exam preparation.

Transcripts

Hello friends and greetings for the day

welcome back to another tutorial on

istqb Foundation level certification we

are in chapter 3 talking about static

testing and as a part of this tutorial

We are continuing ahead with 3.2 that is

feedback and review process and today we

shall be covering the next segment under

this topic that is

3.2.4 review types and here you'll get

to understand how exactly different

documentation can undergo review but not

so formal as we did discussed

earlier as we all understand of course

different documentations are not exactly

the same some documents are very

critical some documents are lightweight

some documents are heavyweight and

sometimes some documentations are just

limited to your internal team sometimes

things are limited to multiple

stakeholders as well as the documents

are so different and distinct from from

each other how can one review type Bill

be used or enough to test or review any

type of documentation certainly We

cannot put a very heavyweight process

like the one we covered in our previous

tutorial that is formal review process

to review any type of documentation for

example if I have to compare a project

plan versus test case these two are

totally different from each other when I

talk about the project plan it consists

of a lot of detailed information about

the whole project schedule the plan of

action the different activities and the

people the resources and whatnot the

budget time frame and everything but

when it comes to test case which is also

another work product but it's just

limited to testing team or to certain

extent to developers sful so only two

people would be just enough to talk

about this particular documentation and

the other stakeholders may not be just

worried about what is the test case all

about however I might be worried about

test plan being a project manager

development manager design manager and

so on so every single do document is

different from each other and certainly

one heavyweight process of review cannot

be applied at every single place so in

that context this particular topic will

help you learn and understand about what

are the different types of review

process and how exactly we can make use

of it so let's quickly get into the

screen and try understanding that what

exactly are these view types and how

they are different from each other the

number one point here is to talk about

the introduction so there may exist many

review types ranging from informal

reviews to formal reviews the required

levels of formality depends on factors

such as sdlc being followed the maurity

of the development process the

criticality and complexity of the work

product uh being reviewed legal or

regulatory requirements and the need for

an AIT trade now the most important

thing here to talk about is that it's

just not one factor which I just told

you indeed there are many other factors

if you're talking about agile I may not

have a lot of time to conduct formal

review process because it's a very light

process altogether and certainly I

cannot invest a lot of time going

through documentation review makes sense

right but if I talk about waterfall

model I have literally a lot of time and

I can certainly utilize this time to do

a formal review at every single document

same way if I talk about the criticality

I talk about the regulatory requirements

contractual requirements and whatnot now

Regulatory and standards certainly do

drive if my ISO demands me to conduct

the static testing for such particular

documentations then even if I don't want

to do that I have to do it because it

would be one of the flaws or findings

when it comes to the audit or review of

iso so in that context it is very

critical and important for me to

understand how this works well right so

all the factors should be taken into

account by any team any organization in

order to select what type of review

should be followed further to add here

we talk about the same work product can

be reviewed with different review types

initially you can start with informal

but later you can have more formal

review as type as well also selecting

the right review type is the key to

achieving the required review objective

that means you just can't apply a random

type whenever you want but you should be

very much selective in terms of what you

would need to do for which type of

document also the selection is not only

based on the objective but also on

factors such as project needs available

sources work product types and risk

business domain and Company culture and

putting up all together with our

previous point also we have many such

factors which should be taken into

account to Define about the appropriate

review type so let's have a look on the

different review types which we have and

how they're different from each other

however these are very very high level

I'll try to give you something unique

about each type of review and trust me

that unique Point could help you a lot

in getting the right answer during the

examination

because when they ask you match the

following then the unique points help

you a lot or sometimes they give you a

five pointer question and ask you hey

what review are we talking about then

that particular unique point would be

very very helpful so let's quickly have

a look on what types of review we are

talking about and the review types here

we include we have major four types of

review of course there are no minor

minor could be very very casual or

informal ones but mainly there are four

types of review the four types of review

include informal walk through technical

review and inspection starting from the

least formal to the highest formal

review that is inspection just for your

kind information just make a note of it

the formal review process which you

covered in the previous tutorial is

exactly as that of inspection that means

inspection is fully formal review so if

you know what is formal review process

you know what is inspection or if you

know what is inspection you know what is

formal review process so you don't have

to learn it separately as two different

topics if you know what is formal review

process you know what is inspection

let's start with informal review the

very first review here we have is

informal informal review do not follow a

defined process and do not require a

formal documented output the main

objective is detecting anomalies now

taking a quick example here of course

the word is very self-explanatory sorry

the statement is very self-explanatory

but uh giving you a quick example assume

that I'm a tester one writing test cases

right and I want someone to review it

because I am a human a human is that are

prone I can do mistakes so before we put

it in the repository or go for

executions we ask one of our colleague

to review that now this involves just

two people T1 and T2 tester one and

tester 2 to get involved in this review

if tester 2 has anything in findings he

will let the tester one know that hey

just fix this thing and that's all good

to go and that's it so it does not

involve more than two people it could be

just between T1 and T2 or it could be

between tester one and test lead who

will be reviewing the work product to

some extent we also call it as buddy

checks okay buddy checks so informal

review is very very useful in agile

methodology because uh we have to do it

as a part of preventing defects but we

can't be very very formal so in that

context these are very lightweight no

formal documentation no formal process

and it's just conducted between two

people so the unique point is no formal

process and just two people involved

which you call it as budy check also

let's move on to the next one the next

one here is called as walkth through a

walkth through which is led by the

author can serve many objectives such as

evaluating quality and building

confidence in the work product educating

reviewers gaining consensus generating

new ideas motivating and enabling

authors to improve and detect anomalies

reviewers might perform an individual

rot before the walkth through but this

is not required now here if you'll just

differentiate between each of these

points you would get many key key points

here number one the walkth through is a

type of review which is led by the

author itself but if you know the formal

review process there is a trained

moderator or facilitator who's

responsible to leave the review okay

informal review but when it comes to

work through it's an author that means

the person who has written the document

itself is leading the review so there's

no moderator there's no facilitator

there's no review leader it's just the

author who is taking control over the

entire review process the second

important Point what we found here is

that indiv ual review before the meeting

is not mandatory it's optional so if you

want people to you know go through the

preparation before you want to have a

meeting with them you can always do that

but it is not completely mandatory

additionally if I look here we also talk

about the objectives which are very key

important things that is the why do we

do it so you can do it for gaining

consensus like audience poll like hey

what should we do about this or

generating new ideas you want to do

something as a workaround you can look

forward to that and enabling authors to

improve that means over a period of time

you may look forward to improve the way

the documentations are being written and

that would be of great help right so

unique Point here is it is led by author

okay that's completely unique here it is

not anywhere else that means not in any

other type of review the third important

thing is technical review and the

technical review is performed by

technically qualified reviewers and led

by moderator now here you can very well

notice that moderator is coming into

picture sure to lead the review and

performed by technical experts that is

subject matter Experts of the technical

domains will be the reviewers not just

like anyone blindly being invited so the

unique points are right on your you know

first thought right now the very first

line that is the technical experts will

be the reviewer and second you will have

the moderator but it's not moderator is

not unique the reason is it is also

mandatory in inspection so keep in mind

technical review is conducted by

technical experts which doesn't happen

anywhere else also to add here the

objective of technical review are to

gain consensus and make decisions

regarding a technical problem but also

to detect anomalies evaluate quality

build confidence in the work product

generate new ideas and to motivate the

enable authors to improve that means

these objectives do remain common

throughout but however there are

something very important for us to take

into account last but not the least when

we come to inspection inspection is the

fully formal review process as

inspection as the most formal type of

review they follow the complete generic

process what we discussed in earlier

topic the main objective is to find

maximum number of anomalies other

objectives are to evaluate quality build

confidence in the work product and to

motivate and enable others to improve

which is pretty common among all other

types of review matrices are collected

and used to improve the sdlc including

the inspection process in inspection the

author cannot act as a review leader or

scribe that means there will be standard

dedicated roles and roles and

responsibility the whole process will be

followed as per the formal review

process like entry criteria exit

criteria making use of matrices to

gather the effectiveness and success

rate of the review process and there

will be standard roles like manager

moderator author will be only

responsible to uh collect the collate

the anomalies and fix them but not

responsible to play the role of

moderator or something so if you

differentiate between so now inspection

has unique points as entry exit rules

and checklist roles and responsibility

all these becomes unique point of

inspection because these are not

mandatory in the other three types of

review so given that we have understood

what are the four different types of

review how these are applicable right

and how they get applied in the reality

that would be of great help for you to

answer a quick question right from here

right 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 understand the

context thanks for watching the video

team and happy

[Music]

learning