YT YouTube2Text

YouTube2Text → Transcripts → Manual Software Testing Training Part-5

Manual Software Testing Training Part-5 — Transcript

by SDET- QA · 12,959 words · 2,318 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:01All right.
0:02So in the today's session, uh we are
0:04going to see some of the important
0:06terminologies in software testing.
0:08So so far we have seen like sort what is
0:10a functional testing types and what are
0:12the non-functional testing types in the
0:14previous session, right?
0:16So in the today's session, we have to
0:18learn some of the important
0:19terminologies. So in the IT industry,
0:22especially in the software testing on
0:23day-to-day basis, uh
0:25we frequently use these terms. So we
0:27have to know what is the exact meaning
0:29of those terms.
0:31Like regression testing, retesting, or
0:33smoke and sanity testing, exploratory
0:35testing, or ad-hoc testing, monkey
0:38testing, positive and negative testing,
0:41end-to-end testing. So these are the
0:42different terms most of the times we use
0:45on day-to-day basis in the software
0:47industry, okay?
0:48So we have to know exactly what is the
0:50meaning of these terms.
0:52Now let us discuss what exactly they
0:54are.
0:55So first one is regression testing. So
0:57let me write the notes.
0:59Software testing terminology. So the
1:01first type of testing is regression
1:04testing. So let's try to understand this
1:06very clearly by which is very very
1:07important and especially for interview
1:09also.
1:11So please listen this carefully.
1:13So first is regression testing. So what
1:15exactly regression testing means?
1:18So let me just give you a small example
1:20for
1:21regression testing.
1:22Sometimes uh your application is having
1:25multiple modules, right? So application
1:27is having multiple modules.
1:29So what developer will do? For example,
1:31let us say I have few modules. Let's say
1:33one, two, three, four. So I have four
1:38different modules in your application.
1:40So what developer will do is suppose you
1:42found some a bug in your some module. So
1:45let's say I have found some bug in this
1:47or I have found some defect in the
1:48particular module.
1:50So what I will do as a tester? I'll
1:52report that defect to the developer.
1:54Okay, I report that defect to the
1:56developer.
1:57So what developer will do is developer
2:00will modify that. In this particular
2:02module, developer will fix that bug.
2:05And then they release a new new build.
2:09So for example,
2:10let us say I have first build. Build is
2:12nothing but a software, okay? Small
2:14piece of software.
2:15Let us say build one.
2:17In the build one, I reported one bug to
2:19the developer.
2:21I found one bug in the build one.
2:23And I reported that bug to the
2:25developer.
2:26So what developer will do is developer
2:28fix that bug.
2:30And again release another build called
2:32build number two. Let us say build two.
2:34This is the second build.
2:36So as a tester, what I have to do in the
2:39second build?
2:40So let's say build contains a multiple
2:42modules, okay? Let's say build two
2:44contains or build one contains a four
2:46different modules. In some module, I
2:48found some bug and reported to the
2:49developer.
2:51Developer fix that bug bug in that
2:52particular module and then release a
2:54another build.
2:56So in the build number two, as a tester,
2:58what I will do is I will verify that bug
3:01whether it is fixed or not, it is
3:03working fine or not.
3:05And uh sometimes what happens is because
3:07of that change or sometimes my developer
3:10fix the bug. Apart from the bug, they
3:12may add some new functionality also in
3:14the build number two. Or they may delete
3:16the existing functionality or they
3:18modify the existing functionality. So
3:20whenever the dev is doing some changes
3:22in the build,
3:24because of that change, there should not
3:26be impact on other modules. So for
3:28example, in the module number one, he
3:30did some change.
3:32And that should not impact on other
3:34modules. Because there will be some
3:36connection between modules in the
3:37application, right? There will be some
3:39integration takes place.
3:41So whenever the dev is done some change
3:43on particular build or particular
3:45module,
3:46there should not be any impact on other
3:49modules.
3:50So that we have to test, which is called
3:52as regression testing.
3:54So during the regression testing, tester
3:56will verify the
3:59bug fixes or a new functionality or
4:01modification.
4:03Because of those changes, there should
4:05not be impact on other modules. And
4:07along with that bug fixes and uh new
4:09functionalities, testers will also test
4:11the other dependent modules.
4:14Okay? Other dependent modules. So that
4:17is called as a regression testing. Let
4:19me just share a small presentation.
4:23Okay? So now you can Here you can look
4:25at here. So testing conducts on modified
4:28build
4:30to make sure there will not be impact on
4:32existing functionality because of
4:35changes like adding, deleting, modifying
4:38the features. So this is a commonly
4:40happen uh while testing that
4:42applications, okay? Whenever you report
4:44a defect to the developer, developer
4:46will fix it.
4:47And because of that fix, he may add some
4:50new functionality or he may delete the
4:51existing functionality or he may modify
4:53the some features. And those should not
4:56affect in the existing functionality. So
4:58that you have to make sure. And you have
5:00to test that changed functionality along
5:03with this impacted functionality. So
5:05what on other modules will be impacted
5:07because of that change, you have to make
5:09sure. So existing functionality should
5:11not be broken because of new changes or
5:14bug fixes. So that is basically called
5:16as regression testing. Very very
5:19important. Okay, definitely people will
5:21ask this question in interview. So what
5:23is regression testing? Regression
5:24testing conduct conducts on modified
5:27builds
5:28whether the bug fixes or new changes are
5:31working fine or not. And there should
5:33not be any impact on
5:36other builds or other functionality.
5:38Okay? And regression testing can be done
5:41in three different ways. So there are
5:42three types of regression testings we
5:44have.
5:45Unit regression testing,
5:47regional regression testing, full
5:49regression testing. Unit regression
5:51testing, regional regression testing,
5:53full regression testing.
5:55Let us understand what exactly is unit
5:57regression testing means.
5:59Testing only the changes or
6:01modifications done by the developer.
6:04So in the unit regression testing, what
6:07you will do is suppose we have four
6:10different modules
6:12and we reported one bug on that
6:14particular module to the developer.
6:16And developer fix that bug in that
6:18particular module and we will test only
6:21that module. We'll test only that
6:23particular component and impacted areas
6:25also related to that particular
6:27component.
6:28So testing a specific module where
6:31exactly we reported the bug is called as
6:34unit regression testing, the first type
6:36of testing. Testing only the changes or
6:39modification done by the developer. So
6:42what exactly the change part?
6:44Okay? So where exactly developer is
6:47modified, where exactly the developer is
6:49changed, only that particular part we
6:51are going to test. We are going to test
6:53the
6:54bug also, okay? So in the unit
6:56regression testing, whatever bug we
6:58reported,
7:00we will verify whether the bug is fixed
7:02or not.
7:03And
7:05change area. So because of that bug,
7:07what are all developer has changed?
7:10So developer will intimate you what are
7:11all other components have got changed
7:13because of this defect. So we will test
7:15only those components. Okay? That is
7:18called unit regression testing means
7:21testing only the changes or
7:23modifications done by the developer.
7:26Only changes or modification will be
7:27tested.
7:29But regional regression testing, there
7:31is another type of testing called
7:33regional regression testing.
7:35In this regression testing, we test the
7:37modified module
7:39along with the impacted modules.
7:42Testing the modified module along with
7:44the impacted modules. What does it mean?
7:47In the first unit regression testing,
7:50what are all changes have been done by
7:52the developer, we tested only those
7:54changes. Okay? Only that particular
7:57module.
7:58But
7:59in another type of regression testing,
8:01regional regression testing, what you
8:02will do is what are all changes have
8:05done by the developer, those changes
8:08along with that im- dependent modules
8:11and what are all other modules are
8:12impacted. And those modules or those
8:15features also will be tested. That is
8:17called regional regression testing.
8:19So in the unit regression testing, we
8:20are just verifying
8:22the changes have been done by the
8:24developer.
8:25Whereas regional regression testing, we
8:27are also going to test
8:29along with the changes, we are also
8:31going to test the impacted area. Suppose
8:34this may impact on other modules or some
8:36other feature. And those also we need to
8:38verify
8:39in the regional regression testing.
8:42But how we will know the reason how we
8:44will know the impacted areas?
8:46So what happens is in the regional
8:49regression testing,
8:50there will be a meeting called impact
8:53analysis meeting. There will be a
8:55meeting called impact analysis meeting
8:57conducts to identify impacted modules
9:00with a QA and dev.
9:02As soon as the dev is modified
9:03something, and dev and QA see together,
9:07and they will discuss where exactly that
9:09particular change or bug fix will be
9:12impacted.
9:13So that will be conducted between QA and
9:16dev. So they do some kind of impact
9:19analysis meeting. Impact analysis means
9:21what? Interview question again. What is
9:23impact analysis? So during impact
9:25analysis meeting, we will identify the
9:28impacted modules
9:30because of new changes, because of
9:33adding a new functionality, because of
9:35deleting the existing functionality, or
9:37because of modifying the existing
9:38functionality, or because of bug fixes.
9:42So because of all these reasons, there
9:43will be
9:44some functionality will be impacted. We
9:48will identify that feature or identify
9:50those functionalities is called as
9:53identify those functionalities and test
9:54those functionality. That is called as
9:56regional regression testing, which is
10:00called as regional regression testing.
10:03So,
10:04understood the difference? The first
10:05unit regression testing, only the
10:07changes done by the developer we will
10:09test.
10:10But in the regional regression testing,
10:12we are going to test the changes
10:14along with this
10:16impacted areas also we are going to
10:18test. But how we will know the impacted
10:19areas?
10:20During impact analysis meeting
10:23with the developers, we will consolidate
10:25all the impact and impacted meet
10:28impacted functionalities or impacted
10:29features and we will test those features
10:31also.
10:33That is regional regression testing.
10:36There is another testing called as full
10:38regression testing. Full regression
10:39testing. Understand this difference.
10:41Full regression testing means what?
10:44Let us say, I have multiple modules in
10:47my application. Let us say, 1 2 3 4 5 6.
10:51There are multiple modules are there in
10:53my application.
10:55So, I have reported one bug in
10:58particular module
10:59to the developer.
11:01Okay?
11:02And the developer, what the developer is
11:05done is the developer
11:08fixed that bug on that particular module
11:11and by fixing the bug, he has modified a
11:14lot on other modules also, the other
11:16functionalities. Almost
11:18for 100 100% features in these modules,
11:21almost 80% of the features are got
11:23modified.
11:24So, developer
11:27while fixing the bug, he is also touched
11:30other modules
11:31and also he modified a lot of other
11:34functionalities in other modules. Almost
11:3580% of the modules, he has almost
11:38modified them.
11:40Because of fixing this bug. At the time
11:42of fixing the bug, developer modified
11:44almost every module.
11:47So, in that case
11:48we don't do normally impact analysis.
11:51Why? Because almost 80% of the code is
11:55modified.
11:56Right? So, because of that change,
11:59instead of doing impact analysis
12:03we can do one and full round of
12:05regression testing. What does that mean?
12:07Just for doing impact analysis on
12:10specific module, that is again wasting
12:12of time here because he's almost
12:15modified each and every module in your
12:17application. Almost everywhere he
12:19modified because of that bug fix.
12:22So, instead of doing impact analysis on
12:24every module, identifying the scenarios,
12:26it again takes a lot of time and it is a
12:28wasting of time.
12:30So, instead of doing that we will do one
12:33full round of regression. So, we will
12:35test almost every module which is
12:38modified by the developer
12:40because of that bug fix.
12:42That is called as a full regression
12:44testing.
12:45So, here impact analysis cannot be done
12:47because he's almost modified every
12:49module. Instead of if we do impact
12:51analysis in this case, it is again
12:52wasting of time. So, instead of wasting
12:55the time, we will do one round of full
12:57regression. Um means we will test each
13:00and every module
13:02which is recommended by the developer.
13:04So, that is called as full regression
13:07testing. So, let me repeat once again.
13:10So, regression testing means what?
13:12Whatever bug fixes, sometimes on the
13:14build developer may add a new
13:16functionality or delete the
13:18functionality or modify the
13:19functionality or sometimes he may fix
13:22the bugs.
13:23And because of those changes, the
13:25existing functionality which is already
13:27there in the application should not be
13:29impacted
13:30or should not be broken.
13:32To make sure what you will do, we will
13:34test the changes from the developer
13:37along with the existing functionality of
13:39the application. That is called as a
13:40regression testing.
13:42So, unit regression testing, regional
13:44regression testing, full regression
13:46testing.
13:47In the unit regression testing, we
13:49testers only
13:51test the changes or modifications done
13:53by the developer.
13:55Whereas in the regional regression
13:56testing
13:57testing the modified module along with
14:00the impacted areas. And how we will know
14:02the impacted areas?
14:04In impact analysis meeting, we conduct
14:07the conduct to identify impacted modules
14:10or impacted areas
14:12and where we will discuss along with QA
14:14and dev. And then we'll identify the
14:16impacted areas and we will test them
14:18along with the changes. That is called
14:19regional regression testing.
14:22So, full regression testing means what?
14:24Testing the main feature and remaining
14:27part of the application. Almost
14:29everything we will test in the full
14:30regression because developer has changed
14:33a lot of things. He modified each and
14:35everything in the build. Almost 80% of
14:37the code is modified. So, instead of
14:39identifying impact impacted area, one
14:42round of full regression we will do
14:43that.
14:44So, that is called as full regression.
14:46Okay, that is a example. So, dev has
14:48done some changes in many modules.
14:51Instead of identifying impacted modules,
14:53we perform one round of full regression.
14:56Okay? So, this is all about regression
14:58testing. So, we have unit regression
15:00testing, regional regression testing and
15:03full regression testing.
15:05So, are you guys clear on this?
15:07Please confirm in the chat window what
15:09is regression testing.
15:11Very, very important testing.
15:14So, we have to test the modifications or
15:16bug fixes, new functionality, existing
15:19function. Because of those changes
15:21should not be impacted. Other
15:23functionality should not be impacted.
15:24That is called as regression testing.
15:28All right?
15:29So, next we'll move on to the
15:32retesting. The next terminology is
15:35retesting.
15:41Retesting. So, what is a retesting?
15:43Retest.
15:45Test again. The term itself is says
15:47retesting means
15:49we have to conduct the testing again and
15:51again. That is called retesting.
15:53So, what exactly it means? Let me give
15:55you one example. Retesting.
15:58Suppose in my application
16:00let's say I have my build in my
16:02application
16:03I found one defect.
16:05Okay, I found the defect.
16:08And I reported that defect to the
16:09developer.
16:11I reported to the developer. I reported
16:13that bug to the developer.
16:15So, once the developer will fix that bug
16:18and again will provide the another
16:19build.
16:21Okay, he will provide the another build.
16:23So, in the let's say this is my build
16:25number one, this is my build number two.
16:28In the next version of build uh that is
16:30build number two whatever defect we
16:32already reported in build number one
16:34the bug again we will verify in the
16:37build number two.
16:39That is called as a retesting.
16:41So, regression retesting means what?
16:43Whatever bugs we reported in the
16:45previous builds those bugs are fixed or
16:48not, we will verify in the upcoming
16:50builds.
16:51That is called as a retesting.
16:54So, why you're calling retesting means
16:55we already tested this functionality, it
16:58is
16:59not working earlier. But now again we
17:01are testing the same functionality
17:04whether it is working fine or not in the
17:06build number two. That is called as
17:08retesting.
17:10Retesting.
17:12Okay, retesting. So, whatever we
17:14reported the bug which is fixed in the
17:16next build and then again we are
17:18retesting the same functionality whether
17:20it is working fine or not.
17:22That is called as a retesting. Simple.
17:24But in the regression testing, what you
17:26will do? We will test that functionality
17:28along with the other functionalities
17:30also, impacted areas also we are tested.
17:33But in the retesting, we just verify the
17:36bugs what we have reported earlier
17:39and whatever the bug fixes we got, we
17:41verify only those bugs. That is called
17:44retesting.
17:45Small difference. Let me understand
17:47again.
17:48Whenever the developer fixed a bug
17:52tester will test the bug fix is called
17:54as a retesting. So, what is bug fix
17:56means? Bug fix is a nothing but a fixed
17:59bug. Whatever the bug is already
18:01developer fixed, that is called as a bug
18:03fix. It's a technical term.
18:05So, whenever the developer fixed a bug
18:09what tester will do? Tester will test
18:11the bug fix which is called as a
18:13retesting.
18:14Because we are testing again whenever
18:16the developer fixed that bug.
18:18And tester close that bug if it is
18:21worked. Otherwise, he again reopen and
18:24send to the developer.
18:25This is again continuous process, guys.
18:27Suppose we reported the developer we
18:30reported the bug to the developer.
18:32Developer is given the bug fix. Again,
18:34if it is not working, what you will do?
18:36Again, we will report to the developer.
18:38And again, developer will fix it and
18:39give back. Again, we will retest it.
18:42If it is working fine, we will close
18:43that bug. If it is not working, again we
18:45reopen and again resend to the
18:47developer.
18:49So, this is a continuous process until
18:51unless the bug is or defect is closed,
18:53we keep on reporting the bugs, we keep
18:55on reopening the bugs.
18:57So,
18:59tester close the bug if it is worked.
19:02Otherwise, he reopens and resend to the
19:05developer.
19:07And to ensure that the defects which
19:09were found and posted in the earlier
19:11build were fixed or not in the current
19:13build. So, the main intention of
19:15conducting the retesting is whatever
19:17bugs we reported in the previous builds
19:20they are fixed in the new build or
19:23current build or not.
19:25So, that is a main intention of doing
19:26retesting.
19:28And the next examples, suppose let us
19:30say build number one, 1.0 was released.
19:34And tested team found some defects. Let
19:36us say, 1.0.1,
19:381.0.2 and posted those defects or
19:41reported those defects into the
19:43developer.
19:44Now, in the build number 1.1, that is
19:46the next build or next release. Now,
19:48what tester should do? Now, testing
19:51the defects, same whatever reported in
19:54the previous builds, we are again
19:56verifying those defects working fine or
19:58not. That is called as a retesting.
20:02Okay, understand the difference. So,
20:03retesting means whatever bugs we
20:05reported in the previous build,
20:07in the next build, we are verifying the
20:09same functionality whether the developer
20:12is fixed those bugs or not. We are
20:13retesting the same functionality again
20:16and again. So, for retesting the
20:18functionality, what you are doing? We
20:19are executing the test case again and
20:21again.
20:23Okay, so if you want to test some
20:24functionality, we will have one test
20:26case. We will execute the test case.
20:27What is a test case means? Step-by-step
20:29execution. So, what we are executing
20:32certain steps and working fine or not.
20:33What is expected? What is actual?
20:35Expected and actual is exactly matching
20:37or not. So, that we are calling as a
20:39test case.
20:41So, in the first build, whatever the bug
20:43we reported, and that bug is fixed or
20:45not in the next build. To verify that,
20:48we have to execute the same test case
20:49again.
20:50So, executing the test cases again and
20:52again is also called as a retesting.
20:55Verifying the functionality again and
20:56again in the upcoming builds is called
20:58as a retesting.
21:00Okay, so regression testing and the
21:02retesting. So, have clarity on these
21:04two. Very, very important. And people
21:06will ask in interview also, what is the
21:08difference between retesting and
21:10regression testing? So, in the
21:11retesting, we are just verifying the
21:14bugs. Whatever we reported earlier, in
21:17the coming builds, they are fixed or
21:18not. So, retesting the functionality.
21:21But, in the regression testing, whatever
21:24bugs we reported in the previous builds,
21:26along with that, the new functionality
21:28which is added or modified or deleted.
21:31Because of those changes, there should
21:32not be impact on the other areas. Other
21:35impacted areas also we are going to test
21:37as part of regression testing.
21:39So, this is a basic difference between
21:41retesting and regression testing. So,
21:44very, very important question in
21:46interview.
21:47So, are you guys clear on this?
21:49Difference between retesting and
21:51regression testing. Everybody, please
21:52confirm in the chat window.
21:57So, retesting and regression testing.
22:05Okay, great. So, now let us move on to
22:07the next type of testing.
22:11So, the next type of testing is
22:16So, before going to the next example,
22:18let me just give you one more example.
22:20Retesting versus regression testing.
22:22Okay, so this is one testing, then you
22:23can understand very clearly.
22:28Okay.
22:31Now, let me just give you one small
22:33example before going to the next type of
22:35testing. So, retesting and regression
22:38testing. So, let us see the basic
22:39understanding and difference. So, let us
22:41say I have three features on my
22:43application. Let's say admin, purchase,
22:47and finance. Okay, there is an admin
22:49feature in my application or admin
22:51module.
22:52Purchase and finance. And these three
22:55modules are dependent. Okay, purchase
22:57module is depend on admin.
22:59Finance module is depends on
23:02purchase. So, they are integrated
23:03modules. Okay.
23:05And admin, purchase, and finance.
23:08So, here, let us say tester found a bug
23:11on purchase module. So, purchase is one
23:13module and tester found some bug in
23:15that. And also posted to the developer
23:17or reported to the developer.
23:19So, once the developer is fixed that bug
23:22in the purchase module,
23:24in the retesting, what you will do? You
23:26will verify only that particular bug,
23:29whether it is fixed or not. We will
23:31retest that functionality.
23:33That is retesting.
23:35But, because of that bug, because of
23:38those changes,
23:40the finance module also will be impacted
23:42because this is also depends on the
23:44purchase module.
23:45Okay, this is an impacted module.
23:48So, in the regression testing, what you
23:49will do? Apart from the bug fix, we are
23:51also going to test the finance module.
23:55Okay, that is a regression testing. So,
23:57retesting means testing the only the bug
24:00fix.
24:01No other functionalities.
24:03In the regression testing,
24:05verifying the bugs along with the
24:06impacted functionalities. And those
24:08impacted functionalities can be there in
24:10the same module or other module,
24:13sometimes in every module in our
24:15application.
24:16Okay, so
24:18understand the difference. So, if you If
24:20you do the changes, if you do the
24:22If you do If you test the impacted areas
24:25only within that module because of that
24:27change, that is unit regression testing.
24:29And if you test the impacted areas in
24:33other modules, one or two modules, then
24:35that is called regional regression
24:37testing.
24:38If you conduct testing on every module
24:40because of that change, which is called
24:42as full regression testing.
24:43Okay, just understand the difference.
24:45Retesting and regression testing.
24:49Now, let us move on to the another
24:51testing called smoke and sanity testing.
24:54Smoke and sanity testing.
24:57Okay, now let us discuss that. Smoke
25:00testing and sanity testing. These are
25:03also very, very, very important and
25:05definitely interview people will ask
25:07you. Smoke testing and sanity testing.
25:09Let us try to understand what exactly
25:11they are.
25:12First, let us start with the smoke
25:14testing and then sanity testing.
25:16Smoke testing.
25:18And both are basically basic
25:21functionality testing. So, in the smoke
25:22or sanity testing, we don't test the
25:24application in detailed. Very basic
25:27functionality we are going to test. Very
25:30basic functionality we are going to
25:31test. Let us understand the first smoke
25:34testing. What is a smoke testing?
25:37So, whenever the developer is provided a
25:40build to the tester, let us say
25:42developer
25:44is providing the build to the tester
25:47or we can say tester team.
25:50So, as soon as we get the build from the
25:52developer,
25:53build is nothing but a software, a piece
25:55of software which contains some number
25:57of features. Okay,
25:59so whenever we get the build from the
26:01developer,
26:02as a tester, what you will do is you
26:05don't directly
26:07go in deeper of application. So, you do
26:10some basic functionality testing. You do
26:12some basic functionality testing. What
26:14is basic functionality testing means? As
26:17soon as you get the build from the
26:18developer, first you will verify you got
26:22the complete build or not. You got the
26:24installer properly or not or is there
26:26any files are missing in the installer.
26:28That you will verify.
26:30And then you will do installation part.
26:33So, you install the build in your QA
26:35environment. And installation is
26:37perfectly working or not.
26:39Build is basically stable or not
26:41to continue further testings.
26:44So, you have to mainly focus on that
26:46area. That is mainly called as smoke
26:48testing. Smoke testing in the sense,
26:51you're basically verifying the health
26:54checkup of that particular build.
26:55Whether the particular build is stable
26:58on your environment or not. Properly
27:00install or not.
27:02And basic navigations are working or
27:04not. For example, when I open the URL,
27:06I'm getting the home page or not. When I
27:08click on something, some link, which is
27:11navigating to the next page or not. The
27:13basic level of testing you are
27:15performing before conducting the
27:17in-detailed testing or in-depth testing.
27:19That is called as a smoke testing.
27:22Okay, smoke testing is a basic
27:24functionality testing, which is also
27:26called as a build verification testing.
27:29Because here we are not focusing on the
27:32major features of application. We are
27:34just focusing on the
27:36build. We are just focusing on the
27:38build. Whether the build, the software
27:41contains all the files properly or not
27:44or anything is missing. And build is
27:46properly installing in our QA
27:48environment or not without any issues.
27:50And once successfully installed, whether
27:52we are able to navigate between the
27:54pages properly or not. This is called as
27:56a smoke testing. Very, very basic
27:58functionality testing is called as a
27:59smoke testing.
28:01And to doing this, we don't have any
28:03specific test cases or nothing. We are
28:05just verifying the build. So, which is
28:07called as a build verification testing.
28:10That is called smoke testing.
28:12Okay, understand this.
28:14Now, in initial days, the first whenever
28:17the software development testing process
28:19is started, in the first few cycles of
28:21testing,
28:22we will always get unstable builds.
28:25Because build will not be cannot be
28:27installed.
28:28Unstable builds. And suppose if you are
28:31not able to install the builds, you
28:32cannot continue with the rest of the
28:34testing.
28:35So, in few cycles, in few testing
28:38cycles, we will release the unstable
28:41builds. So, smoke testing will be
28:44conducted very frequently in every build
28:47whatever we are getting from the
28:48developer. In every build, whether the
28:51build whether the software or build or
28:54installer contains all the files are
28:55not. And whether it's properly
28:57installing or not. Basic navigations are
29:00working or not. URL is working or not.
29:02So, these things will be verified at the
29:04beginning level.
29:06And if these things are perfectly
29:07working, that means the build is stable.
29:10But, initial cycles, initial testing
29:12cycles, you will never get stable build.
29:16You will always get unstable build
29:17because
29:19just the developer is started
29:21development. So, you don't expect the
29:23build will be stable in the initial days
29:25itself. So, you will conduct the smoke
29:28testing.
29:29Okay, you will conduct the smoke
29:30testing.
29:31After few mini cycles, slowly build
29:34becomes a stable.
29:36Okay, in that time, as soon as the
29:38developer is providing the builds,
29:40the builds will be stable after few mini
29:43cycles.
29:44In that case, you will conduct the
29:46sanity testing.
29:48Okay, this is also basic functionality
29:50testing, but it is mainly focusing on
29:53the functionalities, very high-level
29:55functionalities.
29:57Not only the build installation
29:59navigations, it is also checking the
30:01main functionalities like login is
30:03working or not.
30:05Okay, products on the application is
30:06displaying or not.
30:08And links are properly working or not.
30:11Like login, logout is working or not.
30:13So, basic functionality testing we are
30:15going to conduct at the functional level
30:18or features level. That is called as a
30:20sanity testing.
30:21Okay, that is called as a sanity
30:23testing. So, smoke testing and a sanity
30:25testing both are comes under basic
30:28functional testing.
30:29We are going to test application at very
30:32high level.
30:33But what exactly difference means? Smoke
30:35testing will be conducted the initial
30:38days of
30:39testing life cycle. Because most of the
30:42times in the initial cycles, we will get
30:44the unstable builds. So, we have to
30:46verify the stability of the build,
30:49whether the build is stable
30:51or not. What is stability means? It
30:53should successfully installed and the
30:56basic navigation should perfectly work.
30:59That is called as a stability. So, once
31:01the stability is done, then we conduct
31:03sanity testing, regression, functional,
31:05and rest of the testings will be
31:06conducted.
31:08So, that is a smoke testing and a sanity
31:11testing. A smoke testing can be done by
31:13either tester or developers also. Can be
31:16done by testers or developers also.
31:19And uh before delivering this build to
31:21the tester, before giving the build to
31:23the tester, developer they also do some
31:25smoke testing in their environment,
31:27right? Because before providing the
31:29build to the tester, developer will
31:31install that application in their
31:33environment also, right? Don't blindly
31:35they will give the application to the
31:36tester. They will also install the our
31:38application or software in their
31:40environment, in the dev environment. And
31:42basic functionality is working or not,
31:44they will test it.
31:46And after that, they will release to the
31:47tester. So, there it is called as a
31:49smoke testing. So, developer can also do
31:51the smoke testing. And once you get the
31:54build, tester also can do the smoke
31:56testing. The build is properly installed
31:58or not, the
31:59basic functionality is working or not.
32:01But sanity testing is always conducted
32:04by the tester only. Because the
32:06developer will not test any features or
32:08functionality. Will test the only build.
32:11But sanity testing, what you will do? We
32:13are verifying the basic functionality is
32:14working fine or not.
32:16Once the build is stable, the basic
32:18functionality is working or not.
32:20So, sanity testing is always done by the
32:23testers.
32:24And smoke testing can be done by
32:26developers and also testers.
32:29Okay? And smoke testing will be
32:31conducted on unstable builds most of the
32:34times.
32:35And if the build is a stable, then we
32:37will concentrate on main functionality,
32:39very high level. That is called sanity
32:42testing.
32:43If smoke and a sanity testing is
32:45successful,
32:46then only we will accept the build from
32:48the developer. Remember, guys. Sometimes
32:51we can also reject the build.
32:53Developer is provided some build and
32:55smoke testing sanity testing is
32:57successful or passed, then we can accept
33:00the build and then we'll continue with
33:02the rest of the testings.
33:04But if the smoke testing is got or
33:05sanity testing was got failed,
33:08then we will reject the build and
33:10developer will create another build and
33:12provide that build to the tester. So,
33:14this is exact process will happen in the
33:16software testing process.
33:19Okay? So, whenever we receive the build
33:21from the developer, smoke testing should
33:23be done. And which will basically focus
33:26on the stability of the application or
33:28stability of the build.
33:30Basically, installation process will
33:31come into smoke. And once the build is
33:33stable, then we'll conduct the sanity
33:36testing. So, basic function working
33:37functionality testing is functional
33:39features are working or not, very high
33:41level, not in detail.
33:43So, once these testings are passed, then
33:45we'll accept the build and continue with
33:47the rest of the testings. So, that is
33:48called as smoke and sanity testing.
33:53Okay? So, first we'll conduct the smoke
33:55testing. Smoke is nothing but the first
33:58testing we have to conduct as soon as we
33:59get the build from the developer.
34:01Because until unless installation is
34:03successful, how we will conduct how will
34:05test the rest of the features?
34:07It is not at all possible, right? Your
34:09build, whatever the software you are
34:11receiving from the developer, first you
34:12have to install it. And then you can do
34:15some testings.
34:16So, that is smoke testing. Stable or
34:18not, install or not in your environment,
34:21that is most important thing. So, once
34:22the build is installed successfully,
34:24basic things are working and then
34:27we are focusing on the main features,
34:29sanity is working or not.
34:31Right? So, sanity is also sometimes part
34:33of the regression testing. So, once you
34:36developer fix some defect, we are going
34:38to verify the defect apart from this
34:40other impacted areas. So, we verify the
34:42sanity, we conduct the sanity testing on
34:44the other impacted areas.
34:47So, these two are the called basic
34:50functionality testing, smoke and sanity
34:53testings. And as when you have to
34:55conduct these two testings? Whenever you
34:57receive the build from the developer, in
34:59every cycle,
35:01you will get multiple builds, not only
35:03single build. Because developer will do
35:05a lot of changes, they will add a new
35:07functionality,
35:08delete the existing functionality, and
35:10do some changes on other builds, other
35:12functionalities.
35:13So, every time you will get the new
35:15build from the developer. So, whenever
35:16you get the new build from the
35:18developer, smoke testing will be
35:20conducted and then sanity testing will
35:22be conducted. And if there are any bug
35:24fixes, you should also conduct
35:26regression testing.
35:27So, this is all about smoke testing and
35:30sanity testing. Now, let us see the
35:33differences between smoke testing and
35:36sanity testing. Okay?
35:38So, let me just say what are the
35:40examples of smoke testing
35:42and a sanity testing. So, as I said
35:45before, smoke test is done to make sure
35:49the build we received from the
35:50development team is testable or stable
35:54or not.
35:56Sanity test is done during the release
35:58phase to check for the main
36:00functionality of the application without
36:02going deeper.
36:03That means what? As soon as we get the
36:05build from the developer, we verify the
36:08build stable or not. Stable or not, how
36:11we will know that? We have to install it
36:13first of all. Installation should be
36:15successful. Basic navigation should
36:17work. Then we can say the build is
36:19stable.
36:20But when we have to conduct sanity
36:21testing? Once the smoke is done and very
36:24high level, the basic functionality we
36:26are going to verify. That is sanity
36:28testing.
36:29And smoke testing is performed by both
36:32the developers and testers, as I said
36:34before.
36:35Before releasing the software to the
36:37testers, developer will cross-check
36:39whether it is properly installable or
36:41not.
36:42So, that is smoke testing from the
36:44developers.
36:45And once the build is released to the
36:47testers, testers will conduct the smoke
36:50testing. So, testers will install the
36:52build on their environment and test
36:55whether we successfully installed and
36:56properly or not.
36:58That is smoke testing. So, smoke testing
37:00can be done either both developers as
37:02well as testers.
37:04And sanity testing is only performed by
37:06the testers alone because they know
37:08exactly functionality of the
37:09application.
37:12Okay? And smoke testing, build maybe
37:16either stable or unstable. Stable. So,
37:18when I conduct the smoke test, why we
37:19are conducting the smoke testing? To
37:21check the build is a stable or unstable.
37:25Right? We have to know. We will know
37:27once you conduct the smoke testing, we
37:29will know whether build is stable or
37:30not.
37:31If it is not stable,
37:33then installation will definitely fail.
37:35If an installation is successful, the
37:36basic navigation will fail. Sometimes
37:38URL will be pinged. So, once you open
37:40the URL, home page will not be
37:41displayed.
37:43So, that means build is not stable.
37:45So, in the smoke testing, build maybe
37:47either stable or unstable. If it is
37:49unstable, immediately we reject the
37:51build. Then we will get another build
37:52from the developer.
37:54But in sanity testing, build is
37:56relatively stable.
37:58So, once the build is stable, then we
37:59will verify the basic functionality of
38:01the application.
38:02Login is working or not, logout is
38:04working or not,
38:05or links are working or not. So, these
38:08things we are going to verify once the
38:09build is stable. That is on sanity
38:11testing.
38:12That is also mainly focusing on the
38:14high-level features.
38:16Now, smoke testing done on initial
38:19builds, most of the times in the
38:20starting, in the beginning of test life
38:23cycles, we will most of the times we
38:25will get unstable builds. Unstable
38:28builds. So, there we will conduct smoke
38:30testing.
38:32And the sanity testing will be conducted
38:33on stable builds. First, installation
38:35should be successful and basic
38:37navigation should work on the
38:38application and then we will conduct
38:40other testings. So, sanity testing will
38:42be done on the stable builds.
38:44And smoke testing is a part of basic
38:47testing and sanity testing is a part of
38:49regression testing.
38:51And smoke testing usually done every
38:53time there is a new build is released.
38:57And the sanity testing is a planned when
38:59there is no enough time to do in-depth
39:01testing. Suppose,
39:03tomorrow I have to release the
39:05application and you don't have such time
39:07to execute all the test cases. So, what
39:09I will do is you will do basically
39:11sanity testing. So, basic functionality
39:13is working or not. And then release to
39:15the next department.
39:17Okay? So, whenever you don't have much
39:19time and if you want to really test high
39:22level of the application, then you can
39:24also conduct sanity testing.
39:26So, these are the differences between
39:28smoke testing and sanity testing. Smoke
39:32testing and sanity testing both are
39:34basic functionality testing. But the
39:37difference is in smoke testing is done
39:39at the beginning of the test cycles to
39:41check build is stable or not. In sanity
39:44testing, we are verifying the basic
39:46functionality is working or not after
39:47build is stable.
39:50As smoke testing will be done by the
39:51testers as well as developers, but
39:53sanity testing is always done by only
39:55testers because functionality we are
39:57verifying. Developer don't test the
39:59functionality, okay? We are verifying
40:01the functionality in the sanity testing.
40:04Now, let me show the picture, then you
40:05can understand.
40:06So, when exactly we conduct smoke
40:08testing? When exactly we conduct sanity
40:10testing? So, for example,
40:12we have an initial or unstable build.
40:15The first time the developer is
40:17releasing the build to the tester. What
40:19he will do? We do smoke testing to check
40:22the build is stable or not.
40:25Or build is installable or not.
40:27And if the smoke test is passed, then
40:29what you will do? We will conduct with
40:31the rest of the testing, system testing,
40:33all the types of testing, regression
40:35testing, rest of the testings we will
40:36conduct here.
40:38Suppose smoke testing is got failed.
40:41Smoke test is passed, no? Then build
40:43will be rejected.
40:45Build will be rejected. We don't
40:47continue any testing on that build.
40:49Understand, okay? So, suppose after
40:52getting some more cycles like build one,
40:54build two, after getting few number of
40:56builds in the testing life cycle, slowly
40:58the build becomes stable.
41:00Slowly the build becomes stable.
41:02Installation will be successful every
41:03time.
41:04In that case, we will do sanity testing.
41:08Means basic functionality with very high
41:10level we are going to test.
41:13And that is
41:14sanity testing. And if it is passed,
41:17then again we'll conduct the rest of the
41:18system testing and regression testing.
41:20Again, if it is failed, then again we
41:22reject the build.
41:23In both the cases, either smoke testing
41:25and sanity testing is got failed, we
41:27reject the build. We don't accept the
41:30build. Again, developer will provide
41:32another build and will continue with the
41:34testing.
41:35Okay. So, this is our
41:37differences between smoke testing and
41:40the sanity testing. So, the first
41:41testing is smoke testing followed by the
41:43sanity testing. Smoke testing focus on
41:46the stability of the application.
41:47Whereas sanity testing is focus on the
41:50main features at very high level, basic
41:52features of the application.
41:55And smoke testing conducted at the
41:57initial testing life cycle to check the
41:59build is stable, whereas sanity testing
42:02will be conducted after few cycles.
42:05After build is stable. And very basic
42:08functionality is working or not. So,
42:09that is sanity testing.
42:12So, are you guys clear on this? Smoke
42:13testing and sanity testing.
42:19All right. So, now
42:21let us move on to the next type of
42:23testing,
42:24exploratory testing.
42:27Exploratory testing. So, what is meant
42:29by
42:30exploratory testing?
42:33So, exploratory testing.
42:37So, sometimes what happens is in your
42:40testing environment in your company,
42:43so you don't have any requirement,
42:46but your application is ready.
42:48Okay? Your application is ready, but at
42:51that time you don't have any
42:52requirement. You don't know the
42:53functionality actually. You don't have
42:55any You don't know any You don't have
42:57any FRS document. You don't have any
42:58design document. No documentation is
43:01available, but your application is
43:03ready.
43:04Okay?
43:05And you have to
43:07test the application by exploring the
43:09functionality.
43:11So, you have to test the application by
43:13exploring the functionality. Suppose
43:15you have joined in some new company. In
43:18that company, software is already
43:19developed
43:21and documents documentation is still not
43:23ready. And they have given that
43:25application to you
43:26and
43:27try to understand the functionality.
43:30So, they have given that application to
43:31you and ask you to understand the
43:34functionality and do some kind of
43:36testing.
43:37So, what you will do? Without having any
43:40documents, without having any test cases
43:43or without having any test scenarios,
43:45you will explore the application and
43:48understand it completely and test it.
43:51That is exploratory testing. Explore.
43:54Here explore means what? You don't know
43:56anything before that. You don't have any
43:58documentation. You don't have any
44:00test cases, nothing. You will just
44:03explore the functionality of the
44:04application
44:05based upon your previous experience.
44:07So, you will open the URL. You will do
44:10the login. You will click on some
44:11register link. And you will click on
44:13some shopping cart, select the product.
44:15So, without knowing any functionality,
44:18you just explore the application and uh
44:21understand the application.
44:23While exploring, understand the
44:24application and test the functionality,
44:26which is called as a exploratory
44:28testing.
44:29So, we have to explore the application,
44:32understand it, and test it. That is
44:34called as exploratory testing.
44:36And understanding the application,
44:38identify all the possible scenarios, and
44:41document it, then use it for testing.
44:44So, in exploratory testing, what you
44:45will do is first you will have
44:47application
44:48and
44:49explore each and every option, each and
44:51every feature in your application,
44:53and document it. Write a small document,
44:55what are the scenarios you have
44:57identified in your application, and
44:58write the document, and use those
45:01scenarios for testing. And test those
45:03scenarios.
45:04That is called as exploratory testing.
45:06So, this is completely depends on the
45:08tester
45:10experience level. Suppose tester is
45:12already worked on previous
45:14domains or previous projects, he has
45:16some kind of experience. And with that
45:19experience, the new applications can
45:21easily explore. Suppose you are worked
45:23on some banking application.
45:25And it is completed project. Then you
45:26have joined in another company, there
45:28also you got some banking application.
45:31And without any documentation also you
45:32can easily explore the application
45:34because you have some previous knowledge
45:35on the banking domain. You know exactly
45:37how bank works, how functionalities will
45:39be there.
45:40And the same functionalities you can
45:42expect in the new application, new
45:43project also. So, explore the
45:45functionality of the application without
45:48having any document and exploring it,
45:50finally you test those features or test
45:52those scenarios. That is comes under
45:55exploratory testing.
45:57So, we do exploratory testing when the
46:00application ready, but there is no
46:02requirement.
46:03So, test engineer here will do
46:05exploratory testing when there is no
46:07requirement.
46:09Okay? Understand this is exploratory
46:11testing. So, just we have to identify
46:13the application, understand the
46:14application by going through all the
46:16flows, and test it without any
46:18documentation. That is exploratory
46:20testing.
46:21But there are some drawbacks in the
46:22exploratory testing.
46:24And this is another important interview
46:26question. So, what are the drawbacks in
46:27exploratory testing? So, first question
46:29is when you will do exploratory testing?
46:32So, exploratory testing will be done
46:35if the application is ready, but there
46:37is no documentation. In that case, we
46:39can conduct exploratory testing.
46:41But what are the drawbacks in
46:43exploratory testing?
46:45There are few drawbacks are there, very
46:46very important.
46:48So, the first and most important
46:50drawback is you might misunderstand any
46:53feature as a bug
46:54or any bug as a feature.
46:57You can misunderstand any feature as a
46:59bug or a bug as a feature.
47:02So, for example,
47:03let us say I have a small login screen.
47:06So, let's try to understand with the
47:08example, guys. What is a drawback in
47:10exploratory testing?
47:12So, you have an application in which
47:14there is a login login login screen.
47:18So, in the login screen, normally with
47:20your previous experience, what you will
47:21expect? The login screen most of the
47:24times it contains a username and
47:26password, that's username and password.
47:29Along with this, let us say some ID.
47:32There is one more field is available in
47:33application.
47:35Now,
47:36based on your previous experience while
47:38exploring the application,
47:40username, password will be there, okay,
47:42that is fine, but additionally you can
47:44see some employee ID here.
47:47Okay? So, you don't have any
47:49documentation which talks about the
47:51functionality. But what you will assume?
47:54You may assume like this is a bug
47:56because a login should not contains this
47:58one, right? Only username, password,
48:00okay, cancel button should be there. But
48:02other than this field, if there if you
48:04found some other field or some other
48:07uh feature,
48:08you may think that is a bug
48:10because you don't have proper document.
48:12You are just doing exploratory testing.
48:14So, there are some chances you
48:16misunderstand whether this feature is a
48:18bug.
48:20Okay? So, that is one problem. Suppose
48:22sometimes there will be bug and you can
48:24consider that also feature.
48:27Okay, sometimes same EMP ID is provided
48:30and this is a feature, part of the
48:32feature, but you will think like it
48:33should not be there in your username,
48:35password. The login means only you
48:36should expect only username, password.
48:38It should not be there. You may consider
48:40this as a bug
48:42or you may consider as this feature
48:44because you don't have a such document
48:46which says this is a part of the feature
48:48or this is not part of the feature. If
48:50it is not part of the feature, you can
48:52consider that is a bug.
48:55Okay, if it is a part of the feature,
48:57then you can consider as a functionality
48:58or feature, that is not a bug.
49:01So, you don't know exactly whether that
49:04is a bug or feature. You cannot
49:06discriminate it because you don't have
49:08such document which says the
49:10functionality of the application.
49:12So, this is a major drawback in
49:15exploratory testing, guys. Very very
49:17important. So, in exploratory testing,
49:20you might misunderstand any feature as a
49:22bug or any bug as a feature. Sometimes
49:26you may think a bug is a feature.
49:28Sometimes you may think a feature is a
49:30bug.
49:31But we don't have such requirement
49:33document. So, that is a one of the
49:36important drawback in while performing
49:38the exploratory testing.
49:40And then, time-consuming.
49:43Because you don't know the requirement,
49:45you are just keep on exploring each and
49:47every functionality. It takes a lot of
49:49time.
49:50If you have a documentation, directly
49:52you will test the application. You will
49:54verify all the scenarios based upon the
49:56documentation.
49:57Which will complete within less time
49:59because you already have documentation.
50:01But you don't have any documentation,
50:03nothing. You're just going exploring the
50:05application, it takes a lot of time.
50:08Because you don't find any help there.
50:10So, it is a time-consuming process.
50:13And finally,
50:15if there is any bug in the application,
50:17you'll never know about it. There is any
50:19bug in the application, you will never
50:21know about it because
50:23is there any documentation there? No. No
50:26documentation says about feature or bug.
50:29So, sometimes if you have a bug in your
50:31application, you don't think that is a
50:32bug.
50:33Because you don't have any documentation
50:35or anything.
50:36So, you don't know exactly whether it is
50:38a bug, really a bug or not.
50:40So, that is another biggest problem. So,
50:42there are some chances to miss some
50:44number of bugs.
50:46So, these are the main three
50:47disadvantages or drawbacks of
50:50exploratory testing.
50:53Remember, very, very important. So, in
50:55exploratory testing, we are exploring
50:58the functionality of the application
51:00without having documentation.
51:03We We don't have any test cases, we
51:04don't have any document, nothing. We are
51:06just exploring the functionality of the
51:07application ourselves without depending
51:10on anything else.
51:12And we are identifying all the scenarios
51:14and document it and use those scenarios
51:16for testing purpose. That is exploratory
51:18testing. So, when you will conduct this?
51:21If application is ready, but
51:22documentation is late or by the time it
51:25is not yet implemented. In those cases,
51:27you will conduct exploratory testing.
51:29So, the drawback in the exploratory
51:31testing means you might misunderstand a
51:33bug as a feature or a feature as a bug.
51:35You don't know exactly which one is a
51:37feature, which one is a bug.
51:39Because of that reason, it is very
51:40difficult to
51:41uh check whether it is a bug or a
51:44feature.
51:45So, these are the drawbacks of
51:47exploratory testing. Very, very
51:49important testing.
51:50And now, I'll explain about one more
51:52testing called
51:55ad hoc testing. So, exploratory testing,
51:58ad hoc testing, monkey testing. So,
52:01these three seems very similar type of
52:03testings, okay? First, I'll tell you
52:06exactly uh what kind of testings they
52:09are and finally, we'll compare all three
52:11testings. Then, we can understand the
52:12differences, okay? So, now we have
52:14discussed about exploratory testing.
52:16What What is exploratory testing? When
52:19you have to perform? What are the
52:20drawbacks? Now, let us talk about ad hoc
52:23testing.
52:25So, what is ad hoc testing and when you
52:27have to perform?
52:29So, during ad hoc testing,
52:31here also, we don't have any
52:33documentation. We don't have any test
52:36cases, we don't have any requirement,
52:38nothing. We don't have anything in our
52:40hand.
52:41You have just have an application.
52:43So, but you don't know
52:46any functionality on this. So, testing
52:48the application randomly without any
52:50test cases or any business requirement.
52:54Here also, we are testing the
52:55application randomly without any test
52:58cases or without any business
52:59requirement document.
53:01Means what? Suppose I have given
53:03application to you
53:05and you have some previous experience on
53:07some other projects, same kind of
53:09domains.
53:10And immediately, what you do? You can do
53:12some kind of testing. Ad hoc testing you
53:14can conduct. Ad hoc is nothing but a
53:15random.
53:17Randomly test the functionalities
53:20with knowing the functionality. Means
53:22what? Based upon your previous
53:24experience,
53:26you can assume the functionality.
53:28Okay, so login should be there. You know
53:30how it should work. Logout link is
53:32there. You know how it should work.
53:35Okay, and inbox, Gmail inbox is there.
53:38You know how it should work. So, to test
53:40these things, you don't need any
53:42documentation. So, randomly you can test
53:44the features.
53:46Which is called as ad hoc testing.
53:48So, testing application randomly without
53:51any test cases or any business
53:53requirement is called ad hoc testing.
53:56And which is an informal testing type
53:59with the aim to break the system. So,
54:01informal testing means what? We don't
54:03have any proper plan.
54:05We don't have any
54:07uh such a cycle where you have to
54:08conduct ad hoc testing. So, we don't
54:10have like like in case of sanity and
54:12smoke testing, like whenever we get the
54:14build, immediately we have to conduct
54:16those testings. But in ad hoc testing,
54:18we don't have such type of rule. We can
54:21conduct ad hoc testing at any time.
54:23So, because we have to test the
54:25application,
54:26basic uh we have to test the
54:28application. It is not a basic
54:29functionality testing, we have to test
54:30each and everything randomly.
54:33Okay? So, it is a informal. Informal
54:36means we can conduct at any time
54:38whenever it is needed.
54:39And the main intention of doing ad hoc
54:41testing is to break the application.
54:44So, why we have to break the
54:45application? Because
54:46this is a fundamental job of a tester.
54:49Tester is always
54:51try to break the application, try to
54:53find the defects at the corner levels.
54:56That's the main intention of doing
54:57testing.
54:58So, we always think about the negative
55:00way, guys. If you see the application,
55:01some fields, you always think you need
55:04to have some kind of analytical skills.
55:06So, suppose if I provide some data, it
55:08is working fine. And if I provide
55:10something else, it should not work.
55:12Right? Suppose if I take small username
55:14field,
55:15try to enter some characters, try to
55:17enter some numbers, try to enter some
55:18special characters, try to enter some
55:20space and let's see what is happening.
55:23So, this kind of skill set that tester
55:25should always have it. So, our intention
55:27is always break the system or break the
55:31uh breaking in the sense some
55:33functionality should should not work. In
55:35that way, we have to
55:36cover the testing. So, it is a informal
55:38testing. So, there is should not be any
55:40plan for that. Whenever you need, you
55:42can conduct ad hoc testing. So, randomly
55:44test the application.
55:47And whatever feature you find an
55:49application, you can test it. That is
55:51called as random testing.
55:54And here, you know
55:56some knowledge of application. Based
55:58upon your previous experience, you know
55:59some functionality here.
56:01You know how login works. You know how
56:03logout You know how can save the
56:05product. You know how to add the product
56:07to the cart. You know already something.
56:09So, based on that, you can perform this
56:11testing, ad hoc testing.
56:13And seems very similar, exploratory, ad
56:16hoc, and next time I'm going to discuss
56:18monkey testing also, but there is
56:19difference. I'll consolidate all three
56:21and I'll explain the differences also.
56:23Okay, first let us understand individual
56:26test case. Like we have understood what
56:28is exploratory testing. Now, we
56:30understanding ad hoc testing and then
56:32we'll understand the monkey testing.
56:33After that, we will compare it, okay?
56:36So, ad hoc testing is nothing but
56:37testing the application randomly
56:41and without any test cases or documents.
56:45But we know some functionality. Even
56:46though we don't have a document, based
56:47on our previous experience, we can
56:49assume the functionality.
56:51Okay? And tester should have knowledge
56:54of application even though he doesn't
56:57have requirement or test cases. How he
56:59will have the knowledge? Depends on your
57:01previous experience.
57:03Okay? And this testing is usually is
57:05unplanned. We don't have any planning
57:07for this testing. Whenever it is needed,
57:09we can conduct this testing. Ad hoc
57:11testing means randomly test the
57:13functionality.
57:15But here, we know the functionality, we
57:17can assume the functionality of the
57:18application. This is ad hoc testing.
57:21And you can also conduct this testing
57:24to find the corner scenarios. Sometimes,
57:27uh your functional test cases or
57:29whatever test case you have written,
57:30they may
57:31catch the corner scenarios. Corner
57:34scenarios Corner scenarios in the sense
57:35what? While using the application,
57:37somewhere
57:39which is not identifiable.
57:41In those cases, in the corner scenarios,
57:43we have to conduct some kind of testing.
57:46That is ad hoc testing. Random testing.
57:48While doing random testing also, you may
57:49find some number of defects.
57:52Okay? So, this is ad hoc testing. Now,
57:54come to the another type of testing
57:56called monkey testing and gorilla
57:58testing.
57:59So, monkey testing and gorilla testing.
58:01And here,
58:03also, we test the application randomly
58:06but without knowing any functionality.
58:09Here also, we don't have any
58:10documentation, no test cases, nothing.
58:13But here also, we are testing the
58:15application randomly, but without
58:17knowledge of application.
58:20We don't know anything about
58:21application. Testers do not have
58:23knowledge of application.
58:26But in ad hoc testing,
58:28we have to know about application. Based
58:30on your previous experience, you can
58:31assume the functionality and you can
58:33test it. So, you have to know about
58:35application even though you don't have a
58:36documentation. But here, you don't have
58:39a documentation and also, you don't know
58:41about application.
58:43But still, you can conduct some testing.
58:46Which is called as monkey testing.
58:48Example,
58:49gaming application. Suppose, in your
58:51mobile or tab, you found some games,
58:54right? And normally, the children will
58:56play games, right? So, they don't know
58:58exactly initial days, they don't exactly
59:00how to play with the games. So, as soon
59:02as you open the game, they will do some
59:04kind of clicking and some They do lot of
59:06things randomly, but they don't exactly
59:08how to work with that.
59:10In those cases, application should not
59:13break.
59:14That is called monkey testing. So, here
59:16and there, we will jump and then do some
59:19kind of testing. Without knowing
59:21functionality of the application. You
59:22don't know how to work with that. You
59:23don't know how it is working with that.
59:25But still, you can just randomly click
59:27on something and see what is happening.
59:30So, that is a kind of testing we do,
59:32which is called as monkey testing or
59:34gorilla testing.
59:36Why we are calling monkey testing means
59:37it is not a stable. Sometime we click on
59:39that button, click on this button,
59:41select the radio button, and without
59:43entering any data, just directly click
59:45on okay button or submit button, then
59:47we'll see what is exactly happen.
59:49Especially gaming applications, people
59:51will do this kind of testing.
59:53Monkey testing. And here also, we do
59:56testing randomly without any
59:58documentation or requirement,
1:00:00which is also informal.
1:00:02And uh the thing is here tester also
1:00:05don't know the knowledge of
1:00:06applications. So, suitable for gaming
1:00:09applications.
1:00:10So, now if I see
1:00:12ad hoc testing, exploratory testing, ad
1:00:14hoc testing, monkey testing,
1:00:16three seems very similar.
1:00:18But now let us understand the
1:00:20differences between these three.
1:00:22So, first start with ad hoc testing. In
1:00:24ad hoc testing,
1:00:26no documentation. Even monkey testing is
1:00:28also no documentation. Exploratory
1:00:31testing is also no document. No
1:00:33documentation in the sense what? We
1:00:35don't have a test cases. We don't know
1:00:37the scenarios. We don't have any FRS
1:00:39document. Nothing is available.
1:00:42But in both three cases, application is
1:00:44available. Our software is available.
1:00:46But there is no documentation.
1:00:49So, in ad hoc testing, monkey testing,
1:00:51and exploratory testing, in three types
1:00:53of testings, there is no documentation.
1:00:56Next point.
1:00:58And these three testings, to conduct
1:01:00these three testings, there is no plan.
1:01:03We can conduct it anytime.
1:01:05Okay, there is no proper schedule. But
1:01:08rest of the testing like regression
1:01:09testing, functional testing, we have a
1:01:10proper schedule. And from so and so day
1:01:13to so and so day, we have to conduct
1:01:15this type of testing. There is a plan.
1:01:17But to conduct these testings, there
1:01:19will not be any plan. We can conduct it
1:01:21anytime. Ad hoc testing, monkey testing,
1:01:24and exploratory testing.
1:01:26Next. All three are informal testings
1:01:29because there is no plan. If it is a
1:01:31plan and schedule, that is a purely
1:01:33formal testing. But due to there is no
1:01:35plan at all, so we can just say informal
1:01:38testing process, informal testings. Now,
1:01:41let's see the differences.
1:01:44In ad hoc testing, tester should know
1:01:46the application functionality.
1:01:49So, tester should know the application
1:01:51functionality. He has some kind of
1:01:53experience on the same kind of projects
1:01:55earlier.
1:01:56Then he can assume the functionality of
1:01:58the application, he can do some testing.
1:02:00Randomly test the functionality by
1:02:03knowing the functionality. That is ad
1:02:05hoc testing.
1:02:07Randomly test the application
1:02:10without knowing the functionality is
1:02:12called monkey testing.
1:02:14So, tester doesn't know the application
1:02:16functionality. But in ad hoc testing,
1:02:17tester should know the application
1:02:19functionalities. In monkey testing,
1:02:21tester doesn't know the application
1:02:22functionalities. But when you come to
1:02:24the exploratory testing, here also
1:02:26tester doesn't know the application
1:02:27functionality. But here we are exploring
1:02:29the functionality. We are
1:02:31exploring the application,
1:02:33then we come to know the functionality.
1:02:35So, in monkey testing and exploratory
1:02:37testing also, we don't know the
1:02:39application functionality or features.
1:02:41We are just
1:02:42testing randomly.
1:02:44But in ad hoc testing, we know some
1:02:46functionality based upon upon your
1:02:48previous experience.
1:02:50Now, all three are random testing. So,
1:02:53why you say random means there should
1:02:54not be any order we need to follow. We
1:02:56don't need to follow any order.
1:02:58So, random testing. Randomly can choose
1:03:00any other functionalities and you can
1:03:02test it in all three kinds of testing.
1:03:05So, random testing.
1:03:07Now,
1:03:08the intention is to break the
1:03:10application or find out the corner
1:03:12defects. Why we do ad hoc testing?
1:03:14Intention is to break the application.
1:03:16We will check somewhere our application
1:03:18is breaking or not.
1:03:20And somewhere some corner scenarios are
1:03:22working properly or not.
1:03:24That is the main intention of ad hoc
1:03:25testing.
1:03:26And the main intention of the monkey
1:03:28testing is also break the application
1:03:31and finding the corner defects.
1:03:33And the main intention of exploratory
1:03:35testing is to learn and explore the
1:03:38functionality of the application.
1:03:40In exploratory testing, the mainly our
1:03:42focusing on learning the application
1:03:44because we don't know the application.
1:03:45We don't have any documentation. So, we
1:03:47are going to learn the application. Even
1:03:49we don't have a prior knowledge of that
1:03:51application. So, the main intention of
1:03:53doing in exploratory testing is
1:03:56to explore the functionality of the
1:03:57application and then test it.
1:04:00Okay. And ad hoc testing can be done on
1:04:03any kind of applications. And monkey
1:04:05testing especially preferred for gaming
1:04:08applications because children most of
1:04:09the time children will play with the
1:04:11games. So, they don't exactly how we
1:04:13need to operate those games.
1:04:14So, gaming applications.
1:04:17And exploratory testing also can be done
1:04:19on any application which is new to the
1:04:21testers.
1:04:22Okay. Because I'm a tester, I have an
1:04:24application, I don't know about that. I
1:04:26don't know about any functionality of
1:04:27the application, then exploratory
1:04:29testing will be done. Explore the
1:04:31functionalities, identify all the
1:04:33scenarios,
1:04:34and use those scenarios for testing.
1:04:36So, these are the similarities and
1:04:39differences between ad hoc testing,
1:04:41monkey testing, and exploratory testing.
1:04:44Guys, you have understood now. Please
1:04:45confirm in the chat window, everyone.
1:04:50Now, let us move on to the next type of
1:04:53testing called positive testing and a
1:04:56negative testing. So, these again seems
1:04:58very similar.
1:04:59Positive testing and a negative testing.
1:05:02Now, let us see about positive testing
1:05:04or negative testing. Now, let us see
1:05:07what is positive testing, what is
1:05:09negative testing.
1:05:10So, before that, let me write here.
1:05:13Exploratory testing we have discussed.
1:05:18Ad hoc testing.
1:05:21And then
1:05:22monkey testing. Okay, these three
1:05:25testing, regression testing are similar.
1:05:27Seems very similar but not similar,
1:05:29okay? So, that's the reason we compared
1:05:31them.
1:05:32And these three seems very similar but
1:05:34they are not similar. So, we have
1:05:35compared them.
1:05:37And now I'm talking about positive
1:05:40testing
1:05:41and then negative testing.
1:05:45So, now we'll understand what is
1:05:47positive testing, what is a negative
1:05:49testing.
1:05:52Positive testing and negative testing.
1:05:54So, testing the application with valid
1:05:56inputs is called as a positive testing.
1:05:58Simple. So, testing the application with
1:06:01the positive inputs and working or not.
1:06:04That is positive testing. And testing
1:06:07the application with the negative inputs
1:06:09and it should not work.
1:06:11That is negative testing. So, for
1:06:12example,
1:06:13let us take a small text box and my
1:06:15requirement is the text box allows only
1:06:19numbers.
1:06:20The text box allowed only numbers.
1:06:23So, if I provide only numbers into the
1:06:25text box, it should allow. That is a
1:06:27positive testing.
1:06:29That is a positive testing.
1:06:30So, from zero to 99999, you can enter
1:06:33any number in this text box. So, it
1:06:36should accept. This is positive testing
1:06:38because we provided the positive input
1:06:40to the
1:06:41application.
1:06:43So, testing the application with the
1:06:44valid inputs is called as a positive
1:06:47testings.
1:06:48It checks whether an application behaves
1:06:51as expected with positive inputs.
1:06:54And this is an example.
1:06:56Now, negative testing. Testing the
1:06:58application with invalid inputs is
1:07:00called negative testing.
1:07:02For example, in this box, it is
1:07:04accepting only numbers. But what you
1:07:06have done here? We are trying to test
1:07:09whether it is accepting characters or
1:07:11not. When I pass numbers, it should
1:07:13accept. That is positive testing. Now,
1:07:16when I pass a characters or spaces or
1:07:18special symbols, then it should not
1:07:20accept. That is our negative negative
1:07:23testing.
1:07:24So, always we have to think positive as
1:07:27well as negative way, guys. As a tester.
1:07:29Okay. So, because
1:07:31as a end user, as a user, I can provide
1:07:33anything into the text box.
1:07:35But is it tester's responsibility
1:07:38test that application in all kinds of
1:07:40scenarios. You should not miss even a
1:07:42small scenario.
1:07:44Okay. In all the conditions, with all
1:07:46the different type of data, you have to
1:07:47test in all the cases. Whether you
1:07:49provide the positive input, it should
1:07:51work as per your expectation.
1:07:54When I pass invalid input, it should not
1:07:56work.
1:07:58Okay, it should differently work.
1:07:59Suppose when I say valid username, valid
1:08:02password, it should successfully log in.
1:08:04That is a positive testing.
1:08:06When I pass invalid username and invalid
1:08:09password,
1:08:11the application should not log in. That
1:08:13is a negative testing. So, test the
1:08:15application with the positive data is
1:08:17called positive testing. Test the
1:08:19application with the negative data,
1:08:21which is called as a negative testing.
1:08:23So, when you're writing your test cases,
1:08:25we have to make sure you should cover
1:08:28positive test cases as well as negative
1:08:30test cases.
1:08:31Okay. So, this is a positive and
1:08:33negative simple test case.
1:08:35Okay, let us say this is an example.
1:08:37I've given one enter only numbers. But
1:08:39what I have entered here? Alphabets. So,
1:08:42how we can perform the negative testing?
1:08:43We can enter small characters from A to
1:08:45Z, upper case characters from A to Z,
1:08:47special symbols, spaces.
1:08:49These are all negative data.
1:08:51Negative test data. So, whenever you
1:08:53provide this kind of data, your text box
1:08:56should not allow it. It should give some
1:08:58message or error, invalid input or
1:09:00something like that. So, that is
1:09:02negative testing.
1:09:03That is negative testing. So, testing
1:09:06the application with the positive or
1:09:09valid data, which is called as positive
1:09:11testing. Testing the application with
1:09:13negative data or invalid input, that is
1:09:15called as negative testing. Very simple.
1:09:19Now,
1:09:20this is this is the example I have
1:09:21given, positive versus negative test
1:09:23cases. For example, let us say I I a
1:09:25small requirement here.
1:09:27A text box is listed as a feature
1:09:30in FRS. It is mentioned as a text box
1:09:32accepts
1:09:336 to 20 characters and only alphabets.
1:09:38Read the requirement once again.
1:09:406 to 20 characters.
1:09:42The number of characters should be 6 to
1:09:4420. Minimum 6, maximum 20.
1:09:47And those characters are only alphabets.
1:09:49Alphabets means what? A to Z. Either
1:09:52upper case characters or lower case
1:09:54characters. So, that's the requirement.
1:09:57Now, when I see the positive test cases,
1:09:59what are all positive test cases will
1:10:00come here?
1:10:02Text box accepts six characters.
1:10:04Yes or no? Yes.
1:10:06Text box accept up to 20 characters.
1:10:09Yes, this is also positive test case
1:10:11because 6 to 20 we said.
1:10:13Text box accepts any value in between 6
1:10:16to 20 characters. Yes. 6 to 20 means
1:10:19what? I can enter 10 characters, 15
1:10:21characters
1:10:22or 18 characters, anything, right?
1:10:24Between these two numbers I can enter
1:10:25any number of characters.
1:10:27And text box accepts all alphabets. So,
1:10:30these are all positive test cases.
1:10:32Verify the text box with all kinds of
1:10:34inputs. But, what are the negative test
1:10:36cases?
1:10:37Text box should not accept less than six
1:10:40characters. Means, try to enter less
1:10:42than six characters like five, four,
1:10:44three, then it should not accept. That's
1:10:46our expectation.
1:10:48Text box should not accept characters
1:10:50more than 20 characters also. Try to
1:10:52enter 21, 25, something like this it
1:10:55should not accept.
1:10:56Text box should not accept special
1:10:58characters like like question marks,
1:11:01percentage symbol,
1:11:02stars should not accept. Text box should
1:11:05not accept numbers or numericals like 1
1:11:082 3 4, number should not accept. So,
1:11:10these are all negative test cases.
1:11:12So, this is a simple example. Positive
1:11:14test cases and a negative test cases.
1:11:16Test the application with the positive
1:11:18input is called positive testing.
1:11:20Testing the application with the
1:11:21negative inputs or invalid inputs are
1:11:23called negative testing.
1:11:26And then
1:11:28end-to-end testing.
1:11:30So, what is end-to-end testing?
1:11:32Sometimes
1:11:34uh your lead will ask you so perform
1:11:36end-to-end testing.
1:11:37So, you need to understand what is
1:11:38end-to-end testing.
1:11:40So, end-to-end testing means
1:11:42testing the overall functionality of the
1:11:44application.
1:11:45That functionality covers each and every
1:11:48flow in your application.
1:11:50So, let's say I have some application
1:11:52and uh let's say Gmail application. In
1:11:54the Gmail application, you have a login
1:11:57and you have a compose
1:11:59and you have sent a sent email and
1:12:02deleted email. So, different components
1:12:04are there.
1:12:05And I want to test end-to-end
1:12:07functionality.
1:12:08Then what I can do? First, I will login
1:12:11to the application.
1:12:12And after successful login, I'll compose
1:12:14a email.
1:12:15Then I can test that email comes into
1:12:18compose box or not. Then again delete it
1:12:20from there. Then come to I'll check it
1:12:23will come to send it will come to
1:12:25deleted emails or not. That's it. This
1:12:27is end-to-end testing. So, which will
1:12:29cover all the components in sequentially
1:12:31which is covered all the components. So,
1:12:33in
1:12:34login box is covered, inbox is covered,
1:12:37sent email is covered, deleted emails
1:12:39also covered. This is called as
1:12:40end-to-end testing.
1:12:42Another example here.
1:12:44So, let's say I have a simple banking
1:12:45application. So, I want to cover and I
1:12:48want to do end-to-end testing. Means, I
1:12:49want to touch each and every
1:12:51functionality in one flow.
1:12:53So, I say first login
1:12:55and add customer.
1:12:57And these are the different components
1:12:58also we can test individually. But, what
1:13:00is end-to-end testing means which should
1:13:02cover every flow in your application.
1:13:04That means I say login to application.
1:13:07Then I'll try to add a new customer.
1:13:09Then I'll try to delete the customer or
1:13:11edit the customer. Then I log out from
1:13:13application. So, this will cover
1:13:15how many? 1 2 3 4 5 scenarios
1:13:18into one test. So, this is called
1:13:20end-to-end test from login to logout.
1:13:23What are all there in between
1:13:24functionalities? We are covering each
1:13:26and every functionality sequentially
1:13:28which is called as end-to-end testing.
1:13:30So, whenever anyone ask you to perform
1:13:33end-to-end testing means you have to
1:13:34make sure each and every functionality
1:13:36or major functionalities will be covered
1:13:38as part of the test case.
1:13:41That is called end-to-end testing. So,
1:13:43testing the overall functionalities of
1:13:45the system or application which includes
1:13:47the data integration among the modules
1:13:50is called end-to-end testing. So, after
1:13:52successful login I can do add customer.
1:13:54After adding the customer, I can delete
1:13:56the customer or I can edit the customer.
1:13:58Dependent functionalities are there.
1:14:00And then I can log out from the
1:14:01application.
1:14:02So, this is called end-to-end testing.
1:14:04So, end-to-end testing means what?
1:14:06Testing the overall functionality which
1:14:08includes each and every component in
1:14:10your application.
1:14:12So, that is all about end-to-end
1:14:13testing.
1:14:15Fine? So, now globalization and
1:14:19localization testing. Globalization and
1:14:22localization testing.
1:14:24And sometimes if you see some
1:14:26application will support globally.
1:14:29Means all different languages. And some
1:14:32application will support specific
1:14:33language, local applications.
1:14:36So, example
1:14:38uh suppose let us say
1:14:40PayPal. So, PayPal is an application
1:14:43which is online payment system.
1:14:45Which is there in almost every country
1:14:47throughout the world.
1:14:49Right? So, it support globally. So, all
1:14:52different cultures, all different
1:14:54countries, all different languages.
1:14:56So, some applications
1:14:59support
1:15:00uh globalization concept and support
1:15:02localization. So, globalization is what?
1:15:05Whether our application is supporting
1:15:07globally or not.
1:15:09All the languages or not.
1:15:12That is globalization testing.
1:15:14Localization testing means what? Our
1:15:15application is supporting the local
1:15:17languages or not.
1:15:19That is localization testing. For
1:15:20example,
1:15:22if I take any Chinese related website.
1:15:25So, Chinese Chinese is a country. All
1:15:28their websites are there in Chinese
1:15:30language.
1:15:32But, nobody can understand those website
1:15:34from the world. Only those country
1:15:36specific people can understand. And
1:15:38those country specific people can use
1:15:40those applications. Even other countries
1:15:42also cannot access those applications.
1:15:45In those applications, we can conduct
1:15:47localization testing. Whether our
1:15:49applications are supporting their own
1:15:52local languages or not. Their own local
1:15:54format. Suppose date will be
1:15:57The date format will be different from
1:15:58one country to another country.
1:16:01And if the application support all kinds
1:16:03of formats,
1:16:04that is a globalization. Or if
1:16:06application support a specific format of
1:16:08date, that is related to specific
1:16:11region or specific geographical country
1:16:13or specific culture.
1:16:15That is localization.
1:16:17So, overall
1:16:18the globalization testing in the sense
1:16:21testing our application which is
1:16:22supporting globally or not.
1:16:26And localization testing means we verify
1:16:28our application is supporting the local
1:16:30community or local languages or not.
1:16:34That is called localization localization
1:16:36testing. Again, this is again part of
1:16:37the requirement. Now, let us understand
1:16:40the points. The globalization testing
1:16:42performed to ensure the system or
1:16:45software application can run in any
1:16:48cultural or local environment. It also
1:16:51includes local. Okay? Global means what?
1:16:54Whole whole world. Local is not which is
1:16:56a part of the global. So,
1:16:59perform to ensure the system or software
1:17:01application can run in any culture or
1:17:03local environment.
1:17:05Different aspects of the software
1:17:06application are tested to ensure that it
1:17:10supports every language and different
1:17:12attributes.
1:17:14See, means global means it should able
1:17:15to support all kinds of languages.
1:17:18In different countries,
1:17:19they can use application in different
1:17:21language.
1:17:22Okay? So, that is a globalization
1:17:24support.
1:17:25And it test the different currency
1:17:27formats. So, currencies will be
1:17:28different. Mobile number formats will be
1:17:30different. Address formats will be
1:17:33different.
1:17:34So, if your application support all
1:17:36kinds of currency formats, all kinds of
1:17:38mobile numbers, all formats, all
1:17:40addresses,
1:17:41then we can conduct globalization
1:17:42testing.
1:17:44Basically, we are checking which is
1:17:45supporting all globally
1:17:47common attributes or not. So, that is
1:17:50globalization testing. For example,
1:17:52facebook.com it support multiple
1:17:54languages. In your Facebook, you can do
1:17:57the posting your local languages and
1:17:59global languages also.
1:18:01That is one example.
1:18:02And localization testing. Perform to
1:18:05check system or software application for
1:18:06specific geographical and cultural
1:18:08location. In specific country, if they
1:18:11are using that application,
1:18:12that support localization.
1:18:14Suppose the language, date formats,
1:18:17okay? And mobile number formats, address
1:18:19formats will be there in the localized
1:18:21support. And in which format they are
1:18:23exactly following in their environment,
1:18:25so all that application will support
1:18:27only that format. So, we are going to
1:18:28test them. That is called localization
1:18:30testing. So, localized product only
1:18:32support the specific kind of language
1:18:34and it is usable only in the specific
1:18:36region.
1:18:38And it test the specific currency
1:18:39format, mobile number format, address
1:18:42format is working properly or not.
1:18:44So, here baidu.com this is basically
1:18:47like a Google application in China. So,
1:18:49in China people they don't use any
1:18:51global applications. They will design
1:18:53their own applications. Even Windows
1:18:55also they have design in Chinese
1:18:57language.
1:18:58Okay? So, google.com, facebook.com,
1:19:00online payment applications, online
1:19:02e-commerce applications, everything they
1:19:04will design their own language for their
1:19:06country, not for the world.
1:19:08So, almost all their applications are
1:19:11supporting localization.
1:19:13Okay? If there is another if you have
1:19:15such type of applications, you have to
1:19:17conduct localization testing.
1:19:19And our in our application the date
1:19:21formats are related to their local
1:19:23region or not, standard or not, mobile
1:19:25number.
1:19:26So, these things we have to focus while
1:19:28performing the globalization and
1:19:30localization testing.
1:19:33Okay?
1:19:34And now,
1:19:35that's it, guys. So, these are all
1:19:37uh different testing terminologies. And
1:19:39from the next session, we are going to
1:19:41see uh different testing techniques. So,
1:19:44what we have covered in the today's
1:19:45session is
1:19:46what is regression testing,
1:19:48what is retesting, and what are the
1:19:50differences between regression testing
1:19:52and retesting.
1:19:54Right? And then, we have discussed about
1:19:57smoke testing and sanity testing. Also,
1:19:58we have compared
1:20:00exploratory testing, ad hoc and monkey
1:20:02testing also we have discussed
1:20:04individually and also have compared.
1:20:07Then, positive testing and negative
1:20:09testing.
1:20:10And finally, we discussed end-to-end
1:20:12testing. And then,
1:20:15localized testing,
1:20:18localization
1:20:21and internet globalization also called
1:20:24as internationalization, okay?
1:20:26Globalization or
1:20:28internationalization
1:20:30testing.
1:20:32So, this is also called as I18N testing,
1:20:35guys, okay? I18N
1:20:38in means I means internationalization.
1:20:41So, after I, there are exactly 18
1:20:44characters are there.
1:20:45So, in shortcut, we can say it is I18N
1:20:48testing. So, whenever you see this kind
1:20:50of term, you can understand this is
1:20:52internationalization testing, also
1:20:54called as globalization testing.
1:20:57Okay? So, these are the different
1:20:59terminologies which we need to
1:21:00understand in testing. Very, very
1:21:03important.
1:21:05Okay? So, I'll stop here for today's
1:21:07session. And then, in the next session,
1:21:09we will discuss about test design
1:21:11technique and other other topics. Okay?
1:21:14Yeah.

About this transcript

This page contains the full transcript of Manual Software Testing Training Part-5 by SDET- QA, generated from the public captions YouTube serves with the video. The transcript has 12,959 words across 2,318 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.