YT YouTube2Text

YouTube2Text → Transcripts → Manual Software Testing Training Part-8

Manual Software Testing Training Part-8 — Transcript

by SDET- QA · 14,148 words · 829 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00all right so in the till uh previous session so we have seen uh hdlc process in the previous session
0:08software testing lifecycle so as part of software testing life cycle we have discussed about
0:14what is test planning and then test designing or test development or then test execution and bug
0:22reporting and finally test closure so these are the different activities we do as part of sdlc
0:28software testing life cycle process okay so now today we are going to discuss in detail each and
0:34every phase okay so what are the different terms we have to use like what is use case
0:39what is a test scenario what is a test case how test case look like how test plan look like so
0:45we will see each and everything in detail now let me share a small presentation just a moment
1:01all right so this is these are the different phases so we have seen yesterday test plan
1:06test design test execution defective boarding and test closure now let us start with the test plan
1:11so what is exactly test plan means in the previous session we have seen so test plan is nothing but a
1:17document so which describes the scope test scope strategy like objectives schedule deliverables
1:25and resources required to perform testing for a software product so test plan should be done
1:32before itself so before starting the testing we will do the planning so in the test plan
1:37we have to specify everything so what we are going to test what we are not going to test
1:43and what is in scope what is not in our scope and then what are the different test strategies we are
1:49going to use what are the different testing types we are going to use while testing and when we have
1:53to test when we have to conduct the testing that means schedules and we will conduct the testing
2:00like human resources and where exactly we conduct the testing on which environment we will conduct
2:04the testing like hardware environment so all these things you have to specify in the document that
2:10is called as a test plan document so here i have listed out some of the points so some of the items
2:17which we have to keep in your test plan document while you are preparing it so the first thing is
2:22like over you we have to specify like why what is the project and why we are preparing the test plan
2:27document we have to just write a small description under overview and then scope scope in the sense
2:33inclusion test environments and exclusions will be specified like what to test what not to test
2:39and how we will know that again depends on the requirement document whatever the requirement
2:43customer says we have to test them and whatever is not part of the requirement we don't test them
2:50okay so scope is nothing but what to test what not to test so these things we have to specify in that
2:56test strategy strategy means what kind of testing we are going to conduct
3:00first science smoke testing then sanity testing regression testing functional testing so these
3:05are the different strategies we are going to use like automation or manual testing what kind of
3:10strategy we are going to use so that is a part of test strategy then defect reporting and procedure
3:17so how we are going to report the bugs and what is the exact process we follow uh to report the
3:23defect from the tester to developer okay so later i'll discuss about defect lifecycle there you will
3:29understand exactly the procedure how you are going to report the defect to the developer
3:34and then rows and responsibilities so in your testing team there are multiple people will
3:38be there and the roles and responsibilities clearly defined in the test plan document like
3:45test engineer test lead project manager okay everybody in the team so we have to clearly
3:51specify the roles and responsibilities and who is other of the document who will review it all these
3:58things will be part of it test schedules means when we have to conduct what kind of testing
4:04so incl clearly we have to specify the dates also dates along with the what kind of activity
4:10we are going to do what kind of testing we are going to do so that we have to specify in the
4:14test plan document and test deliverable so test delivers test deliverables means each in each and
4:20every phase of a testing we are going to deliver certain documents like test plan document is one
4:25deliverable test cases are deliverables and defect report is a deliverable test execution report is a
4:32deliverable so after completion of each and every phase or step we are going to deliver
4:37a small document they are all deliverable so what kind of documents we are going to deliver
4:42so they that should be specified in the test plan document itself and the pricing how much pricing
4:47it will be take so again that is taken care by the management entry and exit criteria so when
4:53we have to start our testing when you have to exit from the testing so the entry criteria and exit
4:58criteria should be clearly mentioned in the test plan document suspension and resumption criteria
5:04so suspension results criteria means some sometimes uh immediately will stop testing suppose
5:11something is not working something is broken in your application okay we'll stop testing and uh
5:17then immediately after recovery like after getting the new build after getting after getting the fix
5:22immediately will again resume our testing so when exactly in which cases we have to stop the testing
5:27in which cases we have to resume the testing so that is also specified in the test plan document
5:32that is suspension and resumption criteria then tools what kind of tools we are going to use
5:37for testing purpose including manual tools also like even excel documents or word documents or
5:43bug tracking tools like automation testing tools or test management tools whatever tools we are
5:49using in our testing we can specify those tools and risks and medications means what suppose while
5:55pros while project is going on there will be some risks okay so a risk can be come from any side
6:03and what is the mitigation mitigation in the sense what is a another plan suppose uh a team member
6:09uh in the project they can leave for long time and uh that is a risk for project right one resource
6:16is gone so there is a risk for project immediately so we need to replace that person with some other
6:20guy so that is a risk what is the mitigation plan is we can replace the person similarly hardware
6:27suppose immediately in the in the middle of the project some hardware values are happen
6:32or some systems got trashed that is a risk so what is a mitigation plan so we have to
6:37always maintain the backup machines so risks and mitigations also we have to clearly specify in the
6:43test plan document and finally approvals from oh and all we need to get approval test plan approve
6:48will approve the test prime we will approve the test case so all these things we have to specify
6:53clearly in the test plan document so these are the main items which you have to clearly mention in
6:59the test plan document in interview people may ask you what is test plan and what it contains
7:04what is a what test plan contains then you have to tell all these important options the mainly
7:09the scope of the testing what to test what are the things we are not going to test so that's the
7:15first and most important thing we have to specify the test plan and schedules strategy and what are
7:21the deliverables okay so all these points you have to remember at least five to six points and
7:27then you can clearly say in your entry so this is a test plan content test document content so
7:33later i'll show you how test plan will be how we have to write the test plan and all these things
7:38so this is a just understanding purpose what is test plan and what it contains okay
7:45right so now let's move on to the uh few important terminologies we are going to use while test
7:51designing so use case test scenario test case so these are all topics very very important guys so
7:59you will definitely get interview questions from this definitely people who ask you questions
8:03from these topics okay please remember this and listen carefully use case test scenario test case
8:13use case test scenario and test case what exactly the means use case what is a use
8:19case means use case is basically describes a requirement so which will help us to understand
8:25the requirement more clear which will help us to understand the requirement more clear for example
8:33let's say i have a frs document or function requirement document and customer describes
8:38a requirement within one paragraph a small with the text only they use some text with
8:43some paragraph or two paragraph two paragraphs of two paragraph they have written in the document
8:49okay that is one kind of requirement and in the same document let us say customer is given some
8:56kind of a picture or diagram and which clearly saying the flow what user will do what action
9:02will do what is the outcome he will get the same thing is written in the text format so these two
9:08are the representation what exactly customer requirement is representing with two different
9:12ways either he can write in the paragraphs using only text or he can draw some pictures and flow
9:19by that also we can understand and which one is more clear so always the pictures are more clear
9:25to understand right so use cases seems like that use case is nothing but a a kind of a
9:31picture or a data flow diagram by which we can understand the requirement more clear so that
9:37is a part of the requirement so use cases also specified in the frs document along with the text
9:45so use case describes the requirement and mainly use cases that three options will be there
9:51the picture itself they will specify three main things actor action goal or outcome
9:58actor action goal or outcomes what does that mean actor is nothing but a user
10:05and user performs at an action then he will he will get some outcome let's say take a login
10:11application so as a user i'll perform the login after successful login i successfully
10:18log into application i'll get the home page so there are three things are there
10:22so user is nothing but an actor login operation that is nothing but an action
10:28after successful login i will get the home page that is our goal or outcome so use case is like
10:34that so by seeing the picture we can easily understand the functionality of the application
10:40so which contains the three parts actor action and goal so as an actor as a user what you have to do
10:47process action is nothing but a process and then what is the goal you will what is the outcome you
10:52will get after completion of the action so use case contains uh these three things use case
10:57talks about these three things and by seeing the use case we can clearly understand the
11:02functionality or the flow in the application so that is a part of the requirement
11:08so test the scenario is a different so tester scenario is nothing but a possible area to be
11:14tested so what we exactly we have to test now i have a 10 requirements in all the 10 requirements
11:22each and every requirement there is a different scenarios will be there so scenario means exactly
11:27what we have to test okay what you have to test in your application where exactly you have to
11:31conduct the testing what we have to test that is test scenario so based upon the use cases we
11:38will derive the test scenarios so to derive the test scenarios what is the input use cases where
11:45exactly we can find use cases in the frs document or functional requirement specification document
11:51so in that use cases will be defined and we will write the use cases tester will not write
11:57use cases okay product managers or product owners and whoever is written the document frs document
12:04or requirements they will create the use cases which are part of the requirement and based on
12:11the use cases as a tester we have to create our test scenarios and test cases so first initial
12:17level we will identify all the test scenarios like what to test we have to be very very clear on that
12:24so once you identify all the scenarios and for each scenario we will write multiple test cases
12:31for each scenario we will write multiple test cases okay so use case basically describes a
12:38requirement which is belongs to the requirement created by the business uh a product manager or
12:44business owner who is responsible for writing the frs document they will create the use cases
12:50or part of the frs document whereas test scenario is a area where exactly you have
12:57to conduct testing it basically describes a what to test and test case describes the how to test
13:04so what to test and how to test so test case is a basically step-by-step action to be performed
13:10to validate the functionality of application under test so whatever application we have
13:16and whatever the function you have to test to test that functionality we will go step by step
13:21so we will perform step by step actions on your application that is called as a test case so
13:27test case contains a multiple steps which we have to perform to perform or to perform to validate
13:32the functionality of the application so which is mainly focusing on how to test the functionality
13:39that is a basic difference between test scenario and test case so test scenario describes what
13:44to test test case describes how to test use case describes the part of requirement use
13:50case describes the requirement it tells us about the requirement more clearly it help
13:56us to understand the requirement more clearly and by using use cases we will define the test
14:02scenarios by using the test scenarios we will write the test cases so this is a relation between
14:09use case test scenario and test case guys are you clear so please confirm in the chart window which
14:16is very very important integration use case is a describes a requirement which is part of the
14:22requirement document test scenario is representing the what to test we have to write the test we have
14:28to identify the scenarios as a tester there's a tester responsibility and writing the test case
14:33is also tester responsibility based on the test scenarios we will derive the multiple test cases
14:40okay so this is a con concept now this is a sample use case guys i just now i told you
14:47the use case contains three different parts remember use case contains a three different parts
14:52actor action outcome right so if i just look at here library user he is a user actor and
15:00he can perform certain operations register a book register book loan register book written
15:07and query book availability add new book so these are these are the three items the user can perform
15:14and what librarian can perform he can add a new book so by seeing the picture we will understand
15:21the flow actually as a user what are the actions i can do as a librarian what are
15:25the action i came to okay so this is simple uh small use case which describes a requirement now
15:34use case versus test case so this is another important inter question will ask an interview
15:40what is the difference between use case and test case as i told you before use case describes the
15:47functional requirement which is part of the requirement document prepared by business analyst
15:53or product manager who is written the product functionality they are written the use cases like
16:00we which we call that we call them as a business analyst business analyst so use case describes
16:07the functional requirement prepared by the business analyst test case describes a test steps
16:14procedure prepared by the test engineer so two differences guys use case is basically describes
16:20a functional requirement test case describes the test steps or procedures use case prepared by the
16:27business analyst test case is prepared by the test engineers okay this is and test case will
16:34be prepared based on the use case if you want to prepare the test case you need to have scenario
16:38first and those scenarios will be derived from the use cases by understanding the use cases
16:44so this is a basic difference between use case and test case now test the scenario ss test case
16:52so test scenario versus test case so to write the test case first we need to have a test scenario
16:58and from where we will get the test scenario from the use case okay so use case based on the use
17:03case we will derive the multiple test scenarios for each test scenario we will have a multiple
17:09test cases so if i just look at here testing scenario is describes basically what to be tested
17:15and test case is how to be tested and for example here this is my test scenario if i
17:21just look at here checking the functionality of the login button so checking the functionality
17:26of the login button so that is a test scenario and what the test case is for that test case one click
17:33the button without entering username and password click the button only entering the username click
17:40the button while entering wrong username and wrong password so these are the different test cases we
17:44can write for one test scenario okay this is a small example of test scenario versus test cases
17:53then test to sweet we can also call it test to suit some people call it as a test suit and we can
17:58also call as test suite which which is basically group of test cases so we will group the similar
18:05type of test cases for example all the sanity test cases i will choose and group them into
18:12one single unit which is called as a sanity test suite all the regression test cases i will group
18:17them that is called as a regression test suite all functional test cases all gui test cases i will
18:23group them which is called as a gui test suite so what is a tester suite means a group of test cases
18:30which are belongs to same category which is called as a testosterone so if i just look at here
18:37and uh test suit one test so two testo three each suit contains a different category of the test
18:43case so test to suit contains the same category of the test cases and each test to suit is
18:48having a different category of the test cases ok understand the terminology which is very important
18:56and now finally what is test case so just now we have discussed the test case is a set of
19:01actions or step-by-step actions executed to validate a particular feature or a function
19:08of your application so suppose i have a login screen i want to test it what is a test case
19:13for login screen a login test so open the url entering the username entering the password
19:19click on submit button so these are the step by step action which you have to perform to
19:23test the login screen okay and which is also contains the expected value when you perform these
19:29actions what we are going to expect that is also part of the test case so a test case is a set of
19:36actions executed to validate particular feature or functionality of your software application
19:44then test case contains so test case is also a document guys okay so test case is also a document
19:53which is also contains a different options like a test plan but initially test cases will
20:00be prepared either in the word document or excel document later we will upload these test cases in
20:05the test management tools because in the early stages what will happen is as soon as we have
20:12written the test cases uh we don't directly upload the tools because we have to conduct
20:17multiple reviews with the team and they will also give you some feedback and they will also
20:22ask us to change some changes in our test cases so reviews will happen in multiple cycles so after
20:29we completed all the reviews and once the get the signed off from the teams then finally we will
20:36upload the test cases in the tool test management tools like jira is also there so we can upload all
20:41the test cases in the tools but at the initial level we always prefer excel file to write all
20:47the test cases so which is called as a test case document okay and normally what test case contains
20:55every test case will identify with some id every test case is a unique which is
21:00identified by using an id so every test case is having id and test case title we have to specify
21:07just one line or two lines and it is not a bigger title small title while reading
21:13the title we have to know exactly what is test case referring to and description we can specify
21:20and three to four lines of description we can write for test case and precondition means what
21:25before executing the test case what are the condition should be satisfied
21:29that is a precondition for example so i want to perform the login test so what is a precondition
21:35i should able to open the application first the url should work fine
21:39i should get the page then i can continue with the login so that is a precondition
21:44so for every task is to execute before executing the test case there will be a precondition
21:51and then priority priority means what in which order we have to execute the test case suppose
21:56i have 100 test cases which test case i have to execute first so how we will know that
22:01so we have to prioritize the test cases and based on the priority we have to execute the test cases
22:07in proper order like p 0 p 1 p 2 p 3 first we have to give p0 priority to the p0 very important
22:14test cases and basically they are related to smoke and sanity test cases and p1 test cases which are
22:21normally belongs to regression test cases and p2pt test p2 test cases which are basically belongs to
22:27functional test cases main major flows of your application p3 test cases means ui related test
22:33cases so based on the priority we are going to execute our test cases in proper order
22:39then requirement id so for which requirement we are writing the test case we have to also specify
22:45the requirement id steps or actions what are the different steps we have to perform and those we
22:50have to specify and what is the expected result after performing the steps or actions what is our
22:55expected result so that is also we have to specify as part of the test case and actual results
23:02we will update later actual results column will be empty while writing the test cases but once
23:09you start the execution then you will update this column with actual results then if you if you find
23:15any mismatched results between expected and actual then you can report that as a bug and sometimes
23:21some test cases also require some test data and we should also prepare the test data before
23:26writing the test cases and the test data also should be specified in the test case okay so
23:33these are the different items which we have to write while creating the test cases now if i
23:38just look at this this is a small template the test case document looks like this if i just
23:45look at here module id requirement id testing type priority and it will not be the exactly the same
23:51in every company people will change the template according to their requirement but the major
23:56important thing is you will not miss this one test cases steps will be compulsory it should be there
24:01actual results expect results should be there and precondition what is the scenario and test
24:07case id and priorities should be mentioned in the test case document but it will not be the exactly
24:12the same everywhere slight changes will be there but this these are the major main items should be
24:18part of your test case so if i just look at here each row is representing one test case
24:24okay test case id one so two three four we have to provide the unique test case id okay test case
24:30id will be the unique for every test case we have to we should not repeat the same id for multiple
24:35test cases so test case template seems like this in excel file is more comfortable so we can use
24:43excel file excel sheet as a test case template all right so [Music] this is all about test case
24:54so this is a test case template guys so whenever you want to write the test cases we use certain
24:59templates and first we as a beginning level we write the test cases in the template and once
25:05your reviews are completed signed off then we upload them into the test management tools okay
25:12fine so now the next one is the requirement reachability matrix what is requirement
25:19reasonability matrix we can say rtm so in interview you may get one important question guys
25:27so you have written 100 test cases right so how exactly you will know whether you covered
25:35all the scenarios or not so whether you have written test cases for all the scenarios or not
25:40how we will know that so this is an entry question so you may have 100 test cases you may write but
25:47how you make sure whether you covered all those requirements which are mentioned in the
25:52specification document or not so the answer for this requirement reasonability matrix as a tester
25:59while writing the test cases parallely we are also writing one more document called
26:05requirement reasonability matrix called rtm so what it says which contains a requirement ids
26:13corresponding test case ids so whenever you write the test cases you will clearly specify
26:19them so for which requirement what are the test cases we are going to write and requirement id
26:26which will map with test case ids maybe one requirement can have multiple test cases
26:31so requirement id corresponding test case ids you will write in special specific sheet or document
26:38that is called as a requirement traceability matrix so by seeing the document you will
26:42understand exactly okay we are are we covered these requirements as per test cases or not
26:48okay so that is the requirement is multimatic so rtm describes the mapping of requirements
26:54with the test cases and the main purpose of rtm is to see all test cases are covered so
27:02that no functionality should miss while doing the software testing and what it contains requirement
27:08id a requirement description if required you can also specify the description of the requirement
27:13then what are the test cases we have written for that requirement test case ids we have to specify
27:18so that is requirement traceability matrix very very important so we will
27:23prepare that tester will prepare prepare it while writing the test cases itself
27:29and he will cross check here whether he covered all the test cases all the requirement he covered
27:34all the test cases or not which is very very important and requirement raised multimatics
27:40looks like this so requirement number requirement description and test case ids you can specify
27:46because one requirement can have multiple test case ids so test case id we can specify and
27:51sometimes we can also update the status but not mandatory required okay but requirement
27:57id should be there the test case id should be there so mapping between the requirement ids
28:02and test case is called requirement reasonability matrix so based on this we will know exactly are
28:09we covered all the requirements are we written the test cases for every requirement or not
28:14so we will know that based on this requirement reasonability matrix very very important then
28:22test environment is okay test environment so what is test environment means so once your design
28:30is completed so you have written test plan you have written test cases and everything is ready
28:36and before getting the bill from the developer you have to set up the qa environment
28:41so what is environment means hardware and software environment so if you want to execute
28:47your test cases certain hardware environment is required similar certain software environment
28:53is required so that you have to set up during test environment so test environment should be
28:59a platform which is exactly replica of the customer platform guys very very important
29:06so where exactly customers use the software in their environment so once you install the
29:10software in the customer environment he will have some certain configurations right he will
29:14use certain number of machines he will use certain number of softwares the same kind of environment
29:20we have to set up in qa in our company because our testing is conducted in some kind of environment
29:28and the software is using in some other environment there will be conflict
29:32so whatever the customer is working on kind what kind of environment they are working on
29:36the same kind of environment we have to create we have to create in our testing
29:40so what is environment means software and hardware environment so what kind of machines they are
29:45using how much ram should be there how much hard disk it should be there what kind of processor
29:51processor here they are using internally in the computer and how much network speed they are using
29:57okay these are all hardware related requirements and what is software related requirements
30:02suppose to install a software there is some other software also required for support
30:07what kind of software they are using what kind of versions they are using and what kind
30:13of word document excel documents are they are using that is comes under the software
30:18so in the test environment we have to use and also on what kind of operating system they are using or
30:23they are using mac or they are using windows or linux and what kind of databases they are using
30:29mysql or sql server what kind of databases they are using okay and based on this we will collect
30:35all the environment requirements again that is a part of your requirement so we have to
30:40understand the customer environment and exactly we have to replicate that environment in the testing
30:46so then only we can conduct the testing and the same test cases will be passed
30:51in the customer environment also okay we have to give the priority to the customer
30:56so in whatever the environment they are working and same kind of environment we have to set up
31:01that's the first and most important thing we have to do before getting the bill from the developer
31:07okay so test environment is a platform specially built for test case execution on the software
31:13product right so it is created by integrating all required software and hardware along with the
31:18proper network configurations and test environment simulates production or real-time environment
31:25means what what is a production environment means where exactly customer will work that is
31:30a production environment and real-time environment or customer environment so that environment should
31:36be simulate and another name of test environment is test bed so this is a technical term so
31:42somebody may ask you what is test bed test bed is a nothing but a software and hardware environment
31:50we create to perform the testing so test bed is a an environment or collection of software and
31:57hardware environment which we can create to perform the testing that is called as a test
32:02bed okay test bed is a technical term which we can use alternatively for test environment
32:07simple so remember this this is a text execution okay now let's move to the next test execution
32:17so after test environment is done okay and after that we will receive the build from the developer
32:26so till now what are the activities we have done we have done the test plan we have created our
32:30test cases test scenarios test cases face building matrix and also have set up the environment then
32:37we are waiting for the bill from the tester so we are waiting for the build from the development
32:42so developer will provide the build so once the developer is provide the build to the testing team
32:48then we will install that product or application or software in the queue
32:52environment whatever environment we set up then we continue the testing so during this particular
32:58phase testing team will carry out the testing based on the test plans and test cases prepared
33:04and what is the anti-criteria test cases should be there test data and test plan
33:12okay so before starting the testing you have to you should have test cases ready and approved okay
33:20test case should be approved until unless your test case is approved you should not start testing
33:25test data is required sometimes for your test cases and test plan is also
33:29should be with you because you need to know the timelines and everything
33:33so you have to keep these things in your hand that is entry criteria then test execution will start
33:39so what you will do in the test execution test cases are executed based on the test planning
33:45test status of the test cases are marked like passed failed blocked or run or any other statuses
33:53most of the times we update pass failed or blocked okay and while executing the test case may be
33:59passed it may be fail or it may be blocked because of some reason so we will update the status
34:04and documentation of the test results and log defects for failed cases is done
34:08so whenever we find the mismatches between expert and actual we will fail those test
34:13cases and report the defects to the developer and we will also prepare a separate document
34:19defect log document where you will write all the defects all the blocked and file test cases
34:24are assigned bug ids for every bug or defect we reported to the developer should have some bug id
34:31and retesting once the defects are fixed suppose developers got fixed those defects and they have
34:36given them another bill again we have to conduct the re-testing and defects are tracked till the
34:42closure so whatever the defects be reported to the developer we have to track those defects till we
34:48close the testing till we stop our testing okay there will be number of defects will be there
34:54some defects will be reported some defects will be pending some defects will be postman to the
34:59next release different statuses will be there we have to track all the defects and finally
35:04deliverables so provides the defect and test case execution report with the completed results
35:09after completion of test execution what kind of reports we have what kind of documents we have we
35:15have a defect report which contains all the list of defects and test execution status so these
35:21documents we will need to have after completion of test execution so test planning test designing
35:28test environment setup then test execution so we will discuss in detail about the bugs or defects
35:34which is a huge concept okay so test execution and then guidelines for test execution so when
35:42you perform the executing your test cases when you're trying to execute your test cases we have
35:46to follow certain guidelines the first guideline is the build being deployed to the qa environment
35:53is most important part of the test execution cycle so always remember guys development
35:59environment is different qa environment is different so development is environment is
36:04used for developing a software they are having different machines different kind of configuration
36:09testing team is having a different kind of environment test environment
36:12so it is not sure like whatever the software we software installation is successfully working on
36:19development div environment but there is we don't have any shorty like the same kind of application
36:26will be successfully installed on q environment there is no guarantee we have to do the testing
36:31on that because environment will be different sometimes these kind of conflicts will be there
36:36between developer and tester so developer says it is successfully installed on my environment
36:41tester says no there is some configuration errors are coming in my environment so then you have to
36:47check the exact environment or not so but ultimate goal of tester is we have to always make sure
36:52our software should work again customer expected platform customer expected environment not on the
36:58developer not on the qa so 100 qa environment should be simulate the customer environment so
37:05test cases application should work on testing environment not on the developer environment
37:10okay so test execution happens in multiple cycles so test execution should be done on the q
37:18environment test execution happen in multiple cycles we cannot exude all
37:22the test case in one cycle guys okay we will get multiple cycles because we will get the multiple
37:26bills from the developer so during the process we will report multiple bugs developer fix it and
37:32we'll give you again multiple bill another bill again we will retest we do regression testing
37:37and continue with the rest of the test cases so again we'll report the defect in another bill
37:42again developer will fix it another give another bill so testing will happen in multiple cycles
37:47so test execution phase consists execution of test cases and sometimes we will also automate the test
37:53cases as soon as your test cases are passed manually will immediately automate those test
37:58cases so that in the upcoming bills we don't need to execute the same cases again and again manually
38:04because we are or if i automated those test cases we can run the automation script in the upcoming
38:10releases upcoming cycles so manual effort will be reduced so that is the main usage of automation
38:16automating the test cases it will reduce a lot of time and also lot of effort in each and every
38:23cycle of testing so these are the guidelines which we have to follow while test execution
38:30and then finally we'll talk about defects or bugs which is very very important concept
38:37you will get a lot of questions and interview people may ask different type of questions on this
38:42okay so let's understand few important concept from this defect or bug both are same
38:50remember guys some people will call as a defects some people call as a bugs or some less number
38:57of people are called as the issue issue is also written but it is not more technical
39:01it's a generic term but error is a different mistake is a different don't say mistake or
39:09don't say error error is a programming related so developer use that term mistake is a human mistake
39:16if i as a human as a tester if i write some incorrect test case that leads to missing of
39:22the defect that is a mistake as a human i committed that what is the bug and defect
39:29any mismatched functionality between expected and actual suppose when executing my test case
39:34on my application when executing my test case and my application i am expecting something some
39:41outcome i am expecting from the application but actually it is working in different way
39:47so that is a mismatch between expected and actual if you found something mismatched between expert
39:53and actual we can consider that as a bug or a defect so we have to report that to the developer
40:00and developer will understand that and if it is really back or really defect then he will fix it
40:06and provide another build so any mismatched functionality found in an application is
40:12called as a defect bug or issue and here we should not use term called error or mistake
40:20so during the test execution test engineers are reporting mismatches as a defects to the
40:26developer through templates or using tools most of the times we use the tools guys but initially uh
40:34for our purpose we will prepare a document like we will prepare some excel sheet we will report
40:38all we will write all the defect information but we don't send exact same format to the developer
40:44we will have a bug tracking or defect tracking tools so there you will get a small form in that
40:49form we will fill all the details like what is the defect id will be automatically generated
40:54defect description what is the cbrt what's the priority what are the steps you have to perform
40:59to reproduce the defect okay and who is reporting the defect and the screenshot you can attach
41:05for the defect and log files you can attach okay and once you provided all this information then
41:12once you submitted it will automatically go to corresponding developer worries implemented that
41:17particular feature or whoever is developed that particular feature in application that developer
41:21will automatically get the details and then developer will work on the defect so that is
41:26actual process we follow so in the comment section i'll show you how to report the defects okay
41:32and there are n number of tools are available in the market to reporting the difference some
41:37of open source tools also there like free tools also available some of them are paid
41:41tools also available so we have a clear quest devtrack quality center
41:49or we can say alm and bhagji la so these are all tools we can use it for bug tracking tools
41:55okay bug tracking reporting tools and especially when it's a jira and quality center they are
42:01basically test management tools so there are two differences you need to understand guys
42:07test management tools are different bug tracking tools are different so back tracking
42:14tools will use only for bug tracking we cannot do any other activity they are bug tracking
42:19rules like if i say here clear quest is a purely back tracking or defect tracking tool devtrack is
42:25a bug tracking tool bugzilla also purely buck tracking tool we can use those tools only for
42:31bug tracking or defect reporting tools we can use them to report the defects to the developers but
42:38jira quality center these tools are test management tools means what we can
42:45track each and every activity during the testing like beginning from the beginning of requirement
42:50we can define the requirements we can write the scenarios we can write the test cases
42:54we can upgrade the execution status we can report the defects everything we can do in those tools
43:00they are called test management tools so not only defect reporting apart from the depot reporting we
43:05can also do some other test management activities we can also track test management activities
43:11those tools are called test management tools so understand the difference so defect tracking tools
43:18use it for only for dpi defect tracking defect reporting but test management tools can also
43:23use defect reporting apart from that other activities also we can track in those tools
43:29right so we are going to learn jira also so once you start understanding jira then you will know
43:34exactly how we can track all the testing activities
43:38okay so jira is a tool is a test management tool or we can say agile tool
43:44where you will track everything we will define the requirements we'll write the test cases so jira
43:49tool can be used by everybody in the team guys not only testers developers also use jira tool
43:55to track their activities okay it is a basically agile tool
43:59so i will explain this in detail in the coming session so don't be hurry okay just understand
44:04what is this tool and how we can perform as a tester as a developer both will use jira tool
44:10as a tester i will define the requirement uh the requirement you define will be business unit so
44:16business owner or product manager will define the requirements in the jira tool and for those
44:20requirements as a tester i will write the test cases and i report the bugs and i'll also update
44:27the execution status but what developer will do developer also have some their unit test
44:32cases integration test cases execution stages everything so they also use jira tool parallely
44:38okay but all the project related activities will be tracked in single place so that is jira tool
44:46okay so now defect report content so just like a test case document we also have a defect report
44:55so in the deep one whenever you report the defect to the developer what are the different contents
45:00you have to specify which is very very important interquestion also so whenever
45:05you report the defect to the developer what are the details you have to provide to the developer
45:09so not only defect id you have to specify detailed information so the developer can easily understand
45:15where exactly the bug is there and how we can fix it so defect report contains a defect id the
45:22first this is a unique identification number for every defect then defect description so the defect
45:30description says detail information what exactly the defect is you can write a small description
45:37and worship and version of the application suppose so you will get multiple built from the developer
45:44so each build is having some version number because you don't know exactly
45:49which build is world which one is the latest bill so every bill is given
45:53a number called as a build bill verification number or we can say build id okay and that id
46:01also we have to specify the version number also we have to space in which build we found the defect
46:06so build number also we have to specify and steps steps means what to reproduce that bug
46:12or defect what are the steps to be performed on the application so those steps we have to clearly
46:18specify and date rised so when exactly we are raising this defect reference and what are the
46:24reference documents we referred to consider this is a bug suppose i have executed one test case
46:31i found a mismatch i consider as a bug but on what basis you are saying that is a bug you have
46:38some reference right so what are those reference your test case and your requirement document okay
46:45or design whatever so based on that you consider that as a bug so you have to specify the reference
46:51also sometimes and detected by that is normally tester name status every defect is having some
46:58status guys new open in progress okay and closed so different statuses will be keep on changing so
47:08i'll explain that in the defect lifecycle then you will understand what is the status of the defect
47:12so as soon as you rise a new bug or new defect the status will be the new so as soon as the
47:18developer is started working on the defect then defect status will be changed as open and uh while
47:25working on the defect fixing by the developer in that time the status will be in progress okay and
47:33once the developer is fixing that issue or fixed that bug the status will be changed as a fixed
47:39and once the developer is fixing that bug and put that change in the build again we will get another
47:44bill after retesting if it is working fine we will close the defect then that time the defense status
47:51will be changed as a closed so depends upon the situation and action the defect status will keep
47:58on changing finally the ultimate goal is it should start from the new status and it should end with
48:05the closed status and before releasing the product to the next level or next to you for uit testing
48:11or customer all the defects whatever we reported to the developer should be in the closed state
48:18okay that is also one of the criteria whenever we exit from the testing now that is all about status
48:25then fixed by who is a developer who is responsible for fixing that bug the developer
48:33name should come date closed so whenever you close the defect automatically date will be updated
48:39and cvrt and priority is very very important so now we'll talk about cvr 10 priority just
48:45a moment okay so now cbrt and biot so every defect guys every defect whenever you report
48:53we have to as a tester we have to assign we have to tell cvrt and priority so we need
48:59to discuss more detail what exactly cvrt and priority means which is very very important
49:06so whenever you write a test case you will prioritize them okay so whenever you write
49:14it as case you prioritize them so test cases are having only priority so there the priority
49:20says in which order test cases should be executed but here defect is having two things
49:26cbi 10 priority i tell you what exactly see we are 10 priority in d10 first let us start with
49:35okay just a moment yeah let us start with
49:40classification so see we are attend priority cbrt and priority we have to assign this is
49:46a tester responsibility so tester has to specify the cbi and priority of the defect before raising
49:54the defect to the developer so cvrt can be four types guys okay blocker critical major and minor
50:05just a moment
50:09okay so cvrt and priority so cbrt is a blocker critical major or minor
50:18blocker critical major minor and priority means we can start with p1 p2 and p3 so pi rds and
50:24these names will be changed one company to another company everywhere you cannot find the same thing
50:30so blocker sometimes cbrt we can also reference h1 h2 s3 like this
50:35or s1 s2 s3 like this so naming convention will be little different but cbrt four types blocker
50:42critical major minor and a priority p1 p2pt so basically what is cbr10 what is priority
50:52so here cbrt describes the seriousness of seriousness of the defect how much impact on
51:00business workflow so cbrt means how the customer workflow will be impacted because of that defect
51:08that is severe seriousness of the bug okay if bug is coming the customer environment how much
51:15his business flow is impacted that is called as severity so cbrt describes the seriousness of the
51:22defect and how much impact on business workflow and it is four types blocker which is also called
51:29as a show stopper this is again technical term in interview people may ask you what is show stopper
51:35so stopper in the sense we can call it as a blocker critical major minor so these are the
51:41four types of severities we can ascend either one of the security we have to ascend to the bug but
51:47when we have to assign blocker when we have to assign critical when we have to ascend major
51:51and minor we have to understand very clearly so whenever you report a bug for example when you're
51:57reporting the bug or whenever you found something is completely blocked it is not working at all
52:06like application is crashed at the time of installation or when you log into your application
52:12login is not working properly and because of that you are cannot proceed for further testing right
52:19you cannot proceed your testing that means you are completely blocked you are testing
52:25so you are not able to proceed further if your login itself is not working
52:30right how can you execute rest of the test cases you cannot so you completely blocked
52:35so in that case you have to assign blocker you have to give severity as a blocker means until
52:42unless the developer fixes that bug you cannot proceed further in that situation you have to
52:48specify the defect as a blocker understand so whenever you find a situation where
52:55you cannot proceed further you cannot proceed or you cannot executing the other test cases in that
53:03case you have to report that bug as a blocker very very important so the defect indicates
53:09nothing can proceed further example application is crashed you open the url of application it is
53:16saying page not found or error in a page so you cannot go further and login is not work
53:22you cannot test anything so these are the examples for blockers now when you have to specify critical
53:31critical means you are not completely blocked okay you are able to proceed but the main
53:38or the basic functionality is not working customer business workflow is broken they
53:44cannot proceed further that means we are able to install the application we are able to proceed
53:50testing okay but the major functionality is not working the main functionality for example in
53:57internet banking for example in internet banking application what are the major functionalities
54:02checking the balance transferring the fund so these are the major functionalities right
54:07so to perform these activities internet banking application is introduced
54:12but after successful login if that functionalities the major functionality is not working means what
54:18that is a critical bug the main suppose if it is a e-commerce application like amazon so what is the
54:26main functionality of amazon searching the product add the product to the cart and do the payment if
54:32this particular flow is not working that means what the major functionality is gone is broken
54:38in the application that kind of bugs we have to consider as a critical critical means the main
54:44functionality the basic fundamental functionality of the application is not working so that impact
54:51the customer business and the main function is broken so that is basically comes under critical
54:57defects if the major function is not working fine we have to report that bug as a critical examples
55:05fund transfer is not working in net banking there's a main functionality in internet banking
55:10right so that is a critical functionality so we have to report that back as a critical
55:15so ordering product in e-commerce application is not working that's a
55:18major flow suppose you have to book a cab like ola or uber cab you have to book so order
55:25booking cab functionalities itself is not working after login so that's a major functionality basic
55:30functionality it should supposed to perform right so those are all called as a critical bugs
55:37critical bugs then major so major when we have to provide a major cbrd here functionality works fine
55:48okay there is no problem with the feature of functionality but some how undesirable behavior
55:55somehow the undesirable behavior for example let us take a gmail application so in the
56:00gmail application you are sending a mail to some other case you put some cc or bc some recipients
56:06and once you compose your email and then click on the submit as soon as you get this as soon as
56:12you click on the submit the mail is successfully sent but you haven't get any confirmation message
56:18like your maze is sent successfully like this but you don't know as a user you don't know whether
56:23your mail is gone successfully or not but when you see the sent mail box whatever you email you
56:29already sent that is part of your sentiment folder that confirms you but before that you
56:35have to know some confirmation message there until unless you get the confirmation message
56:39user will be in the confusion state you don't know exactly whatever action or
56:43whatever the functionality have performed is successfully done or not you don't know exactly
56:48right but function is working fine functionality no major issue if functionality is broken that is
56:54again comes under the critical but the function is working fine application is working files
56:58feature is working fine but somewhere there is undesirable behavior like confirmation message
57:05we haven't get so that will confuse the user whether with a sender email successfully or not
57:10so that comes at the major for example take a booking cap so you are booked upon cab and
57:18you selected the source and destination places you have booked the cap and request went to the driver
57:24but you haven't get the confirmation message you are not able to navigate where exactly he is
57:30okay but the successfully cap is booked and he's came and he's waiting for you
57:35but you don't you don't know exactly whether book is properly properly booked or not because
57:41you haven't have any acknowledgement there so that kind of bugs be reported as a major
57:48okay so functionality is working fine feature is working fine no issues in the future but as
57:54a user i should know whatever action i perform it is working fine or not successful or not i should
57:59know for that i need some confirmation from the application so if that is not working means they
58:04are the major okay so and finally minor defects so minor defect means that defect will not impact
58:14uh any business or any breakdown it's very very minor means like look and feel of the application
58:22or spelling small spelling mistake alignment they are all comes under minor for example
58:27in the login screen okay so for example in the login screen
58:33let me show you okay suppose in the login screen you have some box like this
58:42okay so you have some box like this username textbox is like this this is my username textbox
58:48and this is a small password box this is my password box if i just look at here the size of
58:55the elements is different but this will not affect any functionality so when i enter username and
59:00password when i click on ok button successfully it is login and i'm getting the home page
59:05this will not impact any functionality or any business flow but the size of the element or the
59:10alignment suppose the button or text box will be here or button will be here the alignment
59:16things or color look and feel of the application or sizes of the images so these things will become
59:23under minus minor minor defects because they are not impacting any business flow or functionality
59:30and they are not blocking you you are able to test it you are able to test it you are
59:35able to execute your test cases also on that particular screen so you will not get any issue
59:40except that ui end alignments and everything spelling mistake
59:44okay they are minor defects a low priority of minor defects it won't cause any major
59:51breakdown of the system so those type of bugs become report as a minor bugs
59:56so these are the four categories of cbrt's blocker or show stopper whenever you completely blocked
1:00:04you are not able to proceed further testing then you have to report that bug as a blocker and
1:00:10critical whenever the major functionality the main functionality of the application is not working
1:00:16or the customer business flow is impacting or broken then you have to report as a critical bug
1:00:23and major means the functionality is working fine the feature is working fine but as a user i don't
1:00:29have any acknowledgement from the application i don't exactly the working feature is working or
1:00:35not i don't know exactly in that case major minor spelling mistakes colors look and fees alignments
1:00:41so these things you can report as a minus cvrt because they are not impacting the business they
1:00:46are not that much seriously we can take okay so four types of crds and we will assign the cvrt to
1:00:53the defect tester will assign the cvrt tester will assign the cvrt even priority also tester will
1:00:59assign so blocker critical major and minor these are the defect severities so are you guys clear
1:01:11please confirm in the chat window everyone so are you guys clear defect severity what
1:01:16is exactly defect severity means what are the defect type of severities we can assign
1:01:21while reporting the diff while reporting to the developer okay blocker critical major and minor
1:01:34okay now let us discuss about priority okay
1:01:44yes so now let us discuss about priority
1:01:48so whenever you report a defect we will specify the severity along with the priority so cbrd says
1:01:56the seriousness of the defect how much the business will impact because of the defect
1:02:02but in the priority describes the importance of defect how soon the defect should be fixed
1:02:09so that is representing the priority so priority describes the importance of the defects priority
1:02:15describes the importance of the defect how soon the developer should fix the defect
1:02:21so developer will consider the priority based on the priority the developer fix that bug
1:02:28okay and defect priority states the order in which defect should be fixed
1:02:34okay so priority p0 p1 p2 there are three priorities we will have p0 means high p1 means we
1:02:40can say medium p2 means low high priority medium priority low priority so when we have to give
1:02:46this priority so whenever you reporting the defect to the developer we will anyway specify the cbrt
1:02:52along with that we should also specify the priority so when we have to give p0 hi
1:02:58so whenever you want to whenever the developer you want developer to fix that issue immediately
1:03:06like the defect must be resolved immediately because that affects the system severely
1:03:14and we you cannot proceed further until that bug is fixed in that case you will specify the
1:03:21p0 so whenever you report a bug with a p0 priority developer should immediately work on the defect
1:03:28immediately has to provide the fix for that because you are completely blocked there you
1:03:33cannot go further until unless that bug is fixed so in those cases we will specify high priority
1:03:42then medium priority so when you provide a medium priority p1 then customer will wait for the new
1:03:50versions like every version of release will be there so different versions of software will
1:03:55be released so when i say p1 or medium so that bug can be fixed in the upcoming versions and p2
1:04:04means very low the developer can fix it in later releases so next version is different next release
1:04:10is different guys so in one release there will be multiple versions in one release there will be
1:04:15multiple versions so if when i say p1 medium is it should be fixed within the same release that means
1:04:22in multiple versions some in one specific version or some version within the release they have to
1:04:27fix that back but when i say p2 they will fix that buck in the upcoming releases not in the versions
1:04:35okay p0 p1 p2 you need to understand this seriousness of the defect means cbrd cbrt means
1:04:43how the defect is impacting the customer business how serious it is you have to tell
1:04:48in the case of severity defect by id says how soon the developer will fix it so based on the
1:04:55priority the developer will choose that particular you may reported 10 defects among those 10 defense
1:05:02developer will not fix all of them at once they will choose the defects they will choose
1:05:08the defect based on the priority you specified so whatever the defects you are ascend p1 p0 priority
1:05:14developer will work on p0 bugs or p0 defects first after fixing and closing them then they will
1:05:21go to p1 then they will go to p2 based on your priority the developer will work on those defects
1:05:27very very important so whenever you report a defect to the developer you have to provide cbrt
1:05:35and a priority cbrd means the seriousness of the defect priority means the importance of the defect
1:05:41how much important it is both you have to specify but after reporting this after reporting this
1:05:50priority can be changed by your leads or manager test managers or product managers okay priority
1:05:58can be changed you have given some priority to that bug but like your customer or your product
1:06:06manager think like okay this is not priority now so you can just focus on some other defect in
1:06:12that case priority can be changed priority can be changed by the product owner or business analyst
1:06:18or is given the requirement to you he has choice to change the priority but seriousness nobody
1:06:25can change only that is a tester responsibility so in interview people may ask you a question
1:06:30we will give you civility in priority tester should provide the cvr 10 priority
1:06:37okay so but variety can be changed priority can be changed by the developer also sometimes
1:06:45and business analyst also can change the priority but cbrt should not change that is
1:06:51a tester responsibility if you want to change the cbrt tester itself has to change but developers
1:06:57and business analyst these people will not touch the cbrt because as a tester you have tested your
1:07:03application you have executed test cases you know exactly how much business will be impacted because
1:07:08of the seriousness of the bug so seriousness you have to tell but priority when that bug should be
1:07:15fixed will be decided but decided by you first initial level and later developer or business
1:07:22analyst may or may not change the priority that is up to them okay so this is a defect priority
1:07:32okay so the categorization everything we have to do as a tester we have to decide based on
1:07:38the defect you have to analyze okay which is high or not and priority what kind of severity i have
1:07:45to give to this defect and what kind of priority how to provide so as a tester you should decide
1:07:51you should decide i have given some examples so that's the reason i clearly expand here
1:07:56so when i talking about severity blocker critical major minor depends upon the
1:08:02seriousness of the defect you have to decide whether it is a blocker or it is a critical
1:08:07or it is a major or it is a minor you have to decide and you have to provide the severity
1:08:12similarly you have to provide the priority while reporting the defects how well how soon
1:08:18it should fix so if you want to if you want to fix the defect immediately by the developer then
1:08:24give p0 or sometimes you may also expect the same fix in the next version then you can give
1:08:32p1 or the defect is not that much important now but in future in upcoming releases the
1:08:38developer can work on it in that case you can just give p2 priority
1:08:43so that is completely your responsibility as a tester to categorize the severities and priorities
1:08:53understand guys everyone so defect priority and cvrt very very important topic
1:09:01all right so can you guys please confirm in the chat window how are you guys clear so far
1:09:06all right now sometimes interview people may ask you very very important scenarios
1:09:14there are certain situations the bugs will fall under icbrt and low uh high cbrd and priority are
1:09:24low cbrt prior to the combinations like that bug can be fall under high cbrt and high priority or
1:09:31the bug can fall under high cvrt and low priority and sometimes the bug fall under low severity and
1:09:37high priority and sometimes the bug fall under low severity and low priority so different categories
1:09:45and can you tell some examples this is again an interview people may ask this kind of questions
1:09:51can you tell me a few examples of high severity and high priority high severity in low priority
1:09:57similarly low civility and high priority and low severe attend low priority so you should be able
1:10:02to give some examples so here i'll provide you multiple examples and you can remember and you can
1:10:09clearly explain it just understand the situation so i have a bug like this login is taking to blank
1:10:16page so as soon as i enter username and password by clicking on the submit button
1:10:22and it is not giving a home page it is just giving a blank page after login is successful it is just
1:10:28giving a blank page i don't know whether login is successful or not i don't know anything just
1:10:33it is giving a blank page then what is a priority and what is the cbrt you will assign to that bug
1:10:40so what is a cbrt what is the priority you have to assign to the bug and how we have to ascend
1:10:45observe this very carefully first we have to think about severity so login is not working means what
1:10:52you are not able to proceed further that means you are completely blocked so when i say blocked
1:10:57means what high severity that comes under high severity blocked now think about priority so when
1:11:06you want to fix that bug immediately you want to fix that bug right if i not fix that bug you
1:11:11cannot continue further immediately the time so priority is also very high so this is comes under
1:11:19high severity and high priority if login is not working means what you completely blocked
1:11:26at the same time until unless that bug is fixed you cannot proceed further immediately
1:11:30you want to fix that so you have to give high severity and high priority that is one example
1:11:38now high cbrt high cbrt and low priority so this is the area i'm talking about
1:11:47okay so high cbrt high cbrt and low priority now observe this situation about link is not
1:11:55going to a blank page is going to a blank page for example you successfully log into
1:12:00our application as soon as you log into our application you will see some menu options there
1:12:06right like home page or contact page like about page something like that you will see multiple
1:12:11options there as soon as you enter into the login page immediately you will see those options
1:12:17in that when you click on the about us link it is giving a blank page so when you click on the
1:12:24about link page it is giving a blank page you are not able to see any content there this is
1:12:29a bug so now what could be the cb attend what would be the priority so you have to analyze it
1:12:37so about link is not going to blank base so it is comes under high cbi 10 the low priority
1:12:45so high cbrt low priority why let me tell you so this is comes under high cbrt and low priority so
1:12:53why it is become high severe high severe why it is become high severe because as a user when i first
1:13:02log into my application what are options i can see home page contact above these links i can see
1:13:09and i can perform click action on the about us if it is not going to the actual page it is not going
1:13:16to the actual page that means the functionality is broken there the functionality is broken so
1:13:22high cbrt and do you want to fix it immediately about page is it really required to fix now
1:13:31not required because that's the only page which is just not giving the information but you are able
1:13:37to proceed the testing for other things right so it is not that much important now so a developer
1:13:44also can fix in the next version right so you can give low priority so but the functionality is
1:13:50broken here because of that we have to give high severity but this is not needed to fix immediately
1:13:58okay so we can give the low priority so high cbrt and the low priority now next example see
1:14:07this low cbrt high priority low severity high priority after user is logged into application
1:14:16he can see home page but there is a spelling mistake in the home page observe this so user
1:14:23is logged into application successfully logged in as soon as i see the pages there is a home page
1:14:28tab is there and there is a spelling mistake in that there is a spelling mistake in the home page
1:14:35like something m is missing or p is missing then what kind of category it is it is low
1:14:42cvrt because that is not impacting the business when i click on the link it is working fine
1:14:46only the spelling mistake so that will not break your functionality or it will not break your
1:14:52application so cbrt level is very low but which is high priority why it is a high priority because
1:15:00as a user as a customer as soon as i log into application the what is the first i can see
1:15:06the tabs so user always login to application firstly we will see homepage but inner pages
1:15:14he may not navigate more detail but as a home page everybody will see home page first so if
1:15:21in the home page if the if you can see some mistakes or spelling mistake it doesn't good like
1:15:26it doesn't looks good right it will be very odd so in the home pages there should not be any spelling
1:15:32mistakes you should not looks very odd so customer point of view user point of view this is very very
1:15:39high priority but cbrt is very low because home pages link is displaying when i click on this
1:15:46it is properly navigating to the home page and functionality is working fine only the spelling
1:15:50mistake so it is not impacting the business but in the customer point of view or user point of view
1:15:57it should be fixed very soon so high priority low cbrt and high priority that is one example now
1:16:08low cvrt and low priority this one low cbrt and the low priority suppose uh you in your
1:16:15application we have a contact page so when you click on the contact page the contact details
1:16:22are displayed on the page so like email id phone number addresses everything is displayed on the
1:16:28contact page somewhere so email id is having some small spelling mistake email id is having a small
1:16:35spelling mistake like l is missing or m is missing something like that so this comes under low
1:16:41priority and low cvrt observe this very carefully so what is the difference between here and here
1:16:48both are spelling mistakes only right but why here it becomes a low severity in high priority
1:16:56but here it is also spelling mistake but why here it is becomes a low severity and low priority
1:17:03okay in both the cases low cbrt because here also it is not impacting the application and here also
1:17:09it is not impacting the application workflow there is no function that is broken so it is a lower c
1:17:15we are defined but why it is become high priority here and why it is become low priority here
1:17:21both are spelling mistakes right but the reason is here as soon as a user enter into the application
1:17:29he will able to see the home page link it will appear in front of him it looks very odd
1:17:36so that's the reason it becomes a high priority has to fix it developer has to fix it but when you
1:17:42come to this area contact page link is working and when you enter the contact page you will find all
1:17:49the details among all the details somewhere email address spelling mistake but most of the users may
1:17:56not notice that and somewhere in the corner area those details are displayed so every time user
1:18:03will not go to contact page every time but user is always see the home page but user will not go to
1:18:08contact page every time very rare cases he will go and small issue maybe that is not noticeable also
1:18:15so that is the reason here it becomes a low priority and the same kind of issue
1:18:20here it becomes a high priority so depends upon the user's prospect you have to think
1:18:26user point of view have to think then we can give proper priority and severities so this is these
1:18:32are the few examples of high cbr10 priority and low cvr in priorities the combinations
1:18:39in interview people may definitely ask you this kind of question you should able to answer this
1:18:45and here i have given a few more examples
1:18:49just a moment yeah so here a few more examples i have given low priority and low severity
1:18:57a spelling mistake in a page not frequently navigated by use a spelling mistake in a page
1:19:03not frequently navigated to byte user so there is a spelling mistake in the page but
1:19:08always users will not see the page every time so that is a low priority and low severity
1:19:14an application crashing in some very corner cases application is crashing in some very corner case
1:19:21see this low priority in high severity application crashing that is always high
1:19:26severity crashing means severity high cbrt but why it has become low priority because
1:19:31very corner case users may not go into that area most of the times so we can give low priority
1:19:39high priority low cbrt so slight change in lower color or spelling mistake in a company
1:19:45name so these are high priority there is no low cbrt because this will not impact any business
1:19:52logo color and mistake spelling mistakes will not impact any business but as a customer point
1:19:57of view there should be proper so high priority customer will see the logo first they will see
1:20:02the company name is there on their own application or not if they seems very uh incorrect so customer
1:20:08will feel bad so they are high priority and low cbrt similarly high priority high severity issue
1:20:16with the login functionality user is not able to log into application that is always high priority
1:20:20and high cbrt then high cvi and low priority one more example high cvrt and low priority webpage
1:20:27is not found when user clicks on the link user does not miss the page generally see this when
1:20:32i click on the some link the page is not found error is coming that means a crash so high cbrt
1:20:39but user does not visit the page normally very rare cases the user go to that page so low
1:20:45priority the last one low priority low severity any cosmetic or spelling is cosmetic in the sense
1:20:52spelling mistakes alignment colors these are all comes under cosmetic functionality so any cosmetic
1:21:00or spelling issues which with which is within a paragraph or in a page comes under low priority
1:21:05and low severities so just remember few examples like this and in interview it will
1:21:13be very easy to explain the things okay so we have discussed what is exactly defect and back
1:21:21and what are the defect contents we have and also we have discussed what is a cvrt
1:21:26and what is the priority and also different combinations of priorities and severities
1:21:33okay so probably in the next session yeah so there will be another point called defect resolution
1:21:40so whenever you reported it defect the developer will update one column called
1:21:46defect resolution guys so this is a actual column which is updated by the developer
1:21:52and in interview people may ask you one question what is defect resolution
1:21:56which is very very important so whenever you report a defect to the developer
1:22:02developer has some opinion on that effect like whether is it really a defect or not or is it
1:22:08a duplicate effect that means the developer the tester is only rise earlier or developer think
1:22:13it is not at all a bug dot not at all a defect or developer not able to reproduce the defect
1:22:20in their environment so whenever you report a defect to the developer so developer is having
1:22:26their own opinion on the defect that is basically called as defect resolution what kind of opinion
1:22:32developer is having suppose the resolution types will be different so when i say resolution type is
1:22:38accept that means what developer is accepted that is a defect and he is ready to fix it
1:22:44and sometimes the defects developer is specified reject as a defect resolution in that case what
1:22:52we reported a defect but developer is not accepted that is a defect he is rejected he
1:22:57is not ready to fix it then duplicate so when the resolution type is duplicate means what
1:23:03developer is thing that is a duplicate defect that means we already rise as the defect earlier
1:23:09so that is a duplicate enhancement enhancement is what sometimes we reported a defect and
1:23:15developers think it not exactly defect that's a enhancement or new feature which will come in the
1:23:22next coming uh really coming versions are coming releases sometimes we can misunderstand like a
1:23:28bug is a feature or feature is a bug so that's the reason we have to carefully read the requirements
1:23:34then we will know exactly which one is a bug which one is an enhancement or feature and need more
1:23:39information sometimes the developer come back and ask you for need more information about the defect
1:23:44in that case you can provide more information like screenshot steps or log files everything
1:23:50and not reproducible means what you reported that developer you reported the bug to the developer
1:23:56but developer is trying to reproduce the bug in their environment but it is not able to do that
1:24:03there is a defect in application in your environment when you test it in your
1:24:06environment you found the defect but the same defect is not coming in the dev environment
1:24:10in that case developer says not reproducible and fixed so whenever defect is accepted by
1:24:17the developer and fix it then he say resolution type is fixed then finally
1:24:23as designed as design means what whenever you reported a bug to the developer developer thing
1:24:29that is not a defect that is actual functionality it should supposed to work like that if the
1:24:35developer feels like that he specified as designed okay that is not really bad that should work like
1:24:42that only so it depends on the requirement so as a developer says as designed so these are the
1:24:49different resolution types so resolution type is also one of the columns should be specified in the
1:24:54bug report or defect report and that column is always updated by the developer not by the tester
1:25:02okay while reporting the defect in the tool also there will be some field so resolution type so
1:25:07developer has to select that file tester don't have any right to select that field
1:25:12developer when he working on the defect he has to change the resolution type
1:25:18okay so that is all about defect resolution guys
1:25:23so that is all about defect resolution now let us stop here for today guys so still
1:25:30we have few more things we have to discuss about defect like different life cycles and everything
1:25:34so now let us continue the tomorrow session okay so i am just stopping here

About this transcript

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