ISTQB FOUNDATION 4.0 | Tutorial 8 | 1.5 Essentials Skills and Practices in Testing (Part-2) | CTFL

TM SQUARE
5 Dec 202314:57

Summary

TLDRThis tutorial delves into the ISTQB Foundation level certification, focusing on the whole team approach and independence of testing. It highlights the importance of collaboration in agile methodologies, emphasizing that quality is a collective responsibility. The video discusses the benefits of cross-functional teams and the potential drawbacks of losing tester independence, such as reduced defect detection. It also explores varying degrees of testing independence, from self-testing by developers to fully outsourced testing, and the impact on defect identification and team dynamics.

Takeaways

  • 😀 The whole team approach emphasizes collaboration and communication among team members to reduce gaps and improve understanding and coordination.
  • 👥 Originating from extreme programming, the whole team approach involves everyone, including architects, developers, and testers, working closely together for better communication and collaboration.
  • 🛠 In a whole team approach, any team member with the necessary knowledge and skills can perform any task, and everyone shares responsibility for product quality.
  • 📍 Team members in this approach share the same workspace, whether physical or virtual, to facilitate better communication and interaction.
  • 🔍 Testers work closely with other team members, including business representatives and developers, to ensure quality levels are met and to create suitable acceptance tests and test strategies.
  • 🧐 The close collaboration in the whole team approach can sometimes lead to a loss of independence, where testers might start thinking from a development perspective and potentially miss defects.
  • 🏛 The degree of independence in testing can vary from the author testing their own work to having highly independent testers from outside the organization.
  • 🔎 Higher degrees of independence in testing can lead to more effective defect detection due to different cognitive biases and perspectives between authors and testers.
  • 🔄 For most projects, a blend of multiple levels of independence in testing is beneficial, such as developers doing unit testing and a separate QA team handling system testing.
  • 🚧 The drawbacks of high independence include potential isolation of testers from the development team and a possible loss of responsibility for quality by developers.
  • 🛑 Independent testers may be seen as a bottleneck or blamed for delays in release, highlighting the importance of prompt testing and avoiding delays.

Q & A

  • What is the main topic of the tutorial?

    -The main topic of the tutorial is the ISTQB Foundation Level certification, focusing on the fundamentals of testing, specifically the whole team approach and the degree of independence of testing.

  • What does the 'whole team approach' refer to in the context of agile methodologies?

    -The 'whole team approach' refers to the practice where all team members, including architects, developers, and testers, work together closely to improve communication, collaboration, and reduce communication gaps among stakeholders.

  • What are some characteristics of the whole team approach mentioned in the script?

    -Some characteristics include the ability to work effectively in a team context, contributing positively to team goals, shared workspaces, and the responsibility of quality being distributed among all team members, not just the testing team.

  • How does the whole team approach enhance team dynamics and project outcomes?

    -The whole team approach enhances team dynamics by improving communication and collaboration, creating synergy by leveraging various skill sets within the team for the benefit of the project, and ensuring that desired quality levels are achieved through close collaboration with other team members.

  • What is the potential drawback of having a very close collaboration between developers and testers?

    -The potential drawback is the loss of independence, which may result in testers starting to think from a development perspective and losing their ability to find defects effectively, as they might begin to adopt the developer's mindset.

  • What does 'independence of testing' mean and why is it important?

    -'Independence of testing' refers to the degree to which testing is conducted separately from the development process. It is important because it allows testers to have a different perspective, which can lead to the discovery of defects that developers might overlook due to cognitive biases.

  • What are the four degrees of independence in testing as described in the script?

    -The four degrees of independence are: 1) Work products tested by their author, 2) Tested by the author's peer from the same team, 3) Tested by testers from outside the author's team but within the same organization, and 4) Highly independent, where testers are from outside the organization, often in an outsourced scenario.

  • Why is it beneficial to have multiple levels of independence in testing for most projects?

    -Having multiple levels of independence in testing allows for a blend of perspectives and skill sets, which can lead to a more comprehensive testing process. It ensures that different types of defects are caught at various stages by different individuals or teams with varying levels of separation from the development process.

  • What are some benefits of having independent testers?

    -Benefits include the ability to recognize different kinds of failures and detect defects more efficiently due to different technical perspectives and biases, as well as the capacity to verify or challenge assumptions made during the specification and implementation of the system.

  • What are some drawbacks of having high levels of independence in testing?

    -Drawbacks include the potential for independent testers to be isolated from the development team, leading to a lack of collaboration and understanding of the system. Additionally, developers may lose a sense of responsibility for quality, and independent testers may be seen as bottlenecks or blamed for delays in release.

  • How can the drawbacks of independent testing be mitigated?

    -The drawbacks can be mitigated by ensuring prompt communication and collaboration from the beginning of the project, involving developers in testing through activities like unit testing, and by anticipating and addressing potential delays proactively.

Outlines

00:00

😄 Whole Team Approach in Agile Testing

This paragraph discusses the concept of the whole team approach in agile testing, emphasizing the importance of collaboration among team members, including developers, testers, and other stakeholders. It highlights the origin of this approach from extreme programming and its benefits, such as improved communication, reduced gaps, and better understanding among team members. The paragraph also outlines the characteristics of the whole team approach, including the ability to work effectively in a team, shared responsibility for quality, and the flexibility for any team member to perform tasks based on their skills. The importance of maintaining a balance between close collaboration and independence to avoid potential drawbacks, such as testers losing their critical mindset, is also mentioned.

05:02

🔍 Degrees of Testing Independence

The second paragraph delves into the topic of testing independence, explaining the varying degrees of separation between testers and developers within an organization. It outlines four levels of independence, ranging from the author testing their own work to highly independent testing by external organizations. The benefits of independence include a higher likelihood of defect detection due to different perspectives and the ability to challenge assumptions made during system development. However, the paragraph also acknowledges the potential drawbacks, such as the risk of testers becoming isolated or seen as bottlenecks, and the possible loss of developers' sense of responsibility for quality. The importance of finding the right balance of independence for a project is emphasized, suggesting that a mix of different independence levels can be beneficial.

10:04

📚 Benefits and Drawbacks of Testing Independence

The final paragraph summarizes the benefits and drawbacks of independent testing. Benefits include the ability of independent testers to recognize different kinds of failures and detect defects more efficiently due to their distinct technical perspectives. They can also verify and challenge assumptions made during the specification and implementation phases, ensuring a more accurate final product. On the downside, independent testers might be isolated from the development team, leading to a lack of collaboration and understanding of the system's details. Additionally, developers may lose their sense of responsibility for quality if testing is outsourced. The paragraph concludes by discussing the potential for independent testers to be blamed for delays in release and suggests proactive measures to prevent such issues, such as early anticipation of potential delays.

Mindmap

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 context for discussing testing fundamentals, emphasizing the importance of having a solid base of knowledge in the field.

💡Whole Team Approach

The whole team approach is a collaborative methodology where all team members, including developers, architects, and testers, work closely together towards a common goal. It is highlighted in the script as a practice from extreme programming that enhances communication and reduces gaps in understanding. The video discusses its importance in the agile era, where teams are expected to be synchronized and work closely with stakeholders.

💡Agile

Agile is a project management and product development approach that emphasizes flexibility, collaboration, and customer satisfaction through iterative development. The script mentions agile as the current era's methodology, where the whole team approach is especially relevant, and teams are expected to work closely to reduce communication gaps and improve collaboration.

💡Extreme Programming

Extreme Programming (XP) is one of the agile methodologies that focuses on improving software quality and responsiveness to changing customer requirements. It introduced the whole team approach, as mentioned in the script, where everyone involved in the project works together, contributing to better communication and collaboration.

💡Team Dynamics

Team Dynamics refers to the way team members interact and work together within a group. The script discusses how the whole team approach improves team dynamics by allowing different skill sets to be leveraged for the project's benefit, thus creating synergy and enhancing communication and collaboration.

💡Quality

In the context of the video, quality is defined as a collective responsibility of the entire team, not just the testing team. It is emphasized that everyone should contribute to defining and ensuring the quality of the product, which is a key aspect of the whole team approach and a shift from the traditional siloed responsibilities.

💡Collaboration

Collaboration is the process of two or more people working together to achieve a common goal. The script frequently mentions collaboration as a key benefit of the whole team approach, where team members work closely with business representatives and developers to create suitable acceptance tests and agree on test strategies.

💡Independence of Testing

The independence of testing refers to the degree to which testing is conducted separate from the development process. The script explores different degrees of independence, from testing by the author of the work product to highly independent testing by external organizations, and discusses the benefits and drawbacks of each level.

💡Cognitive Biases

Cognitive biases are systematic errors in thinking that affect the judgments and decisions people make. In the script, cognitive biases are mentioned in the context of why a certain degree of independence in testing is beneficial, as testers with different mindsets and backgrounds are more likely to find defects that the original authors might have missed.

💡Test Automation

Test automation is the use of software to execute tests that would otherwise be performed manually. The script touches on test automation approaches as part of the collaboration between testers and developers, where they agree on how to automate testing processes to improve efficiency and effectiveness.

💡Defect Leakage

Defect leakage occurs when defects are not detected during the testing phase and make it into production. The script warns about the potential drawback of the whole team approach where testers working too closely with developers might lose their critical perspective, leading to a higher risk of defect leakage.

Highlights

Introduction to the tutorial on ISTQB Foundation level certification, focusing on the fundamentals of testing and essential skills and good practices.

Exploration of the Whole Team Approach in agile methodologies, emphasizing the importance of synchronization and close collaboration among team members and stakeholders.

Characteristics of the Whole Team Approach, highlighting the tester's role in collaborating and coordinating with stakeholders for effective communication and reduced communication gaps.

Origins of the Whole Team Approach from Extreme Programming, which introduced the concept of everyone working together for better communication and collaboration.

Responsibility for quality in the Whole Team Approach, where every team member is responsible for defining and ensuring product quality.

Team Dynamics in the Whole Team Approach, allowing for cross-functional team members to leverage their diverse skills for project benefits.

Close collaboration between testers and other team members to ensure desired quality levels, including working with business representatives and developers.

The potential drawback of the Whole Team Approach, where testers may lose their objectivity and ability to find defects due to close collaboration with developers.

Introduction to the concept of Independence of Testing, discussing different degrees of independence that can be experienced in various organizations.

The four identified degrees of Independence in testing, ranging from the author testing their own work to highly independent testing by external organizations.

Benefits of high Independence in testing, such as the increased effectiveness in finding defects due to different cognitive biases and mindsets.

Drawbacks of high Independence, including potential isolation of testers from the development team and a possible loss of responsibility for quality by developers.

The recommendation for most projects to carry out testing with multiple levels of Independence, blending different degrees for comprehensive testing coverage.

Strategies to overcome the drawbacks of high Independence, such as maintaining prompt communication and anticipating potential delays.

The importance of balancing close collaboration with maintaining the tester's objectivity and ability to find defects in the context of the Whole Team Approach.

Conclusion of the tutorial, emphasizing the importance of understanding the context and adapting testing practices to achieve quality in software development.

Transcripts

play00:00

Hello friends and greetings for day

play00:02

welcome back to another tutorial on

play00:03

istqb Foundation level certification we

play00:06

are in chapter one talking about the

play00:08

fundamentals of testing and we are

play00:10

continuing with our last segment that is

play00:12

essential skills and good practices 1.5

play00:16

of this chapter and this is the part two

play00:18

of this particular segment uh we will be

play00:21

covering the next two part that is whole

play00:22

team approach and the degree of

play00:25

independence of

play00:28

testing

play00:32

[Music]

play00:36

so when it comes to whole team approach

play00:38

of course it's the very common

play00:40

understanding that today the era is all

play00:42

about agile and today we are not working

play00:45

separate from each other are very very

play00:47

differently located or separated in the

play00:50

sense like one team is sitting in one

play00:52

particular location and one team is

play00:54

sitting in another location that is no

play00:56

distributed teams we are looking forward

play00:58

to indeed no matter what kind of of

play01:00

methodology you are following you are

play01:01

looking forward to have as much as go

play01:04

location as possible so that the team is

play01:07

synchronized and working very closely

play01:09

with other stakeholders in order to

play01:11

reduce the communication gaps at the

play01:13

same time have a better understanding

play01:15

and collaboration among the stakeholders

play01:18

and that's where the whole team approach

play01:20

comes into consideration as we talk

play01:22

about whole team approach there are

play01:23

several characteristics which one that

play01:26

is a tester should take into

play01:27

consideration to collaborate and

play01:30

coordinate with different stakeholders

play01:32

in order to understand that how exactly

play01:34

they should interact with them

play01:36

communicate with them and what kind of

play01:38

dependencies and support will they

play01:40

really have among the other stakeholders

play01:43

so in order to understand more about

play01:44

this here is our some of the information

play01:46

from the syllabus which talks about what

play01:49

are we considering as whole team

play01:50

approach so when we talk about the whole

play01:53

team approach one of the important

play01:55

skills for a tester is the ability to

play01:57

work effectively in a team cont context

play02:00

and to contribute positively to the team

play02:02

goals the whole team approach a practice

play02:05

coming from extreme programming builds

play02:08

upon the skills which clearly talks

play02:10

about something very important that what

play02:13

is the you know origin of this

play02:14

particular approach that is whole team

play02:16

approach of course one of the approaches

play02:18

of agile is also called as extreme

play02:21

programming compared to that of scrum

play02:23

and Canin we do have another approach

play02:25

called as extreme programming and this

play02:27

extreme programming initially introduced

play02:28

the whole team approach that means

play02:31

everyone be it architect developer and

play02:33

tester they should all work together and

play02:36

that helps us to have a better

play02:37

communication and indeed good

play02:39

collaboration among the team members a

play02:41

lot of clarifications a lot of doubts

play02:43

are sorted when the team are working

play02:45

together also to add further we are

play02:47

talking about in the whole team approach

play02:49

any team member with the necessary

play02:51

Knowledge and Skills can perform any

play02:53

task and everyone is responsible for

play02:55

Quality now that's another important

play02:57

thing which comes together with the

play02:59

whole team approach that quality is not

play03:01

just testing team responsibility it is

play03:04

everyone's responsibility to uh Define

play03:07

quality in the product because it's not

play03:08

just one person working separately like

play03:10

a testing team and defining and taking

play03:13

the ownership on that today every single

play03:16

stakeholder in the entire team is

play03:18

responsible for defining quality in the

play03:19

product and at the same time these

play03:22

members are so defined or so hired put

play03:25

together in terms of Team Dynamics that

play03:28

means the team member can do any task

play03:30

which is relevant to them right as far

play03:32

as they have the skills as they

play03:33

mentioned there anyone can do that

play03:35

particular task the very next Point what

play03:37

we have here is of course the team

play03:39

members share the same workspace

play03:41

physical or virtual as collocation

play03:44

facilitates communication and

play03:45

interaction and that's what we were just

play03:46

talking about a moment ago the whole

play03:49

team approach improves Team Dynamics

play03:51

enhances Communications and

play03:53

collaboration within the team and

play03:55

creates Synergy by allowing the various

play03:58

skill sets within the team to be

play04:00

leveraged for the benefits of the

play04:01

project now as I mentioned it's not like

play04:04

we just have all the members with

play04:06

similar set of skills we do look forward

play04:07

to have cross functional team members

play04:09

put together and as they have different

play04:12

skill set they can very well be

play04:13

leveraged for their skills to perform a

play04:16

certain activity within the project

play04:18

right so that certainly helps and

play04:20

minimizes our effort of depending

play04:21

outside the team and rather making use

play04:24

of internal skills itself also to add we

play04:27

are talking about the next one that is

play04:29

testers work very closely with other

play04:31

team members to ensure that the desired

play04:33

quality levels are achieved so here we

play04:35

don't have differences or gap between

play04:38

the two members thus it becomes very

play04:40

simple and easy to collaborate and

play04:42

understand or gain understanding about

play04:44

the aspects which certainly brings back

play04:46

a lot of value also to add that this

play04:49

includes collaborating with business

play04:50

Representatives also to help them create

play04:53

suitable acceptance test and working

play04:55

with developers to agree on the test

play04:57

strategy and decide on the test test

play04:59

automation approaches so it's just that

play05:02

like when we are working very very close

play05:04

to developers it's just not limited to

play05:06

that but also we work very closely with

play05:08

the business stakeholders to help them

play05:11

understand what are test cases one way

play05:13

we do become agile just like aile coach

play05:16

we do become a testing coach or quality

play05:18

coaches to our team members and educate

play05:20

them about what exactly the test cases

play05:23

will be and how exactly the testing will

play05:25

be conducted and what is that we would

play05:27

be expecting in terms of uh validating

play05:30

the functionality of featur so in that

play05:32

context we do educate other stakeholders

play05:34

about testing and quality and how to

play05:36

define quality in the product thus put

play05:39

together as a whole team goal we can

play05:42

certainly achieve a great quality right

play05:44

here also at the same time testers can

play05:46

thus transfer testing knowledge to all

play05:49

the other team members and influence the

play05:51

development of the product depending on

play05:54

the context the whole team approach may

play05:56

not always be appropriate for instance

play05:59

in some situations such as safety

play06:01

critical a huge level of test

play06:03

Independence may be needed now here we

play06:05

are just trying to give you a quick

play06:06

example on it's not necessary that whole

play06:08

theme approach is always helpful

play06:12

sometime we do have a drawback of having

play06:15

a very close collaboration between

play06:17

developer and Tester the only drawback

play06:19

what we see here is that the degree of

play06:20

Independence between the two teams is

play06:23

lost sometime a tester starts thinking

play06:25

from a development perspective and may

play06:27

lose their psychology or the mindset

play06:30

what they need in order to find effects

play06:32

so working closely with developers but

play06:34

maintaining that asset of your

play06:36

psychology is equally important and when

play06:39

it comes to different critical products

play06:41

it's very very important that you should

play06:44

maintain that difference because here

play06:47

working closely may result into defect

play06:50

leakage okay so working closely is very

play06:52

common to understand that however we

play06:54

collaborate and blend to solve our

play06:56

problems together but sometime we work

play06:59

so so closely with the developers that

play07:01

we we may lose our sense and capability

play07:03

of finding defects as we start probably

play07:05

treating ourself into the developer

play07:08

shoes and start feeling their you know

play07:10

the process and the way they work and

play07:12

that could be a big drawback for us well

play07:15

the next topic we are talking about is

play07:17

called as independent independence of

play07:19

testing and Independence of testing is

play07:21

mainly to talk about what are the

play07:23

different degree of Independence which

play07:25

can be experienced in different

play07:27

organization now degree of of

play07:29

Independence is to just let you know

play07:31

that it's not necessary that testing

play07:33

always happens independently from the

play07:36

development team that means sometime it

play07:38

can be done by developers sometime it

play07:40

can be done by different developers but

play07:43

within the development team or sometime

play07:45

it can be done by a separate testing

play07:46

team what we practice today or sometime

play07:49

it can just be outsourced also but

play07:51

depending on organization factors the

play07:54

organization size and maturity levels

play07:56

you can determine the different degree

play07:58

of Independence so let's have a look

play08:00

what the content is trying to share with

play08:02

us at this point of time so we have of

play08:04

course independence of testing as the

play08:06

next topic we're talking about a certain

play08:08

degree of Independence makes the tester

play08:10

more effective at finding defects due to

play08:13

difference between the authors and the

play08:15

testers cognitive biases because of

play08:18

their different mindsets different

play08:20

abilities and different portfolios you

play08:23

certainly tend to find different defs

play08:24

than that of the developer right here we

play08:27

have identified four different of

play08:29

Independence number one work products

play08:32

can be tested by their author that means

play08:34

no independent tester a developer is the

play08:36

only person who has written the code and

play08:39

the same person is actually trying to

play08:40

test the code the second degree of

play08:42

Independence is by the author's peer

play08:44

from the same team which means there is

play08:46

a slight difference Independence between

play08:49

the person who created it and testing it

play08:52

but they both may be from the same team

play08:54

that is development for an example if

play08:56

I'm writing a code AS developer one I I

play08:59

would give it to developer two for unit

play09:01

testing having a little Independence

play09:03

there when we talk about the degree

play09:05

number three the degree number three

play09:06

talks about a test by testers from

play09:09

outside the author's team but within the

play09:11

same organization which simply means one

play09:13

thing that what we are practicing today

play09:16

development team is only responsible for

play09:18

development and the testing like

play09:20

integration and system testing is being

play09:22

conducted by separate team called as QA

play09:25

team and the fourth one is highly

play09:27

independent which means that

play09:30

the testers from outside the

play09:32

organization and here we can take the

play09:34

example of those startup or small based

play09:36

small scale organizations where testing

play09:39

is completely outsourced to another

play09:41

third party organization because they

play09:42

may not be able to afford testers within

play09:45

their organization so put together we

play09:47

have identified four different degree of

play09:48

Independence and that certainly gives us

play09:52

understanding that the more it is

play09:53

independent the better it is to find

play09:55

defects but is that like is there

play09:57

anything very best here or what is that

play09:59

an organization should actually follow

play10:02

so of course they have differences here

play10:04

that we do have benefits of high

play10:06

Independence at the same time the

play10:07

drawbacks of high dependence so let's

play10:10

quickly check it out that what are these

play10:11

benefits and drawbacks and understand

play10:13

more about it also to add before we move

play10:15

on there that is for most projects it is

play10:18

usually best to carry out testing with

play10:20

multiple levels of Independence that

play10:22

means having a blend of multiple

play10:25

Independence degree within an

play10:26

organization within a project would be

play10:28

helpful for an example developers

play10:30

performing component and component

play10:32

integration testing test team performing

play10:35

system and system integration testing

play10:37

and business representating or business

play10:40

Representatives performing acceptance

play10:43

testing so in that context it will have

play10:44

a blend off everything put together that

play10:47

is all four degrees at the same time so

play10:50

let's talk about the benefits and

play10:51

drawbacks of having independent testing

play10:53

because not every good thing comes

play10:55

without a problem or without a drawback

play10:57

so let's exactly see how these things

play10:59

can really be helpful and at what points

play11:01

these can become a challenge for us and

play11:04

how we can overcome those drawbacks so

play11:07

the benefits are limited of course and

play11:08

includes independent testers are likely

play11:10

to recognize different kind of failures

play11:13

and detect uh defects compared to

play11:15

developer because of their different

play11:17

background technical perspective and the

play11:19

biases of course a tester is someone

play11:21

different than the person who has

play11:22

written the code would certainly be

play11:24

capable of finding different defects

play11:26

than that of developers and will be more

play11:29

efficient in looking into the user

play11:31

perceptions on the second we do have

play11:34

another independent testers benefit that

play11:36

is they can verify challenge or

play11:39

disapprove assumptions made by

play11:41

stakeholders during the specification

play11:43

and implementation of the system

play11:45

assumptions are those where the

play11:46

requirements are unclear and sometime

play11:49

the business analyst also takes as a mi

play11:52

assumption if in case they are not

play11:54

having complete information the

play11:56

technical team like design and

play11:58

development team will make certain

play12:00

assumptions to go with how to implement

play12:02

this requirement but again as far as you

play12:05

make an assumption you think this is the

play12:07

best for it but of course it may not be

play12:09

as far as you share your perception with

play12:11

someone else you may understand that

play12:13

your assumption was not up to the mark

play12:15

but not only that like not only to

play12:17

challenge or disapprove but even to

play12:19

verify or validate I need someone else

play12:22

that whether this assumptions are what

play12:24

expected here right the drawbacks on the

play12:27

other hand includes that independent

play12:30

testers may be isolated from the

play12:31

development team again considering the

play12:33

highest independent team so can be

play12:35

treated as a service provider vendor

play12:38

rather than a technical team as a part

play12:40

of the process so when you Outsource

play12:42

certain services or certain activities

play12:44

to third party organization you may not

play12:46

treat them as a part of the process and

play12:48

because of that they may have lack of

play12:50

collaboration lack of understanding of

play12:53

the component and details because of

play12:55

security policies between the

play12:56

organizations and many other things also

play12:59

to talk about developers may lose the

play13:01

sense of responsibility for Quality now

play13:03

it's very clear and understandable that

play13:05

a developer is not at all responsible

play13:08

for testing and being outsourced then

play13:11

everything will be done by other

play13:12

organization and here developers may not

play13:15

have any kind of understanding that how

play13:16

exactly quality can be defined into the

play13:19

organization into the project so in that

play13:22

context we do give one level to them

play13:24

that is unit testing and that's why this

play13:27

unit testing is given to Developers that

play13:29

is to eliminate this drawback of

play13:32

independent testing and the third what

play13:34

we have here with us is independent

play13:36

testers may be seen as bottleneck or

play13:38

blamed for delays in release because

play13:40

it's very common to understand the one

play13:42

who is last in the queue will always

play13:45

have less time with them and said that

play13:48

certainly can become a crunch and would

play13:51

be blamed for all the delays so however

play13:54

this drawback cannot be eliminated all I

play13:56

would say but being prompt right right

play13:58

from the beginning because somewhere

play14:00

someone is eating the time right

play14:02

somewhere someone is occupying the time

play14:04

that you don't get what time you need so

play14:06

testing always claims one thing that we

play14:09

did not get the stories on time we did

play14:11

not get the development code at the time

play14:13

when we are supposed to start testing

play14:16

and uh that's where most of the time we

play14:19

get delays so instead of reflecting that

play14:22

when we have the delays with us rather

play14:24

in advance if you can start anticipating

play14:26

the delays you can always PR prevent

play14:29

this drawback okay so put together

play14:31

that's all what we had from this

play14:33

particular tutorial team uh should you

play14:35

have anything else feel free to comment

play14:36

below I'm always there to address your

play14:38

queries and answer them well till then

play14:40

keep learning keep exploring keep

play14:42

understanding the context thanks for

play14:43

watching the video team and happy

play14:49

[Music]

play14:55

Lear

Rate This

5.0 / 5 (0 votes)

相关标签
ISTQBTestingAgileTeamworkCollaborationQuality AssuranceSoftware TestingCertificationExtreme ProgrammingIndependent Testing
您是否需要英文摘要?