YT YouTube2Text

YouTube2Text → Transcripts → Manual Software Testing Training Part-3

Manual Software Testing Training Part-3 — Transcript

by SDET- QA · 13,661 words · 822 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00so before starting uh today's session let's recap what we have seen till today till yesterday so in
0:07the previous session uh we have seen v model especially v model right so in the v model
0:12we have discussed about what is verification and validation and also we have discussed about static
0:17testing and dynamic testing so when i talk about static and dynamic testing so the basically static
0:24testing means we can verify the documentation like requirement documentation design documentation
0:31low level design high level design so to review the documentation which is basically comes under
0:36static testing so our testing is mainly focusing on the documentation part like project related
0:42documents and dynamic testing is mainly focusing on the software so we are going to validate the
0:49software directly by providing different inputs and observing outputs whether it is working
0:54according to customer requirement or not so that is comes under the dynamic testing and similarly
1:00verification and validation so verification means what whatever the process we are following we are
1:06cross checking each and every step so whether we are following process correctly or not and
1:11verification techniques also we have discussed like reviews walkthroughs and inspections
1:16and today we are going to discuss in detail and validation means verifying the software
1:20testing the software according to customer requirement which is comes under verification
1:25and unit testing integration testing system testing and uit testing so these are the
1:31techniques we have to use during validation okay these are validation techniques and under
1:36verification we have a reviews walkthroughs and inspection so these are the concepts we have
1:40discussed in the in our previous session okay now today we are going to focus on uh review
1:48walkthrough and inspection so even white box and black box testing methods so what is white box and
1:53black box testing yesterday also we have discussed white box means we have to test the internal logic
1:59of the program so normally what developers will do is the developers write a programs to develop
2:04the software and to test the code directly which is basically comes under white box testing white
2:11box means what what is there internally we can see that that is white box testing
2:16and only developers can do that and black box testing means what we can verify the functionality
2:22of the test functionality of the application or functionality of the software whether it is
2:27working according to customer requirement or not so basically in the black boss testing we
2:31don't need to know the programming because we don't we don't need to know the internal
2:36logic of the program we have to just know the how functionality is working right how the flows are
2:41working how the ui is there so all these things we will focus during black boss testing so we don't
2:47need to know the internal logic of the program so testers actually will do black box testing okay so
2:53these are the two things we have discussed in our previous session and now come to today's session
3:01review walk through and inspection so yesterday itself i have talked about static and dynamic
3:07testing so what are the static testing techniques let me write here static testing techniques
3:15i told you three different techniques static tech static testing techniques there are three
3:22techniques we have one is review is one of the technique review and the second technique is
3:30walkthrough and the third technique is inspection so these are the three techniques we use during
3:36static testing means verifying the documentation and similarly we have a dynamic testing techniques
3:43dynamic testing techniques so what are the dynamic testing techniques
3:48dynamic testing means we are actually testing the software so unit testing integration testing and
3:56system testing integration testing and we have a system testing and then we have uit testing
4:05user accept and testing so these are the dynamic testing techniques so we will discuss this dynamic
4:10testing technique later so starting testing techniques or reviews walkthrough and inspection
4:16so what exactly review walkthrough inspection means so let us discuss in detail so what is
4:22review so what is review suppose when i provide you some document i ask you to review the document
4:29what you will do normally so when i give some document to you i ask you to review the document
4:35so normally what you will do is you will read the entire document right so you will re-enter
4:40the document whether it is completely or not it is completely written or not all the contents
4:46are mentioned in the document or not that is one thing second thing is what whatever the content is
4:51specified in the document which is correct or not so these two things are comes under review part
4:58so what is review means review is conducting on the documents review conducts on the documents
5:04to ensure correctness and completeness so that whatever the content we specified in the document
5:10should be correct and it should be complete so that is basically comes under the review
5:15but what kind of reviews we do different type of reviews we can do so different type of reviews
5:21will do so normally we will do requirements review so there are multiple reviews we have
5:26let me just put it here so requirements review what is requirement review means as soon as we
5:32got the requirement from the customer we will review them so to understand those requirements
5:37better we will review them each and requirement is mentioned or not it is correct or not so we can
5:42review that and design reviews and these design reviews will be conducted on the design documents
5:48normally the designs will design the low level documents high level documents like actually
5:54software will be designed in the form of diagrams and pictures and those design documents we will
5:59review and code review so even sometimes code also we can review so whatever the developer has
6:04written the code that also can be reviewed but not by the testers even developers itself because unit
6:10testing can be done by the developers so whatever code they have written in the programs they can
6:16also review the code whether all code is correctly written syntactically is correct or not logically
6:22correct or not so they will verify that that is called code review and sometimes one developer
6:28will return some code and another developer will review the code how it is written and whether he
6:32followed proper coding standards or not so that can be reviewed that is called as a code review
6:38and the second next thing is a test plan review so even testing part even testing testers also will
6:44do some kind of reviews so whatever documents they created and those documents also will be reviewed
6:50by the testers like test plan review test cases review sometimes even defects also we can review
6:56like how many defects we have raised how many are fixed how many are still open so we can also
7:00review the defects so these are all comes under the review so normally we are mainly focusing
7:06on the documentation whether it is correct or to ensure the correctness and completeness whether
7:13the document is correctly written and whatever the content is mentioned which is complete or not
7:18so that is mainly called as a review okay and review can be done anyone so in the team even
7:25developer or tester or manager so anybody can do the review part so that is all about the
7:31simple review concept and the next technique is a walkthrough sometimes we also do some
7:37walkthrough and this is also mainly focused on the documents now we'll see what is walkthrough
7:45so what is walk so walk review can be done anytime from by anybody by anyone
7:53okay there is no restriction nothing but when you come to the walkthrough it is a basically informal
7:59review this is also kind of a review which is informal means what we don't have a specific plan
8:05and we don't have a specific meeting invite nothing and whenever you want to lose you can
8:10do walk through walk through it is a kind of a review informal review we can say so let me just
8:16put few points here regarding the walkthrough the first point it is informal review what is
8:22formal review what is informal review informal review means there will not be any proper plan
8:29there will not be any schedule that is comes under informal okay formal means what we have
8:36to some we have to be some plan before itself and we have to send invite to the team and we
8:41have to invite all the team members at particular point of time so that is purely formal but here
8:48walkthrough is an informal review means what we can conduct walkthrough at any time at any place
8:55other reads the document or code and discuss with the peer so who is other here means
9:01whoever created the document so whoever created the document is called as a other so he will
9:08be involved mainly he is a main person in the walkthrough so he will go through the document
9:14each and every statement or step he will read the entire document or whatever code they have written
9:19they can read the code and discuss with the rest of the people suppose i have created one document
9:26and i am the author of the document i just go through each and every step and i'll explain to
9:31you what exactly which contains that is basically called as a walkthrough the review is a different
9:37walkthrough is different review can be done by many people and even one single person also can
9:42do review but walkthrough means at least two or three people will be there two or more people
9:48will play at least one other should be there and he read the document and requirement and others
9:54can also listen what he is saying exactly what he is trying to understand the document
9:59that is called walkthrough and it's not a pre-planned and can be done whenever
10:06is required that's the reason we say this is an informal review which is not planned
10:10as and when we require we can walk through the document with the team members normally other
10:16is created you can sit together with the team and walk through the document so for example uh
10:22you have created some test plan you have created some test cases you have written some test cases
10:27and you have to review first yourself okay review comes first whatever document you created yourself
10:33first you review yourself whether you mentioned everything you are not correct or not
10:38and the next step what you will do you will review the document with your team members
10:43okay that is comes under walk through team members in the sense not everybody with the peers just one
10:50or two persons sit together and you go through the document and rest of the people will listen
10:56what you are exactly trying to understand them so that is basically walk through so it is not
11:01pre-planned and also walkthrough doesn't have any minutes of meeting so normally when you conduct
11:07any meetings in the company we will note down all the points okay we will note down what we
11:13have discussed in the meeting and we'll produce those points to the team will share all the
11:17meeting options to the team and here we don't have such type of things because this is a informal if
11:22it is a completely formal meeting then everything will be there but it is informal okay and what is
11:29the basic difference between review and want to in the review only other will be there okay weber
11:36is required to understand the document he will read the document and checks the correctness and
11:41completeness only single person also can do review but when you come to the walkthrough at least two
11:47or more people will be involved it appears very number very minimal number of people
11:51only the team members only peers peers is nothing but the person who are working with you
11:56along with you in your team so you go through the document and read the document rest of the people
12:02can understand the document understand the content in the document so it is not
12:06pre-planned and also doesn't have any meanings of me because it is an informal review okay that is a
12:13walkthrough and the next one is the inspection and this is another important thing inspection this is
12:22another technique we do in the static testing inspection so what is inspection means what
12:27inspection is more formal okay more formal means we have to pre-planned so we have to pre-planned
12:36and we have to send invite to the team members not only testing so sometimes even developers
12:41managers also it's more mostly it is informal review we have to send an email to the team we
12:47have to invite them on particular time and what you will do inspection in inspection actually
12:53there are three kinds of people will be involved okay so in inspection there are three people are
13:00involved so one type of people called as a reader writer and moderator so the three kinds of people
13:11will be involved in the inspection reader writer moderator just a moment
13:24all right so in inspection especially three kinds of people will be involved reader writer and
13:29moderator so let us understand these three role very important so who is reader who is writer who
13:34is moderator so the reader means normally he is the author of the document so whoever is created
13:41the document which is called as a reader and he will read the document and writer so writer is
13:48nothing but suppose while reading the document by the other rest of the team will raise some
13:53questions or clarifications right and the writer will note down all the questions and clarification
14:00what they have discussed in that particular inspection meeting so that role is taken by one
14:06guy is called a writer you will note down all the clarifications and issues everything and the third
14:12one is a moderator is just like a anger moderator means he is like a mediator between the other
14:19and rest of the team okay so reader writer and moderator moderator means he's actually organizer
14:26meeting he's a basic organizer okay and reader writer and moderator so these are three people
14:34will sit together and then do the inspection so it is a more formal review and reader will read the
14:41document and writer will write the write down all the issues and clarifications rised by the team
14:48and the moderator he moderate the meeting he organized a meeting okay and here many number of
14:55people will be involved other than right reader writer moderator rest of the people also will
15:00be involved whoever is working on the team like development and qa project managers everybody will
15:05be involved in this because this is more formal everybody should be there and inspection will
15:11have a proper schedule which will be intimated via email to the consent developers or testers
15:19because this is more formal meeting and before that we have to plan and we have to send an
15:25email to the team and we have to invite them on particular time and also we have to note down
15:31the mean minutes of meeting and we do that even writer or sometimes in moderator so these people
15:39will write down the minutes of meeting and share with the team so this is called as inspection
15:45so the static testing is nothing but testing the documentation whether which is correctly
15:51written or not and static testing can be done by using either review or walkthrough or inspection
16:01and inspection is more formal whereas review and walkthrough or informal because you can conduct
16:08them at any time at anywhere but inspection is more formal it is just like a meeting
16:15okay so these are the static testing techniques guys so review walkthrough and inspection now
16:22come to the dynamic testing techniques there are four kinds of techniques we have like unit testing
16:28integration testing system testing uit testing because here by the time we start dynamic testing
16:35software will be ready coding part will be done so we have to test the software directly so during
16:41unit testing the developers will concentrate on testing the code what they have written and during
16:47integration testing they will integrate multiple modules and multiple components in the software
16:53and they will check the data flow between the components whether those components
16:58properly communicate or not that is integration testing and in system testing actual testers will
17:04perform system testing whether our software is working according to customer requirement or not
17:10it is meeting all the requirements or not the functions is working perf perfectly or
17:14not performance is good or not security testing ui testing the lot of testings will be conducted
17:21during system testing normally the testers will be doing this testing and finally uat testing
17:27user acceptance testing normally the uat will be done by the testers along with the customers
17:33and they will set up the exact environment where the customer is going to work and they install
17:39the software and from the customer point of view they will test the some flows like what they do
17:46day to day basis on the software what are the transactions that they do they will test them and
17:51they also execute some of the test cases on the software that comes under the uat testing okay so
17:56we will discuss these in detail later so basically these are the techniques which we have to use in
18:03dynamic testing so static testing will mainly focus on the documentation project documentation
18:10dynamic testing mainly focusing on the software which we have developed actual software we are
18:15going to verify or validate okay right so the next thing is we have seen review walkthrough and
18:24inspection now in the software industry especially software testing we hear these steps qa qc and
18:35qa so now we need to understand them what exactly qa means what is exactly qc means and qa means
18:41okay very very important so first let us compare qa and qc okay and then
18:49i'll tell you what exactly qa means so this term is recently started qa means quality assurance qc
18:56means quality control qe means quality engineering okay a small difference i'll tell you first let us
19:02compare qa and qc then we'll come back to the qe okay these terms are very important especially in
19:10the software industry so let us start what is qa and qc let me put some points here qa versus qc
19:25okay so qa versus qc so the first point is qa is a process related qc is actual testing of
19:37the software let's try to understand this qa is process related qc is actual testing of the
19:44software qa is a process related so what is process related means if there is a company
19:52there will be three important things there will be three pillars one is people second one is
19:59process the third one is product so these are the three p's p means uh first people should be there
20:07if there is a company people should be there and we have to follow certain process and finally what
20:15you will get you will get the product product in a sense a software or an application so
20:20these three piece are the pillars of the company any company it is a not only i.t company it is
20:24can be any type of company these are the three p's we can call them as a pillars of a company
20:30the first p representing the people people should be there and the process should follow and finally
20:37the people follow the process to produce the equality product that's the end goal right
20:44so here qa means it is a process related this is a process qa is related to the process means the qa
20:54the people who are belongs to the qa will always define the process and talk about the process
21:02and also they ensure rest of the people are profiling proper uh for process properly so that
21:09is the responsibility of the qa so qa is a process related okay and they will define the process okay
21:17they will define the process means what high level management people will comes under the queueing
21:22which is talking about entire process development cycle from the beginning from the requirement to
21:27till we release the product to the customer so the entire process is designed by these people
21:35and also these people are make sure rest of the people are following the process properly or not
21:42okay like high level management people comes under the keyway if i say normally qa is process related
21:49this is the first point and qc is actual testing of the software so yesterday we have seen a few
21:56step size after development process what is that requirement requirement analysis okay this is a uh
22:06first step and the second step is a design part and then we have seen coding part and then testing
22:13right and then deployment and then maintenance so these are the different
22:17phases we have seen in sdlc process this is stlc process software development lifecycle
22:23so here qa involved in every stage of software development because they are taking care of
22:30the process so what process we have to follow how people are following the process will be
22:37observed by the qa because high level management people comes under qa and this is involved
22:43throughout the development process remember this is involved throughout the development process
22:49but the qa is actually testing the software and the qa qcq is actually testing the software and
22:57they are involved only during testing part okay so people who are working under testing they are
23:03actually comes under qc that actually comes under q's equality control the those people actually
23:10test the software whether it is working according to customer requirement or not okay that is a
23:15first point guys so qc is actually talking about the people especially testers especially testers
23:25okay and the qa is a process related they will define the process and make sure others also
23:31following the process correctly or not that is qa qct means what they are actual testers they
23:37are verifying and validating the software whether it is working according to customer requirement or
23:42not that is the first point next one the second point is qa qa focuses on building in quality
23:54qc focuses on testing for quality so observe this carefully i said qa is a process related
24:02why we need to have process why we need to have process finally we have to deliver the quality
24:08product so to deliver the quality product to the customer we have to follow certain process and why
24:14process we are following means the ultimate goal is to produce the quality product to the customer
24:19right and here we are also thinking about the quality of the software for that the process is
24:25designed so qa focuses on building in quality we are trying to build the quality product okay and
24:34this is related to that so process is designed for building the quality called the product
24:40and qc is for testers i said so qc focuses on testing for quality what qc people will do testing
24:48why we are going to why we are doing testing because to deliver the quality product to the
24:53customer and both are talking about the quality but a small difference between these two are it
24:59is for building the quality it is for testing for quality okay building for quality in the sense
25:07to follow certain process properly finally we are able to deliver the quality product to the
25:12customer for that process is designed and what is why we are going to conduct testing because
25:18if the software is having bugs or not we have to find some bugs because we also trying to
25:23produce a quality product to the customer so testing for quality so qa focuses on
25:29building inequality qc focuses on testing for quality and again qcqa is related to people
25:36and process and qc is related to the testing testing people all right the next point is
25:45qcqa is for preventing the defects qc is detecting the defects understand the
25:53difference qa is for preventing the defects qc is for detecting the defects so what is prevention
26:01so qa is talking about the process if you if you follow the process correctly
26:08or perfectly we can prevent the defects in the future right if i follow process correctly
26:15we can prevent the defects in the future so that is a prevention activity whereas qc
26:22is detecting the defects because which is related to the testing what you will do in the testing we
26:27will find the defects and why qc is there why testers are there to detect the defects
26:32as many as bugs we have in our application we have to find out that is called detection
26:37prevention means what we have to make sure in future should not any bugs or defects should
26:42not come in future that is a prevention detection means what the box will be there we are trying to
26:48find out that is a detection so q a is for qa is for preventing the defects and that's the reason
26:55they define the process and also they make sure people are following prop process correctly or not
27:01but qc is for detecting the defects while testing the software we are going to detect
27:07the defects find the defects and report to the developer because that is a testing activity okay
27:14there is a one difference and next one is as i said before huge a is a process oriented it
27:20will always focus on the process always talk about process process process and that's the
27:27reason which is involved in everywhere that means throughout the development process
27:33qa is involved it is talk about the requirement talk about the design coding testing diploma
27:38everywhere qa will take care about so because the management managers product managers project
27:45managers they are comes to the queue actually so they are taking care of everything so they
27:50are involved throughout the development process but qc is a product oriented what is product
27:57oriented means testing during testing we are mainly focusing on the quality of the product
28:03our main goal is to produce a quality software to the customer or quality product to the customer
28:09so our our main goal our main intention should be on product not about the process we follow
28:15certain process but if that that is not our job to define the process and everything that is a
28:21qa but qc means what we are product oriented our concentration is always on the product quality
28:29finding bugs so this is the actual area we are going to focus which is product so qa is a process
28:36oriented you see is a product oriented okay and uh the last point is as i said qa is for entire
28:49software development lifecycle whereas qc is for testing part in sdlc so when i say sdlc these are
28:56the different phases requirement analysis design coding testing deployment and maintenance so qc
29:05qa for entire live cycles so as i said before qa is involved in every phase
29:10whereas qc is involved in the testing phase people are working on the testing department we can call
29:15them as a qc actually we have to say qc them but people are normally calling qa people but actual
29:22term is a qc they are comes under the qc because they are the people actually testing the software
29:27and concentrating on the product and the qa means a process people who are defined the process comes
29:34under the keyway and that's the reason this is there for entire life cycle whereas the qa is
29:40there only in the testing part which is a one part of entire q a we can say q c is a subset of q a
29:47is nothing but an entire process q c is nothing but which is a one part in the q a which is
29:52testing okay so these are the two differences between these are the few differences between
29:58qa and qc remember guys so qa is a process related whereas the qa is actual testing of the software
30:07qa focuses on building in quality they are always trying to build the quality
30:12product and the qc is always focusing on the testing the quality testing for the quality
30:18and qa is preventing activity qc is a detecting activity and qes is a process oriented qc is a
30:25product oriented qa is for entire life cycle qc is for testing part of sdlc okay so these are the
30:34few differences which we need to understand between qa and qc very very important question
30:40in interview okay so i hope you guys are clear can you please confirm the chart window everyone
30:47so now i will discuss about the qe quality engineering
30:54so the next one is a quality engineering so recently these terms got started guys q e along
31:02with the qa called assurance and quality control there is one more term called as a qe what is qe
31:10qe means quality engineering engineering so this is a little advanced term guys
31:20okay this is advanced term then qc okay after qc qe will come so normally
31:28uh people like people are belongs to qc like testers they do normally manual testing right
31:34and they also do some automation testing testers in the nothing but we can have manual testers and
31:38automation tester or belongs to qc but what is qa means uber is doing automation testing normally
31:46they will write a code okay they will write the code for testing the software actually those
31:52people are comes under quality engineering okay simple guys so we have software engineer we have a
31:59software engineer term right software engineer we can say yes e similarly quality engineer quality
32:10engineer quality engineer i say qe what is basic difference why you are calling engineer here
32:17the reason is the reason is when i say developer software engineer what they have to do what they
32:24have to do now what they do normally they will write the code to develop the software so they
32:30will write the code by using programming language they will write the code to develop the software
32:35the main focus on development but what quality engineer will do they also write the code for
32:42testing the software so quality engineer means automation tester they also write the code
32:48for testing purpose to test the software so both are writing the code right so we can call
32:54them as a quality engineering so who is writing the code for development we can call them as a
33:00software engineer ses and whoever is writing the code for testing the software comes under quality
33:07engineer we can call them as a quality engineer so qe is a team which contains the automation testers
33:14who are involved in the writing the code also okay that is the new 10 people are nowadays
33:19using in the companies and whenever you see some kiwi requirement don't confuse by seeing
33:23that sometimes you can see qa or qc or qe so all these terms are related to testing only
33:30and especially when i ask a qe and this particular role is related to automation testers
33:36okay that's the only difference between qa and qa qc and qe okay mainly we have to understand
33:42the difference between qa and qc but the qe also mostly related to qc itself the only difference is
33:50in the qe people are also writing the code to test the software and there also comes under qc okay
33:57so understand these differences uh very important okay that's it so qa qc and qe now let us move on
34:08to the next topic levels of software testing levels what are the different levels we will
34:14conduct software testing so yesterday when i talked about v-modal what is the first
34:20level of testing we do what is the first level of testing we do unit testing after
34:25completion of the software okay let me write here so levels of testing
34:36let me write so levels of
34:42testing so what is level means step by step after one testing the next level testing or next level
34:47testing so these are the four levels of testing and these are the techniques which we have to use
34:56for dynamic testing right unit testing integration testing system testing uit testing we can call
35:02them as a user acceptance testing user acceptance testing so let us try to understand this
35:10these are the different levels one after another first we conduct unit testing then we go to
35:16integration testing then we go to system testing then we go to user acceptance testing these are
35:22the different levels okay let us try to understand clearly very very important just understand this
35:30so uni testing so what you will do in the unit testing we are just going to test the uh some
35:37component a small module in the application so that is normally done by the developers at the
35:42code level whatever the code some program a small program they have written for some requirement
35:48they will test that program a small piece of code will be tested that is comes under unit testing
35:54what is unit means unit means a small component is called as a unit which is unit testing
36:00integration testing means what while coming while combining multiple units or multiple
36:05modules as a single unit then we will check the data flow or communication between those modules
36:12which is called integration testing and system testing means what we are testing the overall
36:17functionality of the application whether it is working according to customer requirement or not
36:22each and every requirement is mentioned in the software are working or not we are going to test
36:27that is system testing uit testing means what at the last level after completion of system testing
36:34testers along with the users will conduct user acceptance testing okay these are the different
36:40levels we cannot directly jump into system testing we cannot directly jump into integration testing
36:45so once you completed unit testing then we go for inter integration then we go
36:49for system then we go for uh uit testing so these are the different levels of testing
36:55now i will discuss in detail one by one so we need to understand them very very
37:00clearly so the first testing is unit testing this is the first level as soon as a coding is started
37:08the developers will conduct the unit testing in their environment okay we are not bothered about
37:14the unit testing and also developer will care because this is comes under white box testing
37:18technique integration and unit testing comes under white box testing techniques remember that
37:25so let me just uh write a few important points related to unit testing okay so let us understand
37:33what is a unit a unit is a single component or a module of a software so when i take a software
37:42which is a big software and which contains n number of features lot of functionalities lot of
37:49and each and every feature which we can call it as a component for example if i take a
37:55big application a gmail application in the gmail application suppose when i take a login
38:02that's the first entry right a login that is one component
38:05so after successful login composing email that is one component we can say one is that is one module
38:12and after composing the email the mail comes to the send box and send box is one module
38:18and after deleting the email that comes under the deleted emails and deleting emails is one
38:23module so the entire software or application will be divided into multiple units which we
38:29can call them as a components or modules so if i conduct testing on that particular unit or module
38:38or component which is comes under unit testing okay and normally developers write a simple
38:45programs for them and conducting the testing at the code level that comes under the unit testing
38:52but sometimes we get the ui also in the tester point of view we will test the ui suppose i
38:57have a simple login screen and for login the developer writes some code internally so developer
39:04will conduct the testing on that particular code in that context we can call as a unit testing
39:10and after providing the ui ui means what screen after providing the ui
39:16to the tester we don't bother about the code we are going to test the application
39:21we are passing the valid username valid password and we are checking such a login is successful or
39:26not like invalid username invalid password login is restricting or not we are going to test that
39:31in that context we can call it as a component testing we don't use a unit testing term in
39:38case of testing or testers we use a component testing because we are testing the ui part there
39:44but in the developer point of view whatever program they have written inside the ui if
39:49you conduct the testing on that particular code or program that comes under the unit testing almost
39:55same okay but the way of testing is different so unit is a single component or module of a software
40:04unit testing is conduct on the single program or single module because the entire software is
40:09divided into multiple pieces or multiple modules or multiple programs and unit testing is a white
40:17box testing technique why we are calling it is a white box testing technique because we have
40:22to know the internal logic of the program so what developer is written so that's the reason whoever
40:28is writing the code they are the responsible for conducting the testing so unit testing is
40:33a white box testing technique unit testing is conducted by conducted by the developers
40:39because they are the people written the code and they use certain techniques okay to conduct
40:45the unit testing they use certain techniques what are the techniques basis path testing
40:50control structure testing under this control conditional coverage loops coverage comes under
40:57control structure testing and mutation testing these are the different techniques they use
41:02during unit testing okay like basis path testing means what for example let us try to understand
41:08very high level not much important because these are the techniques we used by the developers
41:14at the code level so let's try to understand with very high level what is basis path testing
41:19means suppose we have created some program developer has written some program like this
41:25and which is having multiple lines okay and when i test this program each and every
41:32line should be covered while executing the program while providing the input to the program each and
41:38every line of the program should be executed at least once at least once so that comes under the
41:45basis path testing every path in your program should be executed at least once that comes on
41:51the basis path testing similarly control structure testing under this we have a conditional coverage
41:58loops coverage and in normally the programming we have if condition if else condition switch
42:03case condition so we will verify those conditions are working properly in all the cases like we pass
42:09negative condition we pass positive condition so simple for example i want to find out like largest
42:17of two numbers okay largest of two numbers let us say the developer is written code like this
42:22i say a is equal to 10 b is equal to 20 and i'll write one condition if a greater than b
42:29then what so i have to print a is largest is the largest and suppose else else
42:38uh else b is larger so let us say developer has written the code like this simple code i have
42:44written here and in the conditional coverage what developer will test is
42:51verify the conditions suppose if a is greater than b so a is 10 b is 20 so 10
42:58is greater than 20 which is correct or not which is not correct so condition is false so b is the
43:04largest so the output of this program is b is largest because this condition is false suppose
43:09i'll make a values at on twenty and b value is a ten now what happen this condition becomes true
43:15because a value is a twenty twenty greater than ten so the condition is true so then it prints
43:21a is the largest so if the condition is true it print a is largest if the condition is false b is
43:26largest only one output you will get either a is largest or b is largest depends on the condition
43:33so in the conditional coverage what developer will do is the developer will verify the condition in
43:39positive input and negative input so previously the condition become false now the condition
43:45becomes true in both the cases we will verify that so that comes under the conditional coverage so
43:52developer normally writes a huge number of programs and n number of conditions will be
43:57you will be there in the program in all the conditions will be verified by providing the
44:02different sets of data okay so that is comes under conditional coverage and the next one we have is
44:08loops coverage so sometimes in the programming if you want to repeat some statements we have
44:14to keep in the looping like loop block and that statement will be repeated multiple times
44:21okay so for example let me write a simple example do not worry if you are not understood this code
44:25okay it is a very basic code i have written to just demonstrate what is conditional coverage
44:31now i will tell you loops coverage what is loops coverage let us say developer has written some
44:37codes or suppose my program is let us say i want to print one two five five numbers
44:44i want to print one to five numbers through program and developer has written some code
44:49like this so how developer is written developer is taken a small number let us say initial number
44:54is 1 starting from 1 and what is the maximum number maximum number is maximum number is 5 and
45:01between 1 to 5 i want to print all the numbers so normally we can write there is a print one
45:08okay and you can say print 2.3 we can just write multiple statements like this that's a print two
45:15so let's say multiple statement i can add one two three and four and five so when i say
45:23if i want to print one to find numbers i can write number of print statements
45:27but instead of writing this suppose i want to print hundred then we have to write hundred pin
45:33statements so to avoid that the what developer will do is they will write only one statement
45:40and repeat five times same statement will repeat five times instead of writing multiple
45:45times so then what you will do is they will put this statement in the loop means it's a block
45:51which will repeat multiple time based on certain condition okay just observe this don't worry if
45:57you are not understood no issues at all so here i'm writing the one loop statement so here i'm
46:02writing something else while i less than or equal to max okay and then inside the block i'll put
46:10this print statement every time i'm printing the i value not one see this and after printing the
46:17i value i'm incrementing the i value i equal to i plus one just observe this logic don't
46:23worry if you are not understood no issues just understand very high level my requirement here
46:28is i just want to print one two five numbers so initial number is one the maximum number is five
46:35okay so here what exactly i am doing is i put some condition based on the condition if the condition
46:41is true these two statements will execute if the condition is false these two statements
46:47will not be executed it will ignore it so if i say 1 maximum is 5 so 1 less than or equal to
46:55condition is true then what happens here it will print i means 1 it will print the output
47:02then what happens as soon as i printed i value 1 i value is incremented by 1 so i equal to i plus
47:091 means what i value is already 1 1 plus 1 2 now 2 is assigned to the i now currently i value is
47:15a 2 now again it will go up and again check the condition now 2 is the current value of i is 2
47:212 less than or equal to 5 again condition is true now it will come here then it will print 2.
47:28similarly every time it will print i value as soon as it printed i value again it will increment and
47:33again check the condition so like this the same block of statements will execute multiple times so
47:40as soon as i value becomes 6 then condition become false then it will stop printing the numbers
47:46so this is basically called as a loop in programming we can call it as a loop loop
47:51is nothing but a block of statements which we can repeat multiple times based on certain condition
47:57okay and as soon as this condition is false the statements are stopped executing okay
48:04now in the loops coverage what you will test is when i execute this program whether it is
48:11starting from the beginning or not and it is repeating exactly till the maximum number or not
48:19and whether it's printing all the numbers between this range or not okay we are going
48:23to verify and suppose when i say 6 here so 6 numbers should print when i say 10 here it
48:29should print 10 numbers okay so like this we will verify the loops that comes on the loops coverage
48:37okay this is purely related to programming okay so that's the reason which is comes under unit
48:42testing which is a white box testing technique so to conduct this type of testing we have to know
48:47the programming and the last one is a mutation testing so mutation is nothing but a repetition
48:53suppose uh some programs if you want to test we have to provide different type of inputs
48:58okay suppose a developer is written some program like this like checking the user and password
49:04let's say if user equal to let's say scott and password password is equal to let's say one two
49:15three then i say hello login okay and else if the user is not scored and not password123 then
49:25not hello login so let us say simple code is written by the developer like this now in the
49:31mutation testing what you will do is we will test this code by passing different type of inputs
49:37for example when i provide the username is called and password is one two three then
49:42this condition will be true login will be a lot and else part will be ignored
49:47and suppose when i pass valid user it's got an invalid password instead of one two three
49:53and they pass something else like 235 then else part will execute not allow
49:58the login that is one combination and another combination very username and valid password
50:04valid username and valid uh invalid password like invalid username and valid password
50:10okay so we can just say different combinations and by providing different type of inputs we are
50:15going to test this program whether it is working properly or not that is comes under the mutation
50:21testing mutation is nothing but a repetition testing the code with multiple sets of data
50:27okay so these are all unique testing techniques we can say unit testing techniques and the developers
50:34will use these techniques to conduct unit testing they also use some automation tools
50:39unit tests also can be done through automation they use unit unit or junit testing e so these
50:45are all unique testing tools are available okay developers will take care of this we don't need
50:50to worry about this we don't need to worry about this okay just understand what is unit testing and
50:55we will conduct unit testing and what testing can be done in the unit testing so that is enough okay
51:02so we are mainly involved in the system testing we have to discuss more on the system testing
51:07phase so here this is the area actually we are going to involve more that is our area and rest
51:12of the things we don't need to bother about just we need to understand the definition and process
51:17okay so that is unit testing guys now let us move on to the next level of testing so please focus
51:24guys what i'm saying very very important topics i'm discussing so the next level of testing is
51:32integration testing and do we miss any points here unit testing is a white box testing unit
51:40testing is connected by the developers and these are the different techniques fine so now
51:45let us move on to the next level of testing which is integration testing is integration testing okay
51:56so which very very important integration testing right so very important the next one
52:02is integration testing so what is integration test you will get lot of inter equations also
52:07so please listen carefully so what is integration testing
52:13okay
52:19so let me write few points here so integration testing performed between two or more modules
52:29so what is module we have already discussed what is module model is nothing but a small
52:33functionality or small feature from the software which is called as a model so if i take a gmail
52:39application login is one module composing email is one module and deleting emails is one module
52:47outbox is one module sent emails is one module so different models will be there in your application
52:52similarly if i take a banking application a login is a one model and sending money or
52:58transfer money is one module check balance is one module generating the report is one
53:03module so every software every application is having different modules okay so integration
53:09testing will be conduct or perform between two or more modules if you want to perform integration
53:15testing at least two models will be integrated so after completion of unit testing we do integration
53:22testing so during integration testing we'll conduct the testing between two or more models
53:29and integration testing focuses on checking the data communication between multiple modules
53:36there is one module which will take some input and which will produce some output
53:41and that output is become the input for the next model so it will be like this guys in
53:48integration testing let us say i have one module here let us say a and this module if you want to
53:54test we have to pass some input to this and after passing some input to this model it will give you
54:00some outcome or output that becomes the input for the next model and this is also giving some
54:06output so we are going to test the communication between these two models after combining these two
54:15that is called integration testing integration testing means we are checking the data flow
54:21between the two or multiple models which is comes under integration testing and the next point
54:32integration testing is a white box testing techniques so normally integration testing
54:38can be conducted in two different things guys in the developer point of view if i talk they
54:43will test the code so they will write the code for some write some program for module a they
54:49will write another program for module b and they will integrate these two programs and you will
54:54test the code how the integration is happening this is comes under integration in that context
55:01we can say developers will perform the integration testing at the code level at the code level okay
55:08suppose sometimes the testers also will perform integration testing but how come it is possible
55:15because here let us say i'll give you a simple example then you can understand
55:21let us say something called
55:24so we have something called a gmail application let us take an example then understand a gmail
55:30application okay so in the gmail application what are the different modules we have
55:36we have something called login okay so login is a one module and after successful login
55:45where we can see all our emails in the mailbox so there is something called mailbox this is
55:52another module suppose okay so suppose i deleted some emails from my mailbox
55:59where it goes it goes to deleted email section so there is another module called deleted emails
56:06so deleted email so these are three different modules in my application
56:12okay so in integration testing developer point of view if i talk developer point of view
56:19they will write some code for login they will write some code for mailbox functionality
56:26they will write some code for deleting emails this is just a coding part okay and then
56:34integrate these three models and what developer will do first they execute the first model
56:40and after successful execution it went to mailbox and after deleting the after after building action
56:47the mail comes to the deleted email section so the integration between the programs will be tested
56:55that is integration testing done by the developers
56:59okay that is integration testing done by the developer this is a purely white box testing
57:05now come to the testers for the same login instead of providing the code they will provide us a ui
57:13part we will have a ui like here username field will be there password field then we have to enter
57:20the data then we will get another page gmail page here we will see mailbox here we will see
57:26send items right so on the ui side we also conduct the integration testing how we can do
57:33first we will verify the login by passing valid username and valid password then successfully
57:38log into application then we will check the email box there we will have any emails or
57:44not we will verify after deleting the email that email comes to the send box or not we will verify
57:50so because these are different module but the communication will be there between these two
57:55models how data is communicating between these models we are going to test at the application
58:00level this is also comes under integration testing and in the testing point of view or tester point
58:07of view we also conduct integration testing at the application level and developer point of view
58:13developer also conduct integration tester at the coding level that is the basic difference okay
58:20understood guys what i am explaining here so the same kind of testing the developers will
58:25conduct at the code level whatever the code they have written that is one integration
58:30testing at the tester point of view we do not have this code okay we don't test this code
58:36they will create a ui for that and that ui user interface will be provided to the tester and then
58:43in the testing point of view we are verifying the application functionality so login is module
58:49like mailbox or inbox is one module deleted emails is one module so
58:54we are verifying these functionality in different modules are working fine or not after integration
59:01so this is a integration testing done by the testers at the ui level and if i test the programs
59:09that comes under the integration testing done by the testers oh sorry developers okay so guys
59:16understood this very very important so integration testing means testing the data flow between
59:22multiple modules testing the data flow between multiple modules which is called as integration
59:27testing if i do integration testing at the code level by the developers and sometimes we can do
59:34integration testing at the ui level by the testers okay so that is the concept of integration testing
59:43now in integration testing there are two types of integration testings we have
59:51okay understand side types of integration testing there are two types of integration testing we have
1:00:00so one is incremental integration non-incremental integration listen these concepts guys very
1:00:06very clear incremental integration testing non-incremental integration testing this is also
1:00:16incremental integration testing non-incremental integration testing so first let us try to
1:00:22understand first one incremental integration testing because this is most important
1:00:28most of the times we don't use non-incremental most of the times we use incremental integration
1:00:34testing so let us try to understand what is incremental increase integration testing
1:00:40so this is also integration testing so what is incremental integration testing
1:00:48incremental integration testing means
1:00:53incrementally adding the modules and testing the data flow between the models
1:01:00incrementally adding the modules and testing the data flow between the models what does it mean
1:01:06incrementally adding the modules and testing the data flow between the models
1:01:11simple incremental integration so what you will do is first we will have one module let us say a
1:01:19then we will integrate another module with the a and then we will check the communication between
1:01:24these two models again we will add one more module and then check the communication between
1:01:31the models so we keep on adding a new modules with the existing modules then test the data
1:01:38flow or communication between the modules which is called as incremental integration testing
1:01:45so we keep on in adding the new modules with the existing modules
1:01:49that is called incremental integration model we are don't integrate all the modules at once
1:01:55we are integrating the models one after another which is called as incremental integration testing
1:02:02the first one incrementally adding the models and testing the data flow between the models
1:02:09incrementally adding the modules and testing the data flow between the modules which is called as
1:02:14incremental integration testing there are two kinds of incremental integration again there are
1:02:19two approaches we have so the first approach is top-down approach and bottom-up approach i'm also
1:02:27talking still incremental integration testing okay in the incremental integration testing we have
1:02:32a two approaches top-down approach and bottom-up approach let us see what is top down and bottom-up
1:02:39in the both approaches we will incrementally add multiple modules one after another and test the
1:02:45data flow between the models so let us see what is top down approach what is bottom approach
1:02:52okay so first let us see top down approach so what is stop down top down we can say
1:02:59top down incremental integration testing so this is a terminology so top down approach
1:03:06in incremental integration testing here observe this carefully here
1:03:13incrementally adding the modules and testing the data flow between the models same thing
1:03:20and ensure the model is added is changed of the previous model this is important point ensure the
1:03:28module added is a change of the previous model ensure the model which is added as a channel of
1:03:34the previous model for example let us say i have a model called a okay this is my actual model so
1:03:43when i integrate this model with another module the another module should be the child of the
1:03:49existing module so this should be chilled module and this should be the parent model
1:03:55okay so whatever model we are incrementally adding that should be a chilled module
1:04:02and how we can understand this what is parent model what is change model again let us take
1:04:07the gmail example so in the gmail example we have two models let's say composing email is one model
1:04:16after login is successful we will compose the email after composing and sending the email the
1:04:22same email comes to send items so right if you want to check what are the emails we have sent
1:04:28we can verify in the sent items list right so first which one we will do composing activity
1:04:35so once the compose is done that comes to the send items until unless we compose an email that email
1:04:41cannot come to the sent items so here before sent items first we have to do the compose so this is a
1:04:48parent module this is a change module okay compose is a parent module sent item is a child model
1:04:54so in incremental integration testing in the top down approach in the top down approach
1:05:01we will check the data communication between these two models and make sure the module whichever we
1:05:08have added should be the change of the existing model and tomorrow if you add another module
1:05:14deleted items here we can add deleted items this is another change model further this particular
1:05:20model so whatever module we have added that should be the chilled module of the existing module
1:05:27that is incremental integration testing top down approach okay top down approach okay first
1:05:35top module then another module then another model chilled models or we can say sub models
1:05:43okay that is a top down approach incremental integration testing so incrementally adding
1:05:49the modules and testing the data flow between the models ensure the module added is a chilled of the
1:05:56previous model okay this is a top-down approach so this is an example if i remember this example
1:06:04it is very easy to remember okay first we will compose a mail then only we can get the send items
1:06:10so this is a parent and this is a chain so later if you want to add multiple modules
1:06:15those modules should be the chilled modules of the existing model
1:06:19so this is called incremental integration testing top down approach now come to the next one
1:06:30bottom-up approach okay there is one more approach called bottom-up approach
1:06:38this is also incremental integration the first one but here i'm talking
1:06:42about bottom-up approach what is bottom-up approach in the bottom-up approach this is also
1:06:49same incrementally adding the modules and testing the data flow between the modules same thing but
1:06:58here ensure the module which is added is a parent of the previous model parent of the previous model
1:07:07remember in the top down approach whatever the model we have added that should be the
1:07:12child of the previous model but this time what i am saying to ensure the model which is added
1:07:18is a parent of the previous model parent of the previous model what does it mean
1:07:25parent of the previous or parent of the previous model so for example in the top down
1:07:31approach what we have done we have a parent module and then we have added the chilled
1:07:36child model so this is top down approach in the bottom up approach suppose i have one module a
1:07:45and i can add another module on top of this like this now whatever model we are integrating that
1:07:53should be the parent module of the previous model so for a b is a parent model and then
1:08:00another model okay this is a bottom up approach so first we integrate one parent module will be there
1:08:10and whatever the new models we are adding or integrating that should be the parent model okay
1:08:16now where we have to start the testing now first we'll start testing here then we go here then we
1:08:22go here okay so this is an example so same example you can take same compose email and send items
1:08:30when i say compose email after composing email the email comes to the sent items
1:08:36so let us take this same example in the bot in the top down approach first we composed email
1:08:43and then we verify the sent items because after composing email then only the mail comes into sent
1:08:48items this is top down approach same thing if you want to do bottom-up approach first
1:08:54we go to send emails and we refer the email is present or not if the email is present that will
1:09:01be already composed that is already composed so first we will start testing here we will
1:09:08get this model and then integrate the parent model and combine we will test it we cannot
1:09:13test independent modules guys okay we have to combine and test it because until unless
1:09:18we compose we cannot test the sent items first we integrate the parent model and come do the testing
1:09:24in bottom up in bottom and top down approach we'll integrate the chain module and then test it
1:09:30the ultimate goal is same integration testing but the approach of integration is different
1:09:35top-down approach and bottom-up approach okay top-down approach and bottom-up approach
1:09:42so this is so in the top-down incremental integration incrementally adding the modules and
1:09:49testing the data flow between the models ensure the module added is a child of the previous model
1:09:56same thing we do in incremental integration of bottom up approach
1:10:00here also we incrementally adding the models and testing the data flow between the models
1:10:05ensure the module is added is a parent of the previous model parent of the previous
1:10:11model is this is a previous model if i add another module this becomes a parent of the previous model
1:10:18this is comes under bottom-up approach and there will be another approach interviews people may ask
1:10:25that is called sandwich approach okay sandwich or hybrid approach this is just a combination of top
1:10:33down and bottom up simple okay so combination we use both the combinations combination of
1:10:39top down and bottom approach is called as a sandwich approach so these three approaches
1:10:45comes under integration incremental integration testing incremental integration testing
1:10:54okay we are adding the modules incrementally one after another and test the data flow between the
1:11:01modules the way of adding the modules is different we can add a new models in top down approach
1:11:07or we can follow bottom up approach okay so this is all about the first type of integration testing
1:11:14the next type is non-incremental integration it is very simple stride forward in non-incremental
1:11:21testing we integrate all module at once we integrate all the model in one shot
1:11:29we don't have any integrating multiple models one after another suppose i have a
1:11:3410 models in my application we have to wait to complete all 10 models and combine everything
1:11:40and start testing so simply that is non-incremental integration testing so adding
1:11:47all the modules in one single shot and test the data flow between the model which is
1:11:51called non-incremental but most of the times we don't prefer this option because it has a
1:11:59three drawbacks what are the drawbacks the first drawback is we might miss data flow between some
1:12:06modules suppose if you do incremental integration one two three four there are less number of
1:12:13chances to miss the particular module but here we are integrating all the modules as a single unit
1:12:20so while testing we may miss some model in between there are some chances are there
1:12:26so that is one problem and if you find any defect right it is very difficult to find out the defect
1:12:33is belongs to in which model because we already integrated all the modules at once so it is very
1:12:38very difficult to find out the defect which is belongs to in which module it is very difficult
1:12:44to understand the root cause of the defect so because of these two drawbacks we don't prefer to
1:12:51do non-incremental integration testing guys okay we always do incremental integration testing
1:12:58okay so increment integration testing means what after combining multiple modules we are
1:13:06verifying the data flow between the models comes under integration testing and again there are two
1:13:11kinds of integration testing one is incremental integration testing non-incremental integration
1:13:17testing and again incremental integration can be done in two different approaches
1:13:21top down and bottom up approach and uh and also sandwich approach sandwich approaches
1:13:28also comes under this one the combination of two approaches and non-incremental integration testing
1:13:34we are not going to increment any models we are combining all the models at once
1:13:39and do the testing so that is non-incremental integration testing so the drawbacks are two
1:13:45there are two drawbacks in the non-incremental testing that's the reason we don't prefer to
1:13:49perform non-incremental integration testing so this is one level of testing so so far how many
1:13:56levels we discussed unit testing we discussed integration testing is also we discussed
1:14:02now let us talk about system testing so this is the actual testing where we have to involve
1:14:07as a tester so system testing itself will take two to three sessions guys okay that much is
1:14:13bigger we are going to discuss different type of testings which we are going to conduct as
1:14:18part of system testing but now i'll just give you very high level overview what is system testing
1:14:24what we are going to do in the system testing in the coming sessions i will discuss in detail
1:14:29what exactly system testing means and what are the different type of testings we will conduct
1:14:34so because this is the actual area testers will be involved
1:14:38okay so what is system testing very very important so testing overall functionality
1:14:47of the application with respect to the customer or client requirements so here we are mainly
1:14:55focusing on the functionality of the application what is the functionality of the application
1:14:59suppose customer says from requirement like in my application in my software so and so should
1:15:05be there and they will give some requirement and as a test what you will do is the requirement is
1:15:13present in software or not the requirement is working properly or not the function is working
1:15:17properly or not the functionality is nothing but a some feature of your application so simple example
1:15:23guys let us take a whatsapp in the whatsapp what are the features or functionalities we have
1:15:28we can add the contact we can send the message we can send the videos images right we can share the
1:15:36location map so these are all different features of whatsapp okay so similarly every software every
1:15:43application is also having different number of features so in the system testing we are
1:15:48going to test those features we are not going to touch the code we are going to test the functional
1:15:55features functionality of the application with respect to the customer requirement
1:15:59okay whether it is working to according customer requirement or not that is a main intention of
1:16:04conducting system test system is what everything and it is a black box testing technique because we
1:16:11are not going to touch the code we are getting the ui application from the developers we will install
1:16:17it and we will completely test it and this testing is conducted by the testing team and testers are
1:16:24responsible for this testing because here the main thing is we have to know the requirement we have
1:16:30to thoroughly understand the customer requirement understand the flow of application understand the
1:16:35ui that's more important we no need to understand any code what is what is created by the developers
1:16:42okay so the requirement understanding is very very important here so after completion of component
1:16:49or integration testing we start this system testing this is a third level of testing yes
1:16:55first unit testing should be conducted then integration testing will be done
1:17:00after that we will start system testing until unless those testings are completed
1:17:05we cannot get the build or application from the developer then we will start the system testing
1:17:11third level of testing so before conducting system testing we should know the customer requirement
1:17:18as i said before we have to be understand system call requirement from the customer thoroughly
1:17:24so we will have different documents provided by the customers and designers and developers
1:17:29we will we will read those documents and understand the requirement clearly and
1:17:34then only we can conduct the testing and system testing is mainly focusing on four areas guys okay
1:17:42user interface testing functional testing non-functional testing usability testing
1:17:47so these are the four main categories of system testing we are going to conduct again in each and
1:17:54every category there are different type of testing we will conduct okay in the coming sessions i will
1:18:00explain in detail what exactly these testings are and what are other type of testings we can conduct
1:18:07in this category because before conducting the testing we have to know what kind of testing we
1:18:13have to do we have to conduct that's the most important right so that's the reason we are
1:18:17understanding this theoretically first if you know the what then the next level is how if you
1:18:23know what type of testing should be conducted then the next level we will know how to conduct
1:18:28those testings okay so that is the reason here we are understanding what are the different testings
1:18:34will be there and where exactly tester will involve what kind of testings the tester can do
1:18:40and once we understand this in the next level we will see how we can do those testing practically
1:18:45so that we are going to focus so system testing focuses mainly on four aspects user interface
1:18:52testing means what ui of the application so for example if i give the amazon.com that is a ui so
1:19:00what you will test on the ui part so you are going to test all the images properly aligned or not
1:19:06logo is display or not are like elements like application elements like text boxes check boxes
1:19:12drop downs are properly displayed or not look and feel of your application the colors and font
1:19:18so these things we are going to mainly focus that is user interface testing okay and each and every
1:19:25flow is properly working or not and the navigating between the pages so these things are comes under
1:19:30user interface testing the next level of next is a functional testing this is also comes under system
1:19:37testing and in the functional testing we are going to test the functionality of the application
1:19:43what is the functionality means the navigations flow actual functionality
1:19:47suppose when i say banking application so we test the login login is a one functionality
1:19:54and after successful login we will test the balance check balance functionality
1:19:59and money transfer functionality adding pay is a functionality generating report is a functionality
1:20:05request checkbook is one functionality so once application is there there are a lot of main
1:20:10functionalities are there so we are going to test those functionalities are properly working or not
1:20:16those features are properly working or not that comes down to the functional testing
1:20:20okay so we have input domain testing error handling testing database testing different
1:20:25type of testings will be there under functional testing so we are going to discuss them in the
1:20:29coming sessions the next one is a non-functional testing so non-functional in the sense like
1:20:36security testing performance testing installation testing compatibility testing so these are all
1:20:42comes under non-functional testing so once the functionality is stable then we'll start doing
1:20:48non-functional testing so if a function is working perfectly fine then we will test the performance
1:20:55performance testing comes under non-functional so what is performance testing means the speed
1:21:01of the application suppose if your application is accessed by n number of people through internet
1:21:06you are checking the speed of your application how well your application is responding to the users
1:21:11that is the speed of application but before testing that we have to test the functionality
1:21:17stable or not that is very very important and then non-functional testing will start will test
1:21:22the performance testing in this again load testing trust testing volume testing compatibility testing
1:21:29security testing so there are different type of testings will be there which are comes under
1:21:34non-functional testing and even in the real time there will be a separate environment will be there
1:21:40to conduct non-functional testing and this is also not done by the normal function testers
1:21:45there are separate dedicated team will be there to conduct non-functional testing because
1:21:50that needs a different setup environment okay normal environment will not be sufficient to
1:21:55conduct non-functional experts will be there security testing performance testing so these
1:22:01testings are very very huge testings and a lot of expertise is required to conduct those testings
1:22:07a special category of people will be there in the team and they will take care of those testings
1:22:12and finally we have usability testing usability testing in the sense uh user help suppose
1:22:21suppose if you bought some product a mobile phone or any bike or car whatever along with
1:22:27those products you will also get some document user manuals we can say what user manual contains
1:22:33how to use a product right so that user manual is very very important and required for the users
1:22:40when along with the software we are also going to provide the user manuals to the
1:22:45user our customer so we have to verify those user manuals so that user manual having proper content
1:22:52or not how to install the product how to perform the functionality each and every step whatever we
1:22:57do in the application will be documented that is basically called as a user context and sometimes
1:23:03in our applications also you will see some help menu at the corner even if you open the notepad
1:23:08or whatever you can see some help menu there you can get the help of that particular product
1:23:13so those things we are going to focus while doing usability testing so user friendly how friendly
1:23:18your application is for the customer so that is usability testing okay so these are all comes
1:23:25under system testing the overall functionality not only functionality non-functional aspects
1:23:32also we are going to test as part of system testing okay so here actual testers are involved
1:23:41very very important so next coming three to four sessions we are mainly focusing on
1:23:46only system testing because this is the exact area where we have to more focus on and after
1:23:52system testing the last level of testing is user acceptance testing uat testing this is the last
1:24:00level after completion of system testing user acceptance testing will be conducted
1:24:07so user acceptance testing normally conducted by the customers or users who are using the software
1:24:16and everything is working fine then they will accept the software okay whatever the requirement
1:24:21they have given they will finally verify those requirements are satisfying with this product
1:24:26or not so the main testing will be done by the users or customers or testers or developers can
1:24:33be do some help on them so they can assist them so testers also sometimes will be involved in
1:24:40the user acceptance testing along with the user so here we have again again multiple things like
1:24:47alpha testing beta testing will be there so after completion of system testing uat team conducts
1:24:53acceptance testing in different levels like alpha testing and beta testing something like this alpha
1:24:58testing in the sense the users or customers will do the testing and development environment
1:25:04development or testing environment or means what they will come back to the company wherever the
1:25:09software is developed they will come back to the company and do some testing that is alpha testing
1:25:16after that they will get the software and install that in their environment
1:25:22install that in their environment in the customer environment and then do some
1:25:26basic testing that comes on the beta testing after completion of these two testings our
1:25:32product or software will go to production and then actual customers will start using the software
1:25:39okay so this is user acceptance testing the last level of testing so we have discussed
1:25:46four levels of testing guys one is unit level unit testing integration testing system testing user
1:25:55acceptance testing so in the coming sessions we will talk more about system testing because this
1:26:02is the actual area we have to involve and n number of testings we are going to conduct so what are
1:26:08those testings that we have to learn first after learning then we will see practical implementation
1:26:16how we can conduct those testings before that we have to know what are those testings
1:26:20and then we will know how we can conduct the testing okay so that is a concept of
1:26:27levels of software testing guys okay so in the next session tomorrow we are going to discuss
1:26:34rest of the system testing gui testing in detail so these are all comes under again system testing
1:26:41okay so that's all for today's session guys i'm just stopping here
1:26:45now if you have anything you can discuss okay

About this transcript

This page contains the full transcript of Manual Software Testing Training Part-3 by SDET- QA, generated from the public captions YouTube serves with the video. The transcript has 13,661 words across 822 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.