QA Testing with Agile & JIRA - From Beginner to Expert - The Complete Course | Aakriti E-Learning | Skillshare

QA Testing with Agile & JIRA - From Beginner to Expert - The Complete Course

Aakriti E-Learning, Passion to learn and teach

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
43 Lessons (7h 40m)
    • 1. 1 - Introduction to the Course

      13:52
    • 2. 2.1 - What is testing and its objectives

      9:50
    • 3. 2.2 - Why is testing important and principles of testing

      5:12
    • 4. 2.3 - Common terms in testing and what they mean

      13:35
    • 5. 2.4 - STLC quick first introduction

      3:24
    • 6. 2.5 - Testing models

      6:47
    • 7. 3.1 - Different types of testing

      3:58
    • 8. 3.2 - Static & Dynamic testing

      11:45
    • 9. 3.3 - Functional Testing

      7:37
    • 10. 3.4 - Non Functional Testing

      8:09
    • 11. 3.5 - User Acceptance Testing

      5:32
    • 12. 3.6 - Bonus Content - Deep dive into terms that confuse

      7:49
    • 13. 4.1 - Introduction to STLC

      3:47
    • 14. 4.2 - Phase 1, 2 (Requirement Analysis, Test Planning)

      6:55
    • 15. 4.3 - Phase 3, 4 (Test Design, Test Environment)

      4:46
    • 16. 4.4 - Phase 5, 6 (Test Execution, Test Closure)

      5:16
    • 17. 5.1 - Introduction to Requirement Analysis & how requirements are created

      11:45
    • 18. 5.2 - RTM & Test Coverage

      12:12
    • 19. 5.3 - Test Planning

      6:55
    • 20. 5.4 - Bonus Content - Walk through of a real Test Plan

      17:57
    • 21. 6.1 - Introduction to Test case design

      8:27
    • 22. 6.2 - Test Case Design Techniques - Boundary value, Equivalence Partitioning, Decision Table

      19:30
    • 23. 6.3 - Test Case Review & Maintenance, Test Management tools

      8:07
    • 24. 6.4 - Test Environment & Data Setup

      8:33
    • 25. 6.5 - Bonus Content - Lets Write Test Cases (Part 1)

      26:42
    • 26. 6.6 - Bonus Content - Lets Write Test Cases (Part 2)

      12:59
    • 27. 7.1 - When to start testing, When to stop testing

      7:21
    • 28. 7.2 - Test execution, Test statuses & Non-Functional Testing

      14:38
    • 29. 7.3 - What are Defects and how to write a defect

      10:47
    • 30. 7.4 - Defect (Bug) life cycle

      10:32
    • 31. 7.5 - Cost of defect

      6:00
    • 32. 7.6 - Test Execution reporting

      3:14
    • 33. 7.7 - Bonus Content - Let's create a real execution report

      13:27
    • 34. 8.1 - Sufficient Testing & Test Closure

      10:33
    • 35. 8.2 - Product release stages

      11:38
    • 36. 8.3 - Bonus Content - Lets create a release plan template

      11:13
    • 37. 9.1 - Introduction to Agile

      21:43
    • 38. 9.2 - JIRA tool and its importance

      8:17
    • 39. 9.3 - Bonus content - Lets see Agile & JIRA in action

      41:06
    • 40. 10.1 - What is Automation, why it is importance & what to automate

      11:46
    • 41. 10.2 - Automation tools & Process

      6:03
    • 42. 10.3 - Bonus content - Automation framework explanation

      13:05
    • 43. 11.1 - Resume and Interview Tips (Attachments in Project link)

      7:38

About This Class

Why you should choose this course?

1: This course will teach you everything in detail about Software Testing, Agile, JIRA, Automation Concepts & much more.

2: Become a Testing Specialist and get Job-Ready, in only few hours. Collection of 100+ Interview Questions; Resume & Interview Preparation guide to help you ace an interview.

3: Lots of Practical Examples & Projects so you learn how things actually work in real world IT companies.


Advantages of this course:

  • Coverage of all concepts of software testing - starting from most basic to the advanced ones.

  • Filled with real-world examples - how to create a test plan, how to create execution reports, how to create release reports etc.

  • Learn things practically - we will together write test cases for the leading E-commerce website in world, and take a walk-through of real JIRA tool etc.

  • Contents to make you job ready - 100+ interview questions & tips on how to prepare for an interview. And resume template.


Topics you will learn:

  • Everything about testing - definition, objective, principles, models, terminologies & much, much more...

  • Types of testing - with detailed explanation of each type.

  • Software Testing life cycle with deep, detailed chapters on each stage.

  • Agile

  • JIRA

  • Automation basics and Automation framework concepts.

  • Test plan, Test execution report, Release deployment plan etc. creation on your own (as done by test leads and managers).

Thank you and wish you all the best on this learning journey!!

Keep learning & Happy testing!!

Transcripts

1. 1 - Introduction to the Course: Hello everyone and welcome to the first chapter of this dataset deep learning course on software testing. I'm very excited to get you on board this learning journey. And I thank you for choosing this course. As the name points out, this is a2 set deep learning coats on software testing. So at the end of this course, you will have complete knowledge about all the aspects of software testing from the most basic concepts to the advanced ones. Most important discourse is not just theory. We are going to make it very, very interactive and we have kept examples from real IT world like how to design a test plan, how to write test cases for the biggest e-commerce website in the world, how to create an execution report and much, much more. We will also talk about some of the cool stuff testers are supposed to know. Like what is, what is JIRA tune, what is automation and automation framework, et cetera. These learnings will shine in a lot in your resume and differentiate you from all the other applicants. And lastly, this course is not just about teaching, but also getting you job ready. And so we have bonus lectures on how to make a good testing, resuming and around a 100 plus common interview questions that you can prepare before any interview. So as you can see, that is why the name of this course is a2 set deep learning course on software testing. And the best part is you will learn all this in just few days by putting in only couple of hours every day. In only 11 days, you can go from being bigness to becoming a specialist in software testing. Okay, I am sure you are very excited to begin this learning journey and so am I. So let's move ahead. Here is the agenda for our first lecture. As you can see, we are just getting to know the course in this lecture, which is very important to set the momentum, we will mainly see what this course covers and how you can get the best of it. We will also talk a little about myself, that carrier options in testing. And finally, we will end the chapter with the fun interactive activity. So what can you expect from this course? Like I said, this course is a full package. We will of course, learn everything about testing the core concepts that types is stages, et cetera, et cetera. We will also see a lot of other things that are day to day work of a tester. We will see the kind of techniques, processes, and scenarios that testers deal with. We will see what age I l is, what is, what is automation, etcetera. So you know how things operate in organizations. And since I promised to you that this is not going to be yet another textbook course. We will go through some of the real documents is strategies and planning tips that it tester works on in the IT companies. We will also walk through interview questions, resume a creation, et cetera, so you can land up your next dream job. By the way, testing alone comprises around 45% of IT jobs in India. So you're definitely in the right is stream. As you can see, this course is designed for all kinds of audience in mind. The fresh college pass outs, IT entrants and experience pokes the content of this course covers all levels. And by the end of it, you would have the expertise of a test is specialist. So guys, before moving on, I just wanted to give you a brief introduction about myself. I have ten years of experience in testing in manual automation, functional, and non-functional domains. I have worked on and led several testing projects in India and also for several years in us. My email addresses on the screen. So if you ever face any difficulty in this course or anytime later. Or if you have a question, please feel free to drop me an email and I will proactively reply within 24 to 48 hours. You can also post your questions in the Q and a section below. Before moving for what one of the things I wanted to mention was that in all the years of my work experience, the most important thing I have found that we need in this IoT world is to have the Art of up-skilling ourselves to keep on learning new things. So keeper Desire to Learn. Take on any new topic that interests you and keep building up be a learner. Alright, we are ready to jump in. Let's walk through the course content now so you know what's in store for you. So guys here is the course content. And as we go through it, you will notice each chapter is designed for one day of learning. So you can be a specialized tester in ten days. And then on the 11th day we would invest one more day for job preparation contents. That is interview, question and resume. A. If you want, you can do multiple lessons also enter dates entirely up to you. But I will suggest that you make sure you are understanding through it because every topic is very important. Also, as we explore this, You will notice certain items in blue. These are the practical steps designed exclusively to give you knowledge of how things work in the real IT companies. Once again, I don't want this course to be just bookish. We will explore real world examples, real-world documents, tips, and tricks as we go along. So let's take a look at our course content will start with the D1, which we are already on. So we are covering some of the initial topics. And then we will see that career opportunities as a tester. And we will end the day one on a fun activity to get us started on testing. On day two, we will start with an introduction to software testing. So we will know what testing is, what are its objectives, why it is important? What are the principles of testing? And then we will see some common terms that are used in our testing. These terms are also asked a lot in the interview questions, so it's very important. Next, we will see a bit about SDLC, the testing lifecycle. We will see some development models that are used in the industry. On the next day we are going into the types of testing. So as you can see, there are several different types of testing. And each topic is a separate detail in itself. And we are going to cover all of them. In the bonus content of this chapter, we will look into some terms that look very similar, but they are confusing. And they are asked for sure in the interview questions. So we will learn about them that, so that, that helps you into interviews also. The next is the stages of testing lifecycle. So we will cover each state of the testing lifecycle, the requirement analysis, test planning, test design environment setup test execution test closer at a very high level before we go into the day five. And from here we would start each of these stages at a very detailed level. We will see every tiny detail about these stages. What are the different deliverables that come out of these stages? What are the core concepts of each stages? Everything in here. So day five, we would start with requirement analysis and test planning. We will see what requirement analysis is, how requirements are formed. So this is the stuff that you do in association with the business analyst, but it is very important to know. We will see how requirements are translated into the format from which testers can pick it up. We will also look at the requirements traceability matrix. And then we will go into test coverage and test planning. The bonus content of this chapter is a walkthrough of a real test plan. Very important. The test plan is like the planning book of testing, and we will actually create a real test plan ourself. We will look at all the different strategies, planning, etcetera, everything that goes into creating a test plan. The next step is for test case Design and Environment setup. So we would see about how to write test cases. Some of the techniques that we use in test case design like boundary value equivalence, partitioning, etcetera. We will also talk about two other important activities that is reviewing test cases and maintaining them. Next, we will talk about test management tools. What other different tools in the market and what is the rationale behind choosing each tool. We will also talk about test environment setup and test data setup because these are also important for testing, we cannot test without a test environment and testdata. And finally, in the bonus content of this chapter, we will create test cases for an leading e-commerce website in the world. On the next day we would go into execution. So we will start with when to start testing and when to stop testing. So as you can see, there is a logic behind everything and we will try to learn that. We will then see how to execute test cases. What are the different status when you are executing test cases? We will see what non-functional testing is. And then we will go into that defects. How to log defect, defect lifecycle, the cost of defect, very interesting term. And finally, we will take a look at the reporting. So how do we report the execution status and a defective status? Finally, in the bonus content of this chapter, we will create a real-world execution report. This is the kind of stuff that you will send out to their testing managers, the business managers, the development managers, and all the different client heads on your team. The next days for the test closure and production released. So this is also very important concept, but it does not get sufficient attention other places because it's beyond our testing team. In fact, all the teams are party to this activity. The older teams come together to support this activity. But I believe that we cannot be a good tester unless we know all the fine details because every section is a part of the big process. So I have included this topic also here in this course and in the bonus content of this chapter, we will see the real-world example of how a product is released to the end users. Next day we are going to start in the additional content of age island JIRA. And it is very important to know age ILDs days because everybody's using it and it will be a big boost to your resume if you understand the HL process. So we will learn what AGI is, how testing works in AGI. And then finally, we will go into the tool. Again, a very important tool used by a lot of companies these days. So we will learn about Gita. And finally in the bonus content of this chapter, we will do a demo of the Gita tool to see how it works. The next day we are going to take a walk through of automation. So automation is an area that interests everybody who wants to get into testing. And we will see thinks about automation at the beginner level so you can get a boost and you can continue the learnings later. We will also see what is automation framework, which is the biggest topic in automation. And companies pay a lot of money to create these frameworks. And finally, in the bonus content, we will take a walk through our real automation framework. Next day we will go into a job preparation section to get you ready for the job. So how to prepare a good resume and common interview questions. So I have created a package of over a 100 plus most common interview questions. And I have given their answers in very simple way so you don't have to mug up things, your concepts or sound. So guys, as you can see, this is a pretty exhaustive list. I have created it after long planning to make sure that all the good parts are covered in it. And by the end of this, we would be a good tester with the knowledge of all the aspects. Alright, everyone, just like tester has a test plan, we also have a plan for this course. And this plan is what we would be following over the next 11 chapters to make your testing specialist. Ok guys, the second last topic of this chapter is the carrier opportunities in testing. And it is very important to see the road ahead and be motivated. Testing is one of those fields. Debt has seen tremendous growth in the past 20 years and it is still growing in most of the companies today, testing is a separate vertical, meaning a separate full-fledged business unit and not just hidden behind other units. Every day that industry is thinking of new ways in which testers can contribute. Like example, testers can work as developer with their coding knowledge due to automation, or they can work as business analysts with their deep domain and system knowledge. And lastly, there are several freelance opportunities also available. So companies pay you a lot of money to find defects in their system, do hackathons or be a beta tester. So pretty impressive carrier path. And that's why I said in the beginning that you have made a great choice in choosing testing as your carrier or it moving on. And this is the last topic of this chapter. We will do something fun to get us started on software testing. So what I want to you to do is to go to a website of your choice. You can go to Amazon, Facebook, make my trip any website and think about the first thing that you see over there, whether it's the login page or the search page, the find hotels page, et cetera. And then think about all the things that you can test. They're like if you are seeing the login page, you can test valid login, invalid login, blogged login, etcetera. If you are on Amazon, you can search for valid product, invalid product, etc. And in fact, I will give you an example. So guys, I am on Amazon and I am going to search for pencil. But as you can see, I have typed i spelling wrong. So I'm going to go ahead and hit the search button. And as you can see, it not only converted it from the incorrectly spinning to the correct one, but it also showed me the results that are relevant to that search term. So remember guys, the primary skill data tester needs to have is to analyze every part of the application. And the second thing is to have an eye for seeing defects. So let's see how many flows you can think of a spend a good 15 to 30 minutes or more on any website debt you want. And then we will continue on this wonderful journey again. So guys, I will see you in the next chapter to start with the first topic of this course. Till then, keep learning and happy testing. 2. 2.1 - What is testing and its objectives: Hello everyone and welcome to the second lecture of this a to Zed deep learning course on software testing. Today we are going to begin our journey into the starting concepts of testing. We will see what is testing and its objectives. We will see why testing is important. What are the principles of testing? Next, we will go into some common testing terms, which is a very important point for interview questions and it is always asked there. Next we will see software testing lifecycle, which is the entire testing process. And lastly, we will cover testing models like waterfall model, V-model, Read model, Spiral model, and the most famous nowadays HI EL model. So now that we're clear on the agenda, let's move ahead and start learning. So here's the first question that comes to our mind when somebody says the word testing is what exactly is testing. Now there's an official definition for testing. But before we go into it, let's think of a few things that come to our mind when somebody says The turned a word testing. So first thing it is the process of verifying and validating a software, website or application. Note the keywords here. First, testing is a process. It's not as standalone activity, it's a process which means it's a set of defined activities that we have to follow. Second, it's about verifying and validating. And remember these are two different terms that we will see. What is their meaning, what is the difference? But for now, remember that testing is both about verifying and validating. Third, it's applicable to software, website, applications, anything around us, even there is testing of food devices, aeroplanes, etc. But we are only talking about computer world here, so I have written software, website, and application. Second thing, testing is ensuring data product is bug-free. And as you can see, this line comes with two biggest stars. These stars are like a disclaimer because there is no product or software, or device or application in this world that is bug-free. Most people think about testing as confirming that there are no defects, but it can simply never be true, even if it has something a million times over, there would always be bugs in it. And we will see more about this in the later state, the principles of testing. Third, ensuring that the product meets business requirement. So the business requirement is like go to Amazon.com website, search for any product, click on buy and then order should be placed. So that is the business requirement. Of course, there are a lot of other flows around it that we also have to test. But the primary thing is to make sure that this particular business requirement is validated. For thing the product meets technical requirements. So just like we saw in Los, last comment about business requirements, that is given by the business team. There are technical requirements also debt are given by the development team. For example, the source should use a keyword driven elastic search technique, etcetera. So as a test to remember to think about the technical requirements, also touch base with the developers. Ask them to technical requirements because that would also affect the quality of product and the testing scenarios. And last thing, ensuring that the product handles all use cases efficiently. So this is a very important concept, especially the efficiently part. And I want you to think about it for a minute. Let's say Amazon.com has a business requirement of searching products, like we saw in the last lecture, which works fine. The technical requirement of searching is also met. Let's say everything is very good, everything is very robust. It searches very quickly. But if that search box is placed in the bottom of the page, instead of being at the top, do you think that it is good end-user would go and use it? Absolutely not. So as a tester, always remember that we have a duty towards the end user and we have to make sure that the business requirements are user-friendly. This is what we call as usability. It's a very important term in today's world. We are good design concepts and ease of use is very necessary. And so you would see me often talking about this usability aspect, which I think other courses enter testing community in general ignores, but it's very important mindset for a tester. So let's repeat the concepts one, again, testing is a process of verifying and validating a software website or application. It is done to make sure that the product remains free from bug. It is done to meet the technical requirements, the business requirements, and the handling of the use cases. Okay. So now that we know what is the terminology to make her about testing, let's think about what is the official definition of testing. So this is the official definition of testing given by the IST QB, which is the International Software Testing qualification board, and it's an institution for testing. So I ST QB says that testing is the process consisting of all life cycle activities, both static and dynamic, concerned with planning, preparation, and evaluation of software products and related work products to determine that this satisfy specified requirements, to demonstrate that they are fit for purpose and to detect defects, right? So sounds pretty impressive, but what does it mean exactly? Let's break it down and try to understand it. So there are couple of things here. First, as I said in the last slide, testing is a process. It's a lifecycle of activities. It's not a single thing, it's a process consisting of many different activities. We call those activities as the software testing lifecycle, and we will see what those are later. Second, both static and dynamic. So these are two forms of testing. They are related to non execution and execution, and it's a high level of classification of testing types. So we will see it further down in the next chapter. But for now, just know that testing is not about executing the code, verifying the dynamic activities. No, there is a static part also. We have to do some activities without even execution to make sure that things are good. Third, concerned with planning, preparation, and evaluation of software product. So these are the stages of SDLC. Planning means test plan, preparation means test design, environment setup, etcetera. And evaluation means the execution phase. Final part to determine that this satisfy requirements to demonstrate that they are fit for purpose and to detect defects. So this is what we already discussed in the last slide. Testing is about verifying the requirements are met. To make sure that the product remains bug-free as much as possible, and to make sure that the product conforms to user friendliness. So now that we know the official and generate definition of testing, you can use it in any of the interviews or anywhere else. And in fact, you don't need to mock up the definition. You can say it in your own words also, just be sure to include number one, it's a process, it's a list of activities. Number two, it has types like static and dynamic. And number three, it involves checking requirements, suitability of product, and finding defects. All right, so now that we know what testing is, let see what are its objectives. So guys, why do we do testing? What is the objective behind it? Let's think about some reasons. So number one is, of course, bug detection. If you are a tester, our primary job is to find defects, functional defects, requirement defects is ability defects, all of them. The second thing is bug prevention. So this might seem contradicting to you is our job to detect effects. So it's our job to prevent defects. Well, our job is both. Remember as a tester When you find defects, you help improve the product and process and ensure that same type of defects don't happen again. So it is our responsibility to make the process robust to prevent that the same kinds of bugs are not happening. So much job is boat to detect the bugs and to prevent them also. Third, assure quality of software products. So testers are the guardians of quality and it's our job to make sure that the product adheres to highest standard of quality. Fourth, increased customer satisfaction. So imagine that somebody comes to Amazon.com. They tried to search for laptop and boom, the search, the site simply blows up. So the customer would not be happy, it would not make the purchase. So in a way, when we're testing things, we are increasing the customer satisfaction also. Fifth, increased security, usability performance. So these are the non-functional tests, testing aspects, and we will see each of them in detail in the next chapter. But for now, just remember that testing is not about just verifying the functionality. We have to verify the non-functional aspects also, for example, let's say site is working very good, but it is not secure. It does not handle your credit card data nicely. So then nobody will buy from it. Or let say data site has a very robust searching method, but it takes ten minutes to search a particular product. So again, nobody would use it. So it's not just important to test the functional aspects. The testing of non-functional aspects is also important. Next one is to reduce costs. So let's consider that there is a defect on the travel website like jatropha or make my drip, where it books ticket of January one instead of the deep debt user entered. Imagine how much it would cost the company to fix that defect, how much it would cost to fix their reputation and reliability. So this is a very interesting concept. It's called the cost of defect, and we will see it in chapter seven. And good testing can help to reduce that cost. And last point, improvement in process. So if testing is properly planned, if testing is done from the beginning, etcetera, it leads to improvement in process and better the process better the end result. Sounds good. Alright, so now we know what testing is, what are its objective? In the next lecture, we are going to explore why testing is important and what are its principles. So I'll see you in the next lecture. Till then, keep learning and Hep-C testing. 3. 2.2 - Why is testing important and principles of testing: Hello everyone and welcome to this a2, say deep learning course on software testing. So guys, let see why testing is so important. And let's discuss this one as a story. So you would think that testing is such a big industry today and it is so recognized. But if you go back to 19 eighties or 19 nineties, nobody taught of testing. There was no such thing as a testing team thinks were developed and even launched. If and any little testing was done, it was done by the developers themselves. Then in late nineties, people started to feel the importance of testing, and then it grew and grew to where it is today. And testing nowadays is a very important part of product development with lot of focus. So there are three incidents that I wanted to share that explain why testing is important. The first one is of the nasa Mars Climate Orbiter failure in 1999. And it was almost $125 million loss. And you know why it happened? Because one part of software was written for matrix system and the other part was written for English system. And when they integrated few feet above the surface of Mars, the crashed and dad brought down the entire rover. Second example is from recent times, two plane crashes of Boeing 707 MAX due to faulty flight control software, and almost 346 people lost their lives. So this explains why testing is so important and what could be the consequences of a small Miss. Third example is a very famous e-commerce website. It goes down for a few hours and there's millions of dollars of loss. And I covered this particular example because it's not just important to test the functional aspect, the testing of performance and securities also important. Performance testing or load testing is a very important thing in today's world. You can give it a shot to become a performance engineer if it interests you. Okay, you can read about more about these incidents on the internet if you want. But I think it pretty much covers the topic of why testing is important. The entire world understands it today and companies pay sufficient attention to testing now or at moving on, let's see the principles of testing. Very cool topic. So this is the part where we will see what are the seven principles of testing. And people often say that token, let's test this, let's test dat, let's find defect. But what is the principle behind our work? And the principles are, number one, testing shows presence of defects. So like we discussed earlier, any amount of testing can never guarantee 0 defect in any system. So testing is about finding defects and showing that they are present and not proving data product is defect free because it can never be. Second, exhaustive testing is not possible. So if we take a simple example of the login box on facebook.com, there can be so many combinations in it. We can test it by numbers, alphabet, characters, alphanumeric.com, dot net dot in, etc. So if we start testing all of them, it would take us a lot of time and the application will never be ready on time. So it's not possible to test everything exhaustively. Rather, we have to consider risk, cost, time, et cetera. There are techniques like boundary value analysis, equivalence, partitioning, et cetera, which helped to design the optimal combinations with the minimum number of test cases and we'll see them in the later chapters. Third is our lead testing. So always remember that testing should start as early as possible. It's cheaper to find defects suddenly, it's quicker to fix them early. So we should try to test as much as possible early instead of doing it at the later stage. Fourth defect clustering. So this is based on the Pareto principle, which means that 80% of the defects will be present in 20% of modules. So complex modules, related modules, frequently changing modules, etc. These 20% modules will contain the 80% of defects. Number five, pesticide paradox. So this one is my favorite because it talks about improvement in things. So as the name suggests, let's think about a farmer. He keeps using the same pesticide over and over again. So after some time the insects will become immune to debt and it won't work same way if we keep running the same test cases again and again, it will stop finding defects after a while. So it is very important to continuously review our test cases and maintain them. Next point, testing is context-dependent. So this means data testing approach is different for each application. The testing that we do for an e-commerce website is different from the testing that we will do for a mobile app. And last absence of era's fallacy. We tested the software thoroughly and we find large number of defects in it. But what if the requirement on basis of which we were testing itself was incorrect? What if the system does not meet user's requirement? So data is called as absence of errors policy. And how can we resolve it by Principle number three, early testing. So guys, in this lecture, we learned about the importance of testing and the principles of testing. In the next lecture, we are going to continue with some terms about testing. So I'll see you in the next lecture. Till then, keep learning and happy testing. 4. 2.3 - Common terms in testing and what they mean: Hello everyone and welcome to this a2 set deep learning course on software testing. So guys, in this lecture we are going to go over several testing terms. And these are the terms we hear a lot when we talk about testing. And they are required before we go into more details of testing in the next chapters. So it is important to cover these terms now and also remember very important, a lot of these are asked in the interview questions also. So let us start. The first term is error. And error is a mistake, misconception, or misunderstanding made by humans that leads to discrepancy. The next one is defects. So defect is nothing but the variation between the actual result and the expected result. Next we have the bug ticket or incident, and these are nothing but the synonyms of the word defect. Different companies use these words in place of defect. For example, some companies call it a bug if it is detected by real users. Next we have failure. And failure is anything that causes the software to fail to perform its required function. So guys, you will hear these four terms a lot and they are related, but they are a little confusing. But I will tell you what is the difference. So there is one thing that we humans are very good at, and that is the art of making mistakes. So when humans make a mistake, that leads to some discrepancy, it's called as error. Now when an error will happen most of the times you will not get the expected result. So this difference of expected result and actual result is called a defect or a bug ticket incident, et cetera, and different organizations. Finally, when an error happened, so what defect happened? Our software will not do what it is supposed to do and that's a failure. So remember the order and then things would be clear. Error leads to defect or bug ticket incident and these lead to failure. So I believe it's very clear now let's look at the next term. So the next term is debugging. And debugging is the process of finding, analyzing, and removing the causes of failure in software. So when there was an error, when a defect happened, when a failure happened, we would have somebody from the development team look into it. What was the root cause? What was the cause of failure? So the developer would go into his codebase. He will try to find the root cause and fix it. So dat is known as debugging. It's mainly at deep developmental and it's about finding the cause of failure. So this was all about error, defect, bug, failure and debugging. Let's move on. So the next term that we are going to see guys is verification and it's close sibling, the validation. So these are two terms that are asked for sure in any interview question. Verification is the process of evaluating the work product. Remember not the final product to determine whether it meets the specified requirements. So it's a way to check that are we building the product right? Whereas validation is the process of evaluating software during or at the end of development process to determine whether it satisfies is specified business requirements. So it asked the question, are we building the right product? So let me give you some more differences. Verification is checking the documents, designs, quotes, etc. Whereas validation is testing the actual product. Much of what we do as a tester. Second verification is the non execution testing, which we call as the static testing. Whereas validation is the execution testing, which we call as the dynamic testing. Also remember that verification happens before validation. So these are some of the differences between verification and validation. You can tell these differences in the interview. But as long as you can just say the line debt verification is are we building the product right? And validation is are we building the right product? The interviewer will know that you know the difference and you would be good. Alright, next up, black box testing. So black-box means guys, a closed box. You cannot see what's inside it, you cannot see what's happening. So that's why black-box testing means that you are simply giving the input, which is your test criteria, and you are getting an output that test result. Then you compare that output with the expected result to make sure that it matches. Otherwise it's a defect. So again, you just test on the basis of these things. You don't care about the internal details of the system, how it works. Next is the opposite of black box testing. So white-box testing. So here we know the details of the system. It's some white box we can see inside the System what is its structure. And this is more of a code testing. So we are actually going inside the code and we're seeing how it works. And these are two different techniques of testing black box and white box. And we will look at them in more detail in the next chapter. Next up we have CERT and priority. So again, two very related terms. So severity is the degree of impact the defect has on the functionality. So how much it is impacting the functionality, whereas priority is how quickly the bugs should be fixed. So if I tell you in a different way, severities the functional importance, how much, how much that defect is breaking the functionality, how much it is impacting the user for the functionality and priorities, the business importance that how soon this defect should be fixed. Also remember that C Viet is decided by the testers and priorities decided by the business managers. Now remember guys, whenever they ask you about the CBOT or priority in the interviews, they will also ask you to give you, give them some examples like what is a high severe te, defect? What is a high priority defect? And more importantly, the cross area. So what is low severity but high priority? High priority but low severe t like that. So let's look at some examples now, before we go into the examples, remember severity is functionality and priorities the importance. So if there is something that has both high ECV at high priority, what would be the example of it? Let's suppose that we go to the website, Facebook.com and the Login is not working. So if login is not working, it is impacting the functionality. Users cannot log in. It's also impacting the business because if users are not able to login, company would lose money. So that's a case of high severity and high-priority. Next thing, What is low severity and high-priority? So this is something that would have a very minimal functional impact because it has low severity, but it would have a very high impact for the business. So let's save the company logo is not coming if you go to Amazon.com and the logo is not coming at the top. So the tester would say that, okay, it's low CV or teach, not impacting any functionality. People don't click on the logo a lot so it's low severity. But the business would come up and say that know our business is not getting represented. The people think that OK, the logo is broken, maybe the site is hacked, maybe it's not working correctly. So from the business point of view, it would be a high case area. So Datsun example of low severity and high-priority, both these cases that you see in the top bucket would be something that the business would want to fix as soon as possible because they are the high-priority areas. Next, what is high severity but low priority? So we saw the example of login with the login was not working on facebook.com. Let's say that this seemed organised, not working, but on a page that sits inside a page and sits inside a page, let say five levels down the line. So users go to customer surveys, then they click on Help menu, then they clip, click on terms and conditions, then the click on privacy policy. And there is a login button that is not working. So the tester would say that it is high-priority, login is not working, but business would come back and say that it's happening on a very low level page where the user is going after lot of navigation. Plus if they want to login, there is always a Login option present at the top of the page. So from a business point of view, it's a low-priority defect. So that was the example of high severity and low-priority. And the final thing is something that is low severity and low priority. So it could be like a spelling mistake on the terms and condition page or a simple message that is not coming correct on some of the low-level pages. So data is something that is not having any functional impact and it's not impacting the business also. So it's something that the business would not like to fix immediately. It's a low severity and low-priority defect. So anything that you see at the bottom of this matrix is something that is not a priority. It would be fixed maybe in the later releases or it would not be fixed at all. Now coming back to our slide, let us look at the next terms. So the next term is risk, and risk is the probability of an event, hazard, accident, and its impact. So when we say about risk, it's nothing. But number one, the chances of occurrence of any event. And number two, what is the impact when that event happens? So you multiply these two factors and that is the risk. So guys, risk and testing is something that are very closely tied together. Because as we discussed in the principle of testing, we cannot test each and everything because of lack of time, cost, people, et cetera. And number two, each failure or defect when it happens it carries a risk of money loss, customer loss, et cetera. So whenever we talk about testing in some way or the other, we are always doing a risk-based testing even if we don't know it. And in fact, the next term in our list is risk-based testing. So risk-based testing is nothing but a testing method that is done on the basis of importance of a feature or component and it's likely chance of failure. So we cannot test everything. We do not have the time to test everything. We do not have the cost of people to test everything. So what we can do is we can do a listing of all the features on that website. We can give it a score based on how important it is for the business. And we can give it a score or on how much the chances are, therefore its failure because. Something that is not a stable, it's something that is undergoing a change, etcetera. And then we will multiply these features and it would give us a score for that feature. So higher score, higher is the risk of that feature, higher is the priority of that feature. And we will test the features with highest score first. So this is a very nice way of testing. It's called as a risk based testing. More and more companies are exploring this option. So as I said, that testing is something that is always revolves around risks because we cannot test everything. So risk-based testing is a thing that is gaining momentum. You can read about it online. It's a very nice thing. Next thing is a static testing. So static testing is that testing of a component or system without execution of software. So this might sound like a new concept to you, and we will read about these types more in detail in the next chapter. But it's not just that when we have to test something, we have to execute the code. Know, there is a lot of testing that we can do without even executing the code. Like we can review the documents, we can review the code, we can take a walk-through of the scenarios, et cetera. So that is what is known as the static testing. And because I set that testing should start as early as possible, is static testing is an important thing. We will see more about it in the next chapter. Next is its sibling, dynamic testing, which is opposing static testing. So in a static testing, we wet our testing something without executing the code. In dynamic testing we are executing things by executing the code. Next thing is a jail testing. So this is a very famous term that you will hear in the IT industry nowadays. In fact, HIT is the most common used methodologies nowadays. And it's very important to know how to be a test or in the Agile world. So we have an entire chapter dedicated to H and G dot tool. And so just to give you a summary, a gel is a testing practice that is based on each aisle methodology. So it believes in designing products in a smaller cycle called as a Sprints, so that we can cater to that quick product requirements and it follows those prints into releases. And then we do incremental releases for adding more feature or bug fix as we'll talk about it in detail. But just to give you an idea, it's a very good concept. It's a very important concept. It's gaining too much importance in today's world. And the last term is continuous testing. So again, you would have heard or you will hear about this term, DevOps, CISC, D, et cetera. So it's not like old days. We are we waited for many days to be for things to be ready and test them. Today in IT world, everybody walks on, HI, everybody wants continuous testing and everybody wants to release their product as soon as possible. So continuous testing means that we have to test early. We have to test more often, we have to test everywhere. And because there is such a high demand, how can we meet it? Obviously by automation? So guys, we looked over a bunch of dumps. It's okay if you want to circle back and read them again, some of them we will cover in more details in the next chapter. So what I would suggest you to do is make notes about what we're learning here so you can reference them in future quickly before an interview. And for topics like verification, validation, CERT priority, which are very common. They are asked for sure in any interview, you can create a table wise comparison. We will again cover these topics in the interview questions so that there would be a quick reference guide for you, but you can see them also now. Alright, so we have covered some common terms and now we know what testers talk about all the time. In the next lecture we are going to start with the process details and learn about SDLC. So I'll see you in the next lecture. Till then, keep learning and Hep-C testing. 5. 2.4 - STLC quick first introduction: Hello everyone and welcome to this a2, say deep learning courts on software testing. So guys, let's take a look at SDLC Now. What is SDLC and why is it important? As we talked in the beginning of this chapter, testing is a long process and it includes several steps that have to be done in a predefined sequence. So dat is what SDLC is. Sdlc is the testing process with a specific steps to be executed in a predefined sequence to ensure that quality goals are met. So again, a lot of words in here, let's process them. If you see that here, SDLC is nothing except of VA to make things organized, efficient, and rule-based, which is what we call as a process. So SDLC is nothing but a process. And this process is important to get quality results on time. What we are doing, we are breaking things into smallest stages. We are setting what are the rules for each stage we are defining when we can go from one stage to another, which is called entry and exit criteria debts, all SDLC is all about. So SDLC consists of six phases, and we will see what those pieces are in the next slide. Second, the phases have to be followed in a predefined sequence. So it's not like we can do phase one, go to Phase five, then come back to phase two. No, it has to follow the predefined sequence. Third, all phases are necessary to achieve desired results. So it's not like that we can skip one step. No, all phases are necessary. All phases have certain objectives and we have to make sure that we are doing all the phases. Next point, SDLC is a part of overall SDLC cycles. So software development lifecycle is a methodology for product development. And SDLC is mod, is small subset of debt SDLC process. And last is used by the testing team only. So the business team or the development team, they do not use SDLC. Sdlc is something that is used by the testing team only. Or it Now we know what SDLC is. Let's move on to the next slide and let's see the phases of SDLC. So these are the phases of SDLC and we will revisit each of these phases in detail later. For now, just know the name of the phases. So the requirement analysis, test planning, test design or development, environment setup, text execution and reporting. And the last one, test closure. So guys, this is the SDLC process. And once you know about each of these phases in detail, you would have understood everything about testing. Once again, we are going to re-learn SDLC in more details in chapter four with an understanding of each phase. So SDLC is what would allow us to learn testing overall. So this course is built around the concept of SDLC. We are taking a very quick peek into SDLC now in chapter four, we will do a little bit more detail and is starting chapter five, we are going to cover each of these pieces individually in detail. So now you have a fair idea of SDLC and also what is going to be the flow of this course. However, there are few things that we still need to cover before we can go into SDLC or the next chapter. So that's what the last part of this chapter is, and that's what the entire chapter three is going to be about. So let's wrap up those things before we move ahead in the next and last part of this chapter, we are going to see what other testing models, and it's going to be a good study. So I'll see you in the next lecture. Till then, keep learning and happy testing. 6. 2.5 - Testing models: Hello everyone and welcome to this a to Zed deep learning course on software testing. So guys, we are in the final part of chapter two, hour day two of learning. And we are going to take a look at some of the common testing models. But before we start, what are these testing models and why they are important to know. So testing models are nothing but approach used in the software development process. So each company wants to develop a software, they want to develop a product so they can use one of these methodologies. And each of the, each of the company follows one of its own model that they use. Each model has its own advantages and disadvantages. And remember, even though these are the software development models, each of these model consists of testing at one stage or the other. And there is a variation in the approach. So let's see what the models are, what is the testing inside them? Now the first model that we are going to talk about is waterfall. So waterfall model was the most basic model. It was used by a lot of organizations. And if you speak to somebody who was in the IT industry ten or 15 years ago, like me, waterfall was what everybody was using and companies is still use it. But now more and more businesses are shifting from waterfall to h i. So this is what the waterfall model looks like. As you can see that it resembles a waterfall, hence the name. And it has five stages. The first one is requirement, where the business requirements were formed, then you have designed where the initial design document was made. 30, you have the implementation where things were coded. And next you have verification or testing. And the last stage when everything was successful, the product was launched and it went into maintenance phase, meaning newest of where, again done in Waterfall Methodology and edit to it. So as you can see guys, it was a very simple model. There were clearly defined steps, but the problem was with these clear separations only once you go into later phases, it was very tough to make changes. For example, if you are in the verification phase, the testing phase, and you realize that there is some gap in the requirement. The requirement has to be changed, then you would have to go all the way back to the requirement phase and redo everything again. Second thing is that each of these phases we are segregated. So you cannot just start the next phase until all the previous phase was completed. So this was the drawbacks of the model, is still, as I said, it was a very simple model. It was used a lot, but it could not adapt to the changing market requirements. So companies decided to shift from these waterfall to the HL model. No. Next, the next model that we can talk about is the V model, which was superior to waterfall, but it wasn't rigid model. So this is how the V model looked like. And as you can see, it's a V-shaped, hence the name. And you can also see that each stage corresponds to our testing. So there's our testing activity defined for each state and it is done in parallel to the development. So there was good testing coverage, but again, this model was very rigid if there was any change needed. So for example, if we want to make a change in the high level design, then it means that we would have to rethink about the whole testing strategy. So again, one of those models that was good, that serve the industry for a long time, but it was not open to changing requirements. The third model that we are going to see is the rapid application development or red model. And this is how it looks like. So as you can see this model, in this model, the components were developed in parallel. Like example team one was working on one component, TM2 was working on second component. Team three was working on third component. So each, each team designed components in parallel, and finally they were integrated. So there were quite a lot of good things about this model. You can do developments in smallest, small modules. You can reuse those modules. Are the customer had something to show C at a very early state, like a prototype. But at the same time, this modal was something that could not be adapted to all the products. It can only be used for systems that can be modularized, that can be developed in smallest, small chunks, it required a specific skill sets you would need developers debt could design things that can be finally integrated. So there were some drawbacks into the model, but still it was a pretty good model. Now the next one is a spiral model, which was used for complex system and it was focusing on risk analysis. So this was the Spiral model. And as you can see, each phase of it was divided into four quadrants. And there was a loop between all the phases. So we first faced was that we determined objectives, then we identify risk. Remember it's a risk-based model. The third phase was that we develop and test it. And the final phase was to plan the next iteration. So it was a very complex model. It was used for large product only and you don't need to understand it in complete detail. Just remember that the spiral shape of the model and data, it was used for large and complex projects only. And finally, let's talk about the most favorite model, the HI EL model. So it's the most common model that is used nowadays and it ensures continuous development in line with changing business requirements. So this is the how the HI EL model looks like. And as you can see guys, the problem with most of the models that we discussed earlier was that they were not adaptable to changing requirements. And in today's world, customers requirements are changing very quickly. They need something that adapt to the changing requirements. So that's why the HL model is so popular. And we will cover this picture and H L model in detail again in chapter nine. But for now, just know that a child basically does is small cycles called sprints of planning requirements, developing them, testing them, and releasing to the customer. So everything is done in smallest, small cycles. And that's why this model is so good and changing to add in adapting to changing requirements. So we do things in small chunks, be released them. And in the next iteration we again do things with more improvements and bug fixes. So guys, this was the age I L model and display all the testing models that we had to discuss. So this brings us to the end of chapter two. We learned, caught a lot of cool things about testing, especially its definition, objectives, and principles. We will make use of these techniques as we progress through this course. But remember our discussion in this chapter, especially the objectives and principles of testing. Because the entire process of testing is based on these fundamentals. Once again, if you have any questions, please post them in the Q and a section or you can email me also. We will now proceed to chapter three, which is on the types of testing and continue our learning journey. So I'll see you in the next chapter till then, keep learning and happy testing. 7. 3.1 - Different types of testing: Hello everyone and welcome to the third chapter of this a to Zed deep learning course on software testing. So guys, this is the day three of our learning and today we are going to cover the different types of testing. So let's begin. So in this lecture we will see what are the different types of testing. What is static testing and dynamic testing? We already saw their definition in the last chapter. Now we will go in more details and see what they are. Next we will see functional testing followed by nonfunctional testing, and then User Acceptance Testing or annuity. And lastly, never bonus content, which is deep dive into terms that confuse. These are the terms which are, which look very similar but they are different and therefore Sure asked in interviews. So we're going to cover a couple of those terms in the bonus content of this chapter. So let's proceed. So let's start with what are the different types of testing? And remember when we said types of testing, we are not talking about testing on different applications like a website or software or mobile apps? No, we are talking about the types of testing. So these types remains same irrespective of wherever we are testing. Now there are several types of testing. May be more than a 100 if we start counting. But what's common in all these types is that each of them has a specific objective. Meaning why we do that particular testing. Each of them has a clear stage of implementation, meaning when we would do that testing. There are also types of testing depending upon who's testing. So for example, who's the actor? It's not always the software tester who's validating things. You might have heard about the beta testing which is done by end users. So there are types of testing based on technique, which is a static testing and dynamic testing. We saw in the last chapter that is static testing is the non execution testing and dynamic testing is the execution testing. So these are the two types of testing based on technique, and we will see them in detail in next slides. Next, there are testing types based on his stages. So smoke testing, sanity testing, regression testing, performance testing, etcetera. Remember, these are all dynamic testing techniques. So if you classify them by technique, then they will be dynamic testing. But here we are classifying things by stage. And lastly, there are separate testing based on actors, as I mentioned earlier. So alpha testing, beta testing, AB testing, etcetera. And we will also see in the detail in this chapter what they are. So moving on, let's look at the types of a testing from a high level diagram. So remember in here we have divided testing types by static and dynamic methods. So there are of course several other ways also to divide testing. But for now we have classified them first-level into two types, static testing and dynamic testing. The static testing includes reviews, walkthrough, inspection, etcetera. So this is the stuff that you do without execution. You review the code, you'll give a walk-through of the code, you inspect the code, et cetera. And then the other type is dynamic testing. So this is further categorized into white box and black box testing. We already learned in the last lecture what is white box and black box. And we also learned that white box involves the code testing. So in whitebox we have subtypes like data flow, control flow, etcetera. We are basically testing the code. And in black box we have further categorization of functional and non-functional testing. So guys, this is a very broad classification of testing and it's a very concrete one. There could be many other ways to classify testing types and each one of them is okay as long as we are covering each subtype. But in this course we will use this particular classification because it is very detailed with focus on each type. Okay, now that we know this high-level classification of testing types, what we are going to do next is go into detail of each of these blocks and explore them what they are. So beginning the next lecture, we are going to start with the first level of classification and then move on. So I'll see you in the next lecture. Till then, keep learning and Hep-C testing. 8. 3.2 - Static & Dynamic testing: Hello everyone and welcome to this a 2-SAT deep learning course on software testing. So guys, in this lecture we are going to start with the first level of classification that we saw, which is static and dynamic testing. So let's see what the R. So what is it static testing? The definition says it is the testing that does not require execution of code. So static testing is used to check the code requirement documents and design documents for error. This is a verification testing to find defects early on in the development cycle. Now let's break it into small pieces and understand, if you recall our first lecture, one of the first principles of testing that we discussed was early testing. And that's very static testing comes into play. So we do not want to wait until everything is ready we are doing the testing does not even require execution of code. Next thing, what are the things that we are checking here? We are not executing the code. So what we can check, we can look at the code, we can look at the requirement documents, we can look at the design documents and verify them. So it's basically making sure that your requirements are correct. The code coverage is good and the quality is correct. And finally, this is a verification techniques. So we talked about verification and validation in the last lecture. And a static testing is a verification technique. So three things about is static testing. Number one, it does not require execution of code. Number two, it checks for code and documents. Number three, It's a verification testing. So let's see what other types of starting testing there are four types. Number one is inspection, so it's a formal type of review of any artifact like code, test cases, documents, et cetera. As you can guess by the name it's inspecting. We are inspecting something. It could be the document, the code, or the test cases. Now these inspections are done by your moderator and there is a checklist that he reviews with it. So what is this checklist? It's a quick guide example. The checklist will contain best coding practices of the organization. Moderator will inspect based on debt. And lastly, this remember that this is a formal review, so everything that is being done would be documented. Number two is walkthrough. So the owner explains the product, the participants get to know about it or ask questions. There is a guy called scribe who notes that detail. So again, as the name suggests, in walkthrough, the owner is taking everybody down through the product, explaining its detail. People are getting to know it. People are asking questions. And we have a person called as describe who's taking notes to discuss it for later, to document it for later. Next type number three is technical review. So our review of the code to ensure that it meets technically specification and distended. Now this is a more technical oriented term and it checks for a specification and also whether the coding standards are met or not. So it is done by the development folks, the development manager, the developer group ex cetera. Number four and last one is an informal review. So in these documents are reviewed in formally and also in formal comments are provided. So this is like you put the document out for everybody to read. There is no formal meeting. There is nobody explaining what the document is like in the walkthrough. People will read it on their own. They will send their comments, they will send their feedbacks. They can come over to talk to you. It's all informal. So guys, this was all about static testing. Once again, remember, most important, this is the non execution is stuff. We're not executing the code. We are doing the verification without execution. And what are the things that we can verify without execution? We can verify the code, we can verify the requirement documents. We can verify the design documents. And how can we verify them? We can verify them by reviewing. So that's what is static testing is all about. Okay, so we covered a few things so far. Let's take a short diversion and talk about something practical that will help us in their daily work. So let's talk about two terms that we used here. The first one is checklist. So I strongly suggest you to always have a checklist of things in testing. Now this term of checklists was matured by nasa and now it is used worldwide. Even we also have a checklist in our personal world. So for example, when we are leaving the house, we check for the lights, the AC, the fan, that door, etc. So that is a checklist. It's basically a series of steps that we do before getting into anything. So if you ask about testing, the checklist could be like requirements checked, test cases checked, test data checked, et cetera. Or you can create a checklist to verify a quick list of things that we can check every day on the website or application, just like we are checking things before we go out of the house. So it's a quick and great way to make sure that things are good. And I recommend that you explore checklists when you'll become part of any organization or in your daily work if you are already into the IT world. Second thing that we heard about on this particular slide was the word is scribe. So is scribe is a record keeper who's documenting things. Now testing is lot about captioning requirements and verifying them. And one of the things about requirement is that the change frequently nobody remembers think ten days or two weeks down the line. So whenever you are in a meeting, discussion, review, et cetera, always take notes. If it is a client meeting or entertain meeting, document those notes and send them an email later. It would serve as a record for everybody. You can go back and reference it later if you have any questions. So it's a very helpful thing. So these were my two tips from my work experience that I wanted to share. Now let's get back into the world of testing and continue to the next topic which is dynamic testing. So this is the next type of testing that we have. It's called as dynamic testing. And as you know from the last chapter or as the name suggests, this is the type of testing that involves execution of code. So the definition says this type of testing involves execution of code. Most important thing. The tester provides an input, records the output, and compares it with expected result. Apart from checking functional behavior, the performance, usability, security, et cetera, of the system can also be checked. So this is the official definition. Let's pull out the most important things from it and understand. So first and most important dynamic testing is all about execution, your execution, and you are executing the code for the purpose of checking. And when you're executing, you will give the system and input. And you will report the output node, the output that it returns. You will compare that output with the expected result and that will show you whether it passed or failed. So remember, we are, when we are talking about execution, we will compare it with the expected reserves to make sure that things are good. And we will not only talk about the functional aspects, we will not only be testing the functionality, we will also be talking about non-functional aspects like performance or security or usability, et cetera. Next, what are the types of dynamic testing? So there are two types of dynamic testing, white box and black box. So let's recap them again from the last chapter. And as you can see, this is sort of via explained the Thompson last chapter, that you have a head start in the course. So we note that whitebox means something which you can look inside. It's a temporary Bach, it's a transparent box, sorry. And blackbox means that it is not transparent. You cannot look inside it, you cannot see what's happening inside. So in white box testing method, the internal structure of system is known. It is done by the developers and the type of white-box testing our statement, coverage, loop, coverage, path coverage, etcetera. So basically you are going inside the system at a code level and you are executing things. You are checking if all the statements in the code are covered, you are checking if all the flows in the loop, the if loop, the else loop, the while loop, etcetera. You are covering the path of the code. So again, you are executing things number one, most important, and number two, you are doing it by tracing through the code that testing, this testing was originally done by your developer. But now there are testers also that are doing the white-box testing. And there are a lot of tools in the market that would help you in this testing. The next type of dynamic testing is what is most common in the testing world, and it is called as black box testing. So the system, your website, your application, think about it as a big black box. You don't know what's happening inside. You don't keep the internal structure. You just give input, you get output and you check it. No inner details are mattering. So in this method, the internal structure of the system is not known. It is done mainly by the testers, by the BA or even end-users. That type of black-box testing, our functional testing and nonfunctional testing. So like I mentioned several times in black box, you are not just checking the functional aspect. You are also checking the non-functional aspect like performance, security, et cetera. And they are equally important. Ok, so we have seen our first testing categorization is static testing and dynamic testing. Let's recap it quickly in the next slide. So guys, this is the difference between static and dynamic testing. Remember the first, the most important is static testing is done without executing the code. And dynamic testing is done by execution of code. So if somebody asked you what is the simple, the most one-line difference between both. This is the difference is static testing is done without execution of code, and dynamic testing is done by execution of code. Second thing is static testing is done at early stage of development, whereas dynamic testing is done at the later stage. So remember, we talked about it in the first chapter. Also, early testing is very important. So that's why static testing is a very important testing concept. We are checking things early. We are trying to find defects early because it would be cheaper and quicker to fix them. Next is static testing checks the code requirement documents, design documents, et cetera. Whereas dynamic testing checks the functional working of software, along with the non-functional aspects like performance, security, et cetera. So particularly, just remember that in a static testing, we are not executing the code. So what we can check, we can check the walk-through of the code. We can do the walk-through of the requirement documents. We can look at the design documents, etc. But in dynamic testing, we can look at the functionality as well as the non-functional aspects because we're executing things. Fourth is static testing is verification testing, and dynamic testing is validation testing. So we talked about verification and validation in the past chapter. So this summarizes things is static testing is a verification technique and dynamic testing is a validation technique. Next point is static testing helps to prevent the effects. So we are doing things early. We are testing things early so that we can prevent defects from happening. But in dynamic testing, we are actually executing things. We're finding defects and we are trying to fix it. Last point, in static testing, the artifacts are checklists, Meeting Notes, etcetera. But in dynamic testing the artifacts or test cases or scripts. So there is one term here that we saw new and datas testing artifact. What are these testing artifacts? And it's one of the interview cushion also. So testing artifact is nothing but the deliverable or documents that you generate during testing like example, that test plan or the test case or the test data, etc. These are shared with the clients, that team manager and all the stake holder of project. So that's what testing artifact is. Alright, okay, so we have covered is static testing and dynamic testing. I hope you are clear on this first categorization of testing. Now in the next lecture we will explore another differentiation, functional and non-functional testing. So I'll see you in the next lecture. Till then, keep learning and happy testing. 9. 3.3 - Functional Testing: Hello everyone and welcome to this a to Zed deep learning course on software testing. So in this lecture we are going to cover the next category of testing types, which is the functional testing. So what is the functional testing? This testing verifies the functionality of the application under test to verify that it works according to the desired requirement. And it uses the black box technique. So particularly stuff we're verifying the functional aspects of the system. We are seeing how it works, what it does, et cetera, how we are verifying it. We are verifying it by using black-box technique that is putting the input, getting the output, and then comparing it to the expected result. And then we are, we are getting this expected result from, we are getting it from the requirement documents. So again, to recap, functional testing is the verification of functionality. We verified that it works according to the requirement and we use the blackbox technique. Let's see what other types of functional testing. But before we do that, let's take a minute and think about any application under design. Do you think that that application can be designed in one shot, one big block, no. Right? The ideal way to design it with me to make a smallest small blocks of code is small modules. Then combine one module with another, two modules with the third one and so on. Once all the modules are combined, we will have the system to test and then we will verify the system. We will release it to the user for their use and they will assess it. So we've got four blocks. Number one is small modules, number two, integrated modules, number three and tire system and for the end user. So once you understand this categorization, the understanding of the types of functional testing would be very easy. So the first type of functional testing is unit testing. This is done on the smallest small modules, the individual molecules of the code. So we, we said that the first stage of any product design is a small modules. So those modules would be unit tested. Who would do this testing? This would be done by the developers. Secondly, stages integration testing. So we are joining the two modules that were developed at where unit tested and we have to make sure that they're integrated correctly. Now there are two terms that you will hear very commonly when you are talking about integration testing. And they are stubs and drivers. So think about the system architecture is small box, small modules of code. And these boxes are independent modules that are hopefully unit tested and you are hooking them up to one and other. You are integrating them to one another. So you can either start from the bottom modules and build up, or you can start from the top module and build down. But remember in both of these cases you would not have all the modules that we will need because some of the modules are distinct, is still being developed. So we need something to simulate the missing modules and those are known as the stub and driver. So if we are integrating bottom-up, we will use drivers to replicate the missing modules. And if we are integrating top-down, we will use the stops to replicate missing modules. So bottom-up driver, top-down stops. Now there is a third way of integration also, which is a combination of bottom-up and top-down. And that is called as hybrid integration. And obviously makes use of both stub and driver. Now coming back to the third type of functional testing, it's called a system testing. So this is the stage where most exhaustive testing happens. All our modules are unit tested. They are integrated to each other. They are integrated integration testing, tested. And now we have the whole system ready. So now we will do our system testing. We will do our retesting regression testing, smoke testing, sanity testing, everything in here. And who will do it? It would be done by the testing team. Then we have the last stage of functional testing, which is called as the acceptance testing. This is the testing of weather requirements are meeting the user specifications or not. So this is done by your business analyst or a customer, or a small user group, et cetera. So these are the four types of functional testing unit testing, integration testing, system testing, and acceptance testing. Let's see what are the other types of functional testing that we can learn. So the first one is a smoke testing. So you can think of is smoke testing is a very basic check. It's not the entire testing of all the functionalities. Vendor developers give you a new code base and that is called as a build. So when the developer is giving you a new build, you dont want to jump into it and start testing everything. You first want to make sure that the build is stable, it is healthy, and dad testing is called as the smoke testing. Next we have sanity testing. So this is a town time-bound testing of most critical functionalities. So we are doing a little bit more than they smoke testing. We are doing a sort of test everything little bit approach. So before we can jump ahead and start our fully skill regression testing, we are doing small, small testing of each of the critical areas to make sure that the overall application looks good. And you can also do this testing on a daily basis in the production. So let's say that our website or our application is in production and it is used by the user. So we can do a lot of smoke testing, sorry, sanity testing on it daily to make sure that the critical functionalities are working fine and user would not have a problem. So the difference between a smoke testing and sanity testing is something that people confuse with. And it is Austin a lot in the interviews. So in the end of this chapter in the bonus content, we will take a look at what is the difference between them. So next is regression testing. And regression testing is the testing to determine any new changes or fixes are not breaking any existing feature. So remember, regression testing is not about testing what is nu, rather everything else to make sure that nothing was broken due to the new change. So it's common to confuse between regression testing and retesting. And that is again, something that is asked a lot in the interviews. So in the bonus content section, we will again take a look at what is the difference between regression testing and retesting. Number eight is exploratory testing. So some people call it as random testing also, or even monkey testing. So this is the undocumented testing. We are doing it on the fly. There is no documented is tripped script that tests or is just verifying things. He's not going through a fixed series of e-step. And it is very important to note that exploratory testing can never be counted as the primary testing. It will always be a step to your second step to your regression testing. So once we have completed the regression testing, the formal testing, then only we will do a round of exploratory testing. Number nine and the last one is a risk-based testing. So we saw it in the last chapter Also, this is the testing that is driven by risk. So very interesting, very popular topic nowadays, what we do is that we classified the features of the product. We give a score to each of the feature. We then check which features are the most susceptible to failure, meaning they have changed later or they are the most unstable modules, etc. And based on the two factors, we give a score to everything and we will test the things that have the highest score. So as we saw in the testing principles, we cannot verify everything. We do not have the time costs for everything. So somewhere we are, each of us is already doing risk-based testing, whether we know it or not. So guys, these were some of the main functional testing type. Remember, there will be several other testing types also, but we have covered the most common ones here. Now in the next lecture we are going to explore non-functional testing. So I'll see you in the next lecture about non-functional testing. Till then, keep learning and happy testing. 10. 3.4 - Non Functional Testing: Hello everyone and welcome to this a to Zed deep learning course on software testing. So guys, in this lecture we are going to go over non-functional testing types. So nonfunctional testing is the opposite of functional testing. This is the type of testing that verifies the non-functional aspects of the application, like its performance, its security, its usability, et cetera. So just like functional testing was dealing with testing with the functionality of the application. Here we are focusing on the non-functional aspect. Remember that this testing is also driven by requirements, or we call them as baselines. So just like functional testing, you would also be matching the actual result to these expected requirements or baseline. Now the most common type of non-functional testing out number one, load testing. So this is the testing done to verify the system's performance in expected real world's User node to determine the response time. Next we have the stress testing. So this is the testing where we put more than expected user load to verify how the system behaves. And third is the volume testing. So this is the testing performed with huge volumes of data to determine the system performance. So all these are subtypes of the performance testing. Let's look at what is the difference between them. In the first one, which is load testing, we are checking the system's response to number of users. So let's say that we have the specification that only 1500 users use our system. Then we are going to use different tools such as Load Runner, which are going to simulate the task of login parallely with 1500 users at that same time. And we will make sure that the application does not crashes. The application response time is good. And that would be our load testing criteria. So remember, we are not testing the login functionality that has already been tested as part of functional testing. Here we are testing what is the response time to login with 1500 users? What is the performance of the system? Next thing in the stress testing, we are going to give more load than expected. So we know that our expected load is 1500 users. In load testing, we have already verified the performance with those 1500 users. So in a stress testing, we are going to increase that load. We are going to check login with 1550 users, 1600 users, 1650 users, et cetera, to, to see how the system works in extreme conditions. And the next last parties volume testing. So in volume testing we are giving huge node, we are giving huge volumes of data to verify the system performance. So I hope that you understand these three types of performance testing. Now, performance testing is a very interesting area. It's very much in demand. So you can explore about it. You can think about it as a career option. Coming back to non-functional testing, the next one is security testing. So what it does is it has to uncover vulnerabilities, threats, or risk in the system. So this is a very specialized domain. Let say that we have a website that is using the credit card. So obviously we want to make sure that the credit card is safe. There is no hacking of the website, etc. So there are companies that specialize in security testing. They will, they have tools to verify security testing and clients pay them a lot of money to find vulnerabilities in the system or find security flaws. Again, Security testing is a very interesting and hyping area if you want to pursue. Let's continue with the non-functional testing aspect. So next Enqueue is usability testing. So this is testing performed to determine the ease of use of a system. So again, very important because this distinct checks the user friendliness. If the system is not user-friendly, it won't be used even though the functionality is good. The response time, the non-functional aspects are good. But if the system is not user-friendly, people will not use it. So that is what usability testing verifies. And in fact, there are a lot of companies that specialized in usability testing. They provide you user base VM, with whom you can verify your applications, etc. Number six is accessibility testing. So this type of testing is also gaining momentum in recent time. Because in many countries, especially the US, there is a guideline to make systems accessibility friendly. This is the testing that verifies the system's usability to people with disability. And again, we have several tools to verify this particular testing. The last one in our list is compliance testing. So this is our testing done to confirm adherence to standards, procedures, guidelines, etc. So if you're if you are using the credit card, there's a standard in place that is called the PCI compliance. So in the compliance testing, we are making sure that the system conforms to this PCI standard. There are several other standards for every other type. So this type of testing basically compare so system to make sure that it matches to a particular standard. Again, it is done by a third party company. There are companies that is specialized in compliance testing and they might use different tools for the purpose of this testing. So guys, these were the most common types of non-functional testing. There would be again, several other types of non-functional testing debt would be there, but we have covered the most important ones. So let's move on and let's see what is the difference between functional and non-functional testing pretty quickly. So number one, most important functional testing verifies the behavior of system, whereas non-functional testing verifies attributes like performance, security, etc. So this is the main difference. This is the difference on the basis of which we are classifying things. This is the difference that you can see if somebody asked you what is the basic difference? Second, functional testing is driven by requirements, whereas non functional testing is driven by expectations. So very important, like when we say login functionality, it is clear that the requirement is user should be able to enter user ID, password, and login. But in nonfunctional testing, the requirements come more from expectation. So there is no general rule to how fast the system should log you in. But the general expectation is that the website should log you in in three to ten seconds. So if you are on a website that takes two minutes to login or if you are in a website debt takes ten minutes to search for any item, you will just dump it and move on. So nonfunctional testing is driven by expectations, the market expectations, the baseline, et cetera. Next, functional testing is done before non-functional testing. Vise. Oh, because when we are doing functional testing, the system is still under test. There might be changes, there might be defect fixes, and the code would change. So we want to do the functional testing first, make sure that the functional aspects are working. The code is table, and then we go ahead and do the non-functional testing. Point number four, functional testing is done using functionally specs, functional requirements. And non functional testing is done using the baselines or best practices like we already discussed. Now last point, functional testing can be done manually also. There is automation functional testing also, but it is something that can be done manually also. Whereas if we talk about non-functional testing, it would mostly mostly require any tool. So we cannot get 1500 users to login at the same time, it would not be possible. So we of course need tool to verify the non-functional aspects. So now we know what is functional and non-functional testing. What are its type, what is its difference? And between functional and non-functional testing, we have covered lot of testing types also. We have discussed the most common testing types that are used in the real world. So let's recap on those terms again before we proceed ahead. So functional testing, including unit testing, integration testing, system testing, acceptance testing, smoke testing, sanity testing, regression testing, and exploratory testing. Various non-functional testing includes load testing, is stress-testing, volume testing, security testing, usability testing, and accessibility testing and compliance testing. So guys, this was all about functional and non functional testing. In the next lecture, we are going to see one more type of testing which is called as the user acceptance testing. So I'll see you in the next lecture. Till then, keep learning and happy testing. 11. 3.5 - User Acceptance Testing: Hello everyone and welcome to this a2 set deep learning course on software testing. So guys, the topic that we are going to discuss now is User Acceptance Testing. And we have talked about it earlier also. Let's say that we design a system that is doing all functionalities like login, search, checkout, et cetera, very nicely. All of the functionality is good. It is also doing all those things very fast and very securely. So what nonfunctional parameters are also good. But do you think that any of this would be helpful if the system does not meet the user requirements? The answer is a big no. So dads fights very important to do user acceptance testing or UAT. So this is the type of testing that is done by the end user or the client of a system to validate the software against the business requirements and decide whether it is acceptable. So particular definition, it is done by the users and it is done against the requirement to make sure that the system is adhering to that requirements. Now there are three types of UAT testing debt are very common. The first one is alpha testing, so this is done at the developer side. We call over the users, we call over the end customers. They use the system, they give feedback, they find defects, etcetera. Everything is done at the developers site. The next one is beta testing. So we are doing the same thing. We are verifying the system, but the verification is being done by the end users at their location. So like if you go to the Play store on your phone, you can enroll there in the beta testing program. You can verify the apps over there from your own phone. You don't have to go anywhere. You don't have to use any other machine. You can verify them from your own location. You can verify them from your own machine. And in fact, it's a very good place to start for the testers. You can go to the Play Store, you can explore about enrolling in the beta testing program. Remember those apps that you get for beta testing might not be stable. That's a disclaimer. It might not be very stable, it might crash, et cetera. But it's very good place to start learning about the concepts of testing. The last one is called AB testing or split testing. So what is this? Ab testing creates two versions of the product to determine which one meets business and acceptance more effectively. So guys, most courses end their discussion of unity on the first two types, that is alpha and beta. But I think A-B testing is also very important concept. So what exactly is this AB testing? If you use Facebook, you will remember that they launched multiple like options a few years back. So when did, did this? It was not, it was not launched to all the users. People in some countries got the new like option, whereas other people were still getting the old single Like button. So that is what AB testing means. We are launching the product into version a and B. We then compare which one got a better feedback. And based on that, that behaviors become the going forward behavior. So when Facebook launched these two options, they got a lot of positive feedback that people are liking the new like options, the new like emojis. So then they went and launched it worldwide. So that's what AB testing is. Now how it is different for the testers. It is different for the testers because it means that we have to verify both the a and B variants as long as both our knife to the customer. So it's double the work for us. One more thing about User Acceptance Testing is that testers are not directly involved in it. Because as I mentioned earlier, UAT is done by the end user. However, testers do participate in some ways like by helping with test environment, giving test data, et cetera. And I believe that it is also good for the tester to be present in UAT sessions because it gives you an idea of about how customers think in the real world, what they want from the system, etc. So as testers, we most often think about how to break the system. The general thought process is to break the application. But when you are in the unity session, you will notice that uses mostly care about happy path flows. They do not care about entering any random value to break the system. So it's important to understand that uses what users want from the system. We should focus more on the happy path scenarios, not just the negative scenarios. That's why it's important for testers to understand the UAT also, to understand the customer mindset also. All right, so with this, we have completed our learning of the types of testing. We can now say proudly that we know what is functional testing, what is nonfunctional testing? What is User Acceptance Testing, cetera, we can now say what is the importance of login functionality and why we should also check that login is fast and secure. We can also say now wife, Facebook had to like options, how it was eventually combined into one, and how it made our work double, right? So in summary, we can talk about a lot of things, what tester does and how they contribute to make applications work and be user-friendly. This was an amazing learning journey. We learnt lot of things and we should be proud of our self. Now in the next slide, we will do some bonus learning, as I promised earlier in our discussion. So we will learn about two terms that are similar and confusing and they are asked in the interviews. But before that, remember what we'll learn today is a lot of testers daily work. You would be asked a lot about these things in interview. So if you ever need a recap, just go over the lecture again. It will refresh your concepts. If you still have any questions, do not hesitate to use the QA section or drop me an email. Okay, so I'll see you in the next slide about the bonus content. Till then, keep learning and happy testing. 12. 3.6 - Bonus Content - Deep dive into terms that confuse: Hello everyone and welcome to this a2 set deep learning course on software testing. So this is the bonus content section of the chapter. And as I mentioned in the first chapter of this course, we have this bonus content sections is spread throughout the course to get you to learn something additional. That either helps you clear an interview or understand how things work in the real world. So these sections are what differentiates this course from other courses online. And this learning will differentiate you from other testing is too dense. Now as we go into the next chapters, we will see this bonus content change from definitions to designing practical reports, writing test cases or tools, demo, et cetera. But the idea will remain same. We don't want this course to be bookish concept only. We want to cover practical aspects which will help you in your day-to-day job as a tester. So let's begin with this one. And what we're going to do in the bonus content of this chapter is to look at couple of terms that look very similar, but they are actually different. And this is the stuff that is asked in almost all interview questions. We saw a bit in last chapter about verification, validation, severity, priority, etc. So in this chapter we are going to pick two new comparisons and learn about them. So let's begin. Now. The first term that we are going to discuss is the smoke testing and sanity testing. And I pick this particular topic because it is always tasked in interview questions. And I have seen many people who have huge experience in testing. They also fail in this topic. So let's not be those kind of people. Let's understand the difference between these terms. So what is the smoke testing? Is? Smoke testing is verifying the basic things on a new build. It's a general checkup. So when you go to a doctor, he will check few things quickly to make sure that you are fine or you need more tests. So he will take your temperature, he will check your blood pressure, et cetera. And based on that, he would be able to say that you are healthy or you need more testing. So data is smoke testing a quick way to check, verify stability of the build? And what is sanity testing? It's more of a specialized check. So when you go to the doctor and he does a full blood test data sanity testing later in more detail, a little bit of every check. So coming back to testing sanity testing is like you verify around new functionalities or bucks, or you do a daily check of the system. You are verifying all the critical areas of application. Point number two, when we do smoke testing, when do we do smoke testing? When we get a new build, the developer gave us a new build and we want to make sure that it is stable. So we will run the smoke test. When do we do sanity testing? We do sanity testing for the daily check-up or as a prerequisite to start full regression. Next point, Who does this smoke testing. So it is done mainly by the testers, but sometimes developers will also do it before they gave up build if they want to test things quickly. So smoke testing is mostly testers, but sometimes developers will also do it. But who does his sanity testing? Always the tester. Next point, what do we find? Smoke testing. We verified the basic things. It's a very small subset of testing. What do we find? Sanity testing, we verify all the critical areas. So it's a little bigger than smoke testing and it's usually a small subset of regression testing. So the order is a smoke testing is smallest. Then we have sanity testing and finally, regression testing. And last point as you soy smoke insanity or both, something that we do on a regular basis. So both are very good candidate for automation. What we can also do is tie up the execution of smoke testing automation scripts to each new build generation. And in fact, that's what something we do in the CIC model, the continuous testing model that we discussed in last chapter. So we tie the automation is Script office smoke test to the new build. Each time a new build is given the test run automatically. And for sanity testing, we shut down our automation scripts to run on a regular basis. Like once every day at seven AM Before users will start their day. Alright guys, so I think you are clear now on what is smoke testing and what is sanity testing and what are the difference? Remember the most basic difference, we do smoke testing when a new build comes in and we do sanity testing on a daily basis may be to verify critical areas or before you starting regression testing to make sure the entire system is good. This is the major difference. And even if you say this, just this one thing to the interviewer, he will know that you are good on concepts. All at. Let's move on to the next terminology, regression testing and retesting against something that looks similar but they are different and something that many experienced professionals don't understand. So let's see. So point number one, what is regression testing? Regression testing is verifying data. Recent change has not affected existing functionality. What is retesting? Retail retesting is verifying the test cases which failed earlier. They are getting passed now after the defect is fixed. So let's understand it by an example. Let's say that you logged a defect on Facebook login, that you cannot log in with mobile number. So you logged this defect and now it is fixed. So you will be verified that defect and that is called as retesting. But at the same time you will also verified at other methods of login like email login, user id, log-in, alphanumeric email login, etcetera. They are not broken due to this fixed and data is regression testing. Point number two, what is tested in regression. So we test the existing feature, what is tested in retesting the fixed feature, that's all regression and retesting is point number three, regression includes all scenarios, whereas retesting includes only the fields scenario. Point number for regression testing is one of those areas that is mostly automated by each company. Because regression tests count is high, it is needed frequently, it is stable, et cetera. So regression are the best candidates for automation. But retesting is something that is not automated usually because it is done manually. Why? Because we are verifying the fixed only. And last thing regression is done after retesting. So when we logged the defect for mobile number login not working, we first need to verify that defect is really fixed before jumping into all the regression scenarios. So that's why retesting is done first, then regression testing. So again guys to concepts and when the interviewer asks you, you can answer. In fact, if you just say that retesting is testing the field scenario and regression testing is testing everything except the field scenario. The interviewer will know that you are good in concepts. Okay, so I hope that you are clear now about both these terms and you will not confuse them in an interview. You will be able to answer a smoke and sanity testing, regression entry testing both. And if you have an interview lined up tomorrow, you can always come back here and read it quickly. We will also do a full section on interview questions later in the course. But for now you know two more topics that are asked in the interview and you know how to answer them. I would suggest when you answer these interview questions, use examples to better explain thing. Don't just say the definition because everybody knows it includes some examples also like I gave you of the mobile number and other login like debt. So this will help explain the things clearly and the interviewer will know that you are clear on concepts. All right, so with this, we have come to the end of our third chapter on software testing. I hope you are sealing fine through this course till now, we have learned a lot of core concepts which will serve as the foundation for the stuff in later part of this course. In case you miss anything, don't worry. We will again cover things when it will be needed for now, let's keep up the momentum and proceed to the next chapter, which is the stages of SDLC. So I'll see you in the next chapter. Till then, keep learning and Hep-C testing. 13. 4.1 - Introduction to STLC: Hello everyone and welcome to the fourth chapter of this dataset deep learning course on software testing. So guys, this is day four of our learning journey. So far we have learned what software testing is, what is the importance of testing the principles behind testing, et cetera. We also learnt what are the different types of testing like static, dynamic, white box, black box, functional, non-functional UAT, etcetera. So we have covered the why and what parts. Now starting this lecture, we will get into the process part, the how part. So how to do our testing? And this is going to be very exciting and informative. So let's dive in and let's explore. So here is what we will cover in this lecture. And what you see here are the stages of software testing Life Cycle, or SDLC. And this is what software testing is all about. So we are going to start with an introduction to SDLC, followed by each of its stage, requirement analysis, test planning, test design or test case development, environment setup, test execution. And the last one, test closure. So let's start with the first topic, the introduction to SDLC. So now the first question that comes to our mind is what is SDLC or software testing lifecycle? We talked about it in the past chapters. Let's recap that. So the definition says software testing lifecycle is a sequence of activities conducted during testing process. Pretty straightforward, but let's still break it down more. Firstly, SDLC is a sequence of activities, so it is not a single activity. It's a series of activities which have to be done in a predefined sequence. And you can see the sequence in the image on the screen. We have to follow the exact same order. Second, it is done as part of the testing process. So this is what makes it important. We discussed earlier that testing is not a single task, it's a process. And when we talk of process, there has to be some rules for it to work successfully. A sequence of events and dads, what SDLC is. Next up, each state has a defined entry and exit criteria, so they stay just that you see on the screen. They cannot be started and ended randomly. There is a specific entry criteria, which is when we can start, that is stage. And there is a specific exit criteria, which is when we can end at estate and only vanished ages ended. We can move to the next stage. Last point, each stage has a fixed activity and deliverables. So even within each state there is a fixed list of activity that we have to do. For example, in test design, we will only write test cases, will not execute them until the test execution stage. And then for each state there is a set of deliverables debt should be generated. So like an output or results of data stage, for example, the test design stage will give us the test cases. So guys, you can see the chart for SDLC on the screen. Now in some organizations it may have different stages, or not all these stages, but this is the most common and recognize representation which bulk of the companies follow? This is why I picked this one. And if you get hold of this one, you will understand every other model in the world. So that testing lifecycle is starts with requirement analysis followed by test planning. Then comes test design, environment setup. This is followed by test execution. And lastly, the finalist stage test cycle closure. So these are the six stages of SDLC, and as you would recall, we saw them in chapter two also. So now in this chapter, what we are going to do is we are going to get to know each stage, what is done in it, what are the deliverables, what is its entry and exit criteria, et cetera? And we are going to cover two stages in each lecture. So I will see you in the next lecture with the first two stages of SDLC. Till then, keep learning and happy testing. 14. 4.2 - Phase 1, 2 (Requirement Analysis, Test Planning): Hello everyone and welcome to this a to Zed deep learning course on software testing. So we are going to start with the first stage of SDLC, which is requirement analysis. Now before that, I just wanted to let you know that we are going to cover each of the stages in the same exact format that you see on the screen. So we will see the definition of each stage bought up the activities of data stage, meaning what are the tasks that we do in that stage? Third, what is the entry criteria for that is stage, meaning when do we start that stage? And similarly, what is the exit criteria of data state, meaning when do we end at the state and move to the next stage? Last point, what is the deliverable of each state? So what is the artifact? What is the output that comes from each state? So let's begin with the first stage requirement analysis. Now, when we say requirement analysis to things should immediately come to our mind. First is early testing. That's why we want to start at the requirement analysis phase itself. And second is static testing. So there is nothing to be executed here. We would do the static testing now. So as the definition says in the first phase, the test team reviews any requirement documents, functional or nonfunctional to determine testable requirements and the scope of testing. This phase involves interaction with different stakeholders, client, Ba, developers, designers, et cetera. So let's break it to understand as we do for all definitions. So first thing, this is the starting phase of SDLC, the Faustus stage. Second, this is the stage where we reviewed requirement document. So this will of course include both functional and non-functional requirement document. Since we discussed in the past, both are important. Third point, we extract testable requirements from it and dad defined somebody scope of testing. So very important, we have to clearly define the scope of testing and communicated to everyone. We have to tell them what we are going to test and more importantly, what we cannot test. It's very important to set expectations right from the beginning. Lastly, how we will get requirements will get it from the client, the business analyst, the developers, designers, etcetera. So these are the people that you will work most closely in the requirement analysis stage. Next, let's see what activities we do in this phase. So we identify the types of testing to be done. So we will do integration testing, system testing, load testing, useability testing, regression testing, etcetera, whatever we will do. We discussed the testing priorities. We talk about what will be the testing environments at a high level. Next, we prepare the requirement traceability matrix. So the requirement traceability matrix, or rpm, is a document that helps us map the requirements to test scenarios. So many times we can do it simply in an Excel sheet by putting the requirements in one column and the test scenarios in another. Or nowadays the test management tools automatically provide the capability to create RTF. So there are several ways to do it, and we will see in the later chapter how to create an RT m. In fact, we will create an RPM or cells, but just to make sure, we have to make sure that each requirement is covered. And the way to do it is to write the requirements and test scenarios next to each other, and that is our RPM. Lastly, In this stage we check the feasibility analysis for automation. So whether automation is needed or not, it's important to call it out at this stage only so we can plan for it just like we are doing for the manual testing. Next, what is the entry criteria, meaning when we can start requirement analysis? So the entry criteria obviously is that we have documented requirements both functional and non-functional. We can also get the application architecture is specification. So this would come from the developer. So we know what the system components are and what testing they will need. So as you can see, the entry criteria of requirement analysis is something that is not dependent upon the testing team. It's either coming from the business analyst or it's coming from the developer. So that is why this is the first phase. We have to touch base with them and get started on our testing expectations. Next, let us see what are the exit criteria. So the exit criteria is assigned of rpm and a clear understanding of Testing scope including automation. Last point, what are the deliverables? What are the artifacts that come out of this stage? So again, number one, an RPM, and number two, an automation report if we are going to do automation. So remember if it's a small project, if it's a onetime project, then there won't be any automation. But if we have to do automation, then that deliverable out of this stage is to get an automation report. Ok guys, so via, through the first stage of SDLC, which is the requirement analysis, we have got the requirements, we know what to test, we know whether we have to do automation or not. So let's take those learnings and move to the next stage now, which is test planning. So guys, this is the strategy stage. This is where we decide the roadmap of entire testing. And as the definition says, test planning is the most important phase. As all testing strategies defined in this phase are tests manager determines effort and cost estimate for the entire project. The selection of test tools, Resource Planning, Resources, rules and responsibilities, everything is done. So basically this is the stage where we plan for everything, effort, cost, tools, resources, roles, and responsibilities, everything. It's very, very important to do this stage carefully and plan for each and every thing right down to the finest details, because even a small gap can cost us huge in the later stages. Next, what are the activities of the states? So we finalize the test strategy. We created tress plan with all the details. We go through the list of test tools and decide which one to use. We do that, effort estimation, we do the resource planning, etc. So guys, as you can see, every tiny plan is made here. And all that plan is safety net document that we call as the test plan. So the test plan obviously has to be the most important artifact of testing. And we will see a test plan in detail in the next chapter in the bonus content. In fact, we will go over a real project test plan and see how to make it. Moving on. Next point, when do we enter the test planning is state what is the entry criteria? So we should have the requirements, we should have the rpm, we should have the automation feasibility report. Once all these things are ready, then only we can get into this stage. Likewise, what is the exit criteria? So the exit criteria is that we should have approved test plan. So very important, we cannot move ahead to next stage unless we had approved test plan. And again, LA last thing, what is the deliverable of this history? So again, the test plan. So once again guys, the very important stage of SDLC giving the most important output, output, the test plan. So we have the requirements now we have a solid test plan on how to proceed. So let's move ahead and in the next lecture we are going to cover next two stages of SDLC, which are test design and environment setup. So I'll see you in the next lecture till then, keep learning and happy testing. 15. 4.3 - Phase 3, 4 (Test Design, Test Environment): Hello everyone and welcome to this a to Zed deep learning course on software testing. So guys, we are now at the third stage of SDLC, Which is the test design or test case development. So from the past stages, we have the requirements, we have the RPM based on the test plan. We know what we have to test functional regression, sanity, et cetera. We know what test management tool we have to use. So we are done with all the planning. Let's get into the implementation now. So this is the stage from which the testing work. We'll really start from which the testers will have all the ownership. So in the requirement phase, everything was coming from the requirement, our business analysts or the development managers in the test design phase, the test managers or test needs, we're working on preparing the test plan. But this is the state, the test design from which the real work of testers will start. We will start to create the test cases. So let's read the definition. The definition says this is the stage where we write detail test cases and review them. We also prepare the test data for testing. So this is the first score testing stage, as I said, this and the later execution instead is we are, our major efforts will go next. What are the activities of this phase? So we will get going into writing the requirements into test cases. We will create automation scripts. If we are doing automation in the project, we will get them reviewed. It's very important to get our test cases reviewed so they are effective. And last thing, we cannot continue testing without test data. So we will create test data also here. How do we do that? We will cover in detail in the full chapter on test design later. But for now, just remember that test data setup is also done in this stage and it's an important activity. Why? Because of course, if we do not have test data, we cannot test anything. Next, what are the entry criteria to this face? So we should have an approved requirement document, we should have a test plan. And likewise, what are the exit criteria that we can complete and move to the next stage? We should have the review test scripts, we should have the test data. And last point, what are the artifacts of this stage? So we should have that test scripts, both automation and Manuel. And we should have the test data. So guys, we are halfway through the SDLC. We have covered three out of six stages. We have the requirements, we have the test plan, and now we have the test cases. So let's move on to the next stage, which is test environment setup. So again, this is an important stage of SDLC, but unfortunately, a lot of courses do not pay attention to it because the setup is actually done by the system admins or developers. And testers are not fully involved. However, we cannot test things unless we have an environment to run our test. And that is why this is, this is a state at Tesco should closely monitor. So in this state, any software or hardware required for the testing is configured. This is done mainly by the system admin and development team. And they can do this activity in parallel with the test design phase while the testers are creating the test cases to save some time. What are the activities here? First is to prepare the required hardware and software. Next, we have to do the actual setup. And finally, when the environment is ready and handed over to the testing team, we will perform a smoke test on it and confirm that is stable and healthy for use. Next, what are the entry criteria? So the system design document we got from requirement analysis phase and the environment setup plant that we created in our test plan. Likewise, what are the exit criteria? So the environment should be stable, meaning of a smoke test has passed. So we discussed in the last chapter is also debt. Once the new build is given by the developer, the testers are supposed to run a smoke test to make sure that the general health and stability of the environment is good. So that's what we will do here. And only months somebody smoke tests have passed correctly. We will make sure we will certify that the environment is good and we will sign off. And last point, we will also verify our test data. So remember in the last stage, the test design stage, we had created our test data, but now we have to make sure that it works on the real environment and that is an important part of its environment setup. We will learn more about test data setup in the later chapters. But obviously until there is test data, we cannot test anything. Last point, what are the deliverables of this states? So we got our environments. We have every smoke testing results to prove that they worked. Awesome guys. So we have come a long way in our testing journey. We have, we got the requirements initially, we created a solid test plan, we created test cases. We got the test environment and test data. So we are pretty much a long way in our SDLC stages. And let's move on and cover the last two stages of SDLC, the test execution and disclosure in the next lecture. So until then, keep learning and Hep-C testing. 16. 4.4 - Phase 5, 6 (Test Execution, Test Closure): Hello everyone and welcome to this a2 set deep learning course on software testing. So this is the final lecture of our chapter four over d4x of testing. And we are going to cover the last two stages of SDLC in it. So let's start with the fifth phase, which is test execution. And this is where all the action would happen. So we will start with our validation and CV or thinks is stand. As the definition says, test execution is the phase we are, test cases are executed, comparing the expected result to actual results and making them as pass, fail or incomplete for feeling scenarios defects are locked and this is also the face we are continuous test reporting is very important. So pretty much self-explanatory. We will run our test cases. If everything is good, they will pass. If say something failing, we will log the defects and Malda test cases fail. There might be other challenges also like blocker defect, test data, query, etcetera for which we will Malda test cases as incomplete. And once those roadblocks blow, roadblocks are resolved, we will proceed with our testing again. Another thing that is very important in this status reporting. So we are executing things, we are making progress on things. So all the stakeholders of a project, the business team, the development team, that client, everybody would want a progress report from us. Now it might be needed daily or weekly depending upon the project. But either case, it is required to capture the progress and report it. There is no point in executing things unless we are not telling people about the results. There is also need to report the status of defects, which is what we call as the defect report. And just to let you guys know, we will cover a real-world execution report in the bonus content section of our test execution chapter. Because like I said, this course is not just about theory, it's practically stuff also. Great. So let's see what are the activities in this stage, we will execute the test cases, we will log the defects, will do the regression testing manual automation. We will do the retesting, we will close the defects, and all along, we will prepare and report our execution results. So that's why, as I said in the beginning, this is the stage where all the action is happening. Next, what are the execute entry criteria for this states? So we have test cases, we have a stable test environment and we have test data, then only we can start with the execution. And likewise, what is the exit criteria for this state? So all the plan test cases should be executed. There should be no blocker and critical defects. That means the testing team should sign off only then we can say that the test execution stage has closed. Lastly, what are the artifacts of this state? So we will have the executed test cases. We will have the execution report that we will send out on a frequent basis. As I mentioned earlier. Then we will have the defect report, which can be a part of execution report. It says, Alright guys, so we have crossed the execution is stayed also of testing lifecycle. We have really come through a lot in this journey. We have completed our testing and the product is all validated and ready to go to live production environment. But while that happens, there is one more activity that we have to do. The last one in SDLC, which is test closure. So this is the official closing of all testing activities. And as the definition says, this is the final phase in which testing cycle is evaluated for completion. A retrospective of entire test cycle is done to learn and identify best practices for the future. So although we have completed our testing, this is tedious, important to, uh, do a retrospective or review of our entire journey so we can learn things from them for the future. We can identify any gaps that we need to be addressed, et cetera. The activities of this stage are evaluating the test cycle on parameters like time, coverage, cost, quality, et cetera. So we'll take a recap of our entire journey and see where we stood. We will document those learnings. We will document the best practices and we will create a test closure report. What is the entry criteria to this face? Our testing should be completed, our test execution and defect reports should be available, etcetera. And what is the exit criteria to this face? We would create the test closure report. And remember, this is the last stage, so there's nothing that needs this test closure report as a precondition. There is no further east stage. We are only keeping this report as a reference for our future. It will serve as a guide if same project comes again in the future or to learn from our mistakes for any other similar project. Last point, what are the deliverables of this estates Augie under test closure report and a test metrics. So like a final summary of our test case count, the execution count, the defect count, the number of automation scripts, et cetera. Alright guys, so we have passed through an entire testing Germany. Now we know at a high level what activities we do, what are the expectations from each stage and how we should proceed. In the coming chapters, we will pick each of these SDLC stages in detail and go deep down into them to know other fine details. And we will also see some of the output deliverables debt we have in this in each stage, like the test plan, the test cases execution report, etc.. In the bonus content section, we will see how to make them. So pretty exciting stuff coming up ahead. Stay tuned. Alright guys, so this brings us to the end of chapter four. We will continue on our journey and I will see you in the next chapter with day five of our journey. So till then keep learning and Hep-C testing. 17. 5.1 - Introduction to Requirement Analysis & how requirements are created: Hello everyone and welcome to the fifth chapter of this a to Z and deep learning course on software testing. In the last chapter, we covered different aspects of software testing or lifecycle. We looked at all the stages that are there in their steel C. And starting this chapter, we will pick those stages one by one and explored them. We will go in depth and see various other topics that happen in those stages. And we will also explore some of the real-world example concepts and documents to give you a practical exposure to how real companies work. Alright, so the topics that we are going to cover the in this, in this particular chapter. Requirement analysis and test planning, the first two stages of SDLC. So let's start our journey into SDLC stage 12. So here is what we will cover in this lecture. We will start with an introduction to requirement analysis. We will see how requirements are formed. So how do companies actually get their requirements? And again, this is a practical concept and I have included it here so that you know how the process works in the real world. Next, how to understand and translate requirements. Then requirements traceability matrix or our TM, very important topic. And then we would go into test coverage and finally, test planning. And we will not talk much about test planning. We will look at only two or three slides because again, it's better to do a demo. And that's why we have the bonus content of this lecture, which is the walk-through of a real test plan, are very important topic. Alright, so we are clear on their agenda. Let's begin. So the first question is, what is requirement analysis as well as the name suggests, it is the process of going through the requirements and making sure that they are clear. So this is the first phase of SDLC. And as you can see that whatever we do here is would act as the input for the next stages. So the information that we gather here would be fed into the later stages of test planning, test design, and so on. And that's why it is very important to make sure that this fastest step is done right? So guys, what happens when we have a misunderstood requirement or a miss missed requirement? In both the cases, it would lead to incorrect testing or inadequate is scope. So we would either not be testing everything or we would be testing it in correctly. Let's look at it from a couple of example. Let's say we are working at Facebook and we have been asked to validate the login flow of Facebook. So the business would come up to us and say that, well, our requirement is that you Dad, somebody enters their email ID and password and we log them in. This is the requirement at came from business gives you an email ID password and we should lock you in. But what happened was that the testing team understood it in a different way. And what the testing team understood was that we have to verify login by mobile number and password, so it did not translate correctly. And the testing team design test is scope and test cases only for verifying login by mobile number and password, not by email. So now you can assume what would happen there. It would lead to incorrect testing or inadequate testing. Well actually it's very extreme example, it does not happen that by such a huge margin in the real world. But either case it's an example of misunderstood requirement. Let's consider another example. We have been asked to validate the checkout flow for Amazon. And Amazon gave us all the requirements, but they did not mention about payments by Malet like MS. Np. So that's why the m isn't pay was never in our requirements and we did not test it. And as you can assume, it would result in incorrect testing or miss testing. So in both the examples that we talked, we wasted our time and energy in testing and it was incorrect or inefficient in sufficient. And it led to late changes which affected the entire shared dual and cost and budget, et cetera. So you can so you can understand how things are going here. And that is why it's very important to capture requirements correctly and completely from the beginning. Okay, next point, requirements can be both functional and non-functional. So we talked about this in the last chapter also, we note that testing is both functional and non-functional. So whenever we are asked about requirements, it's always best to check for both functional and non-functional aspects. So there is no miss. Last point who gives us the requirements? So the requirements can come from the business analysts or be the product owner, the system architect, technical development manager, anybody. The BA will give requirements mostly on the business side. So like the BA would come up and say that I want to make a system that allows user to login. If they give the right password and username, we would log them in else we will show an error message. So this would be the business requirement from the be pretty straight forward. He does not care about how it works. He just gives us the user flow. The technical guy, on the other hand, will give you requirements on a more technical details. So for example, for the same login flow, he would tell that, number one, we should have a web-based text box for login and password with the login button number two, when you enter any details, it should go to the backend database, which should confirm that it is correct. Number three, if nothing is entered in the box as it should give a front end JavaScript error. So like debt, so things are a little, he talks about things in more technical way. But obviously both business and technical teams have their own requirements and we have to coordinate with both of them to understand these requirements. Also remember that in any organization, testers are the one who have knowledge of the entire system. So nowadays it's expected that testers also contribute to requirement analysis. In case something is missed by their BA or technical guys, that testers should be self-sufficient to point it out and raise a query for this. All right, so let's move to the next slide. Let's see how requirements are actually created. And guys, this is not something that we test us would normally do. It's done by the business team like the Product Owner, business analyst, et cetera. But having an idea of this will help understand in our journey. So it will help us understand the entire process. So let's take a look very quickly. Now, requirements may come from many sources, so it may come from group sessions in house ideation. Third party consultants, competitors, etc. Like many companies have a dedicated group for this are dedicated Business Strategy Group debt comes up with new features to add or they do an ideation session where they get together all the employees and they ask employees to submit ideas based on what they have seen anywhere else. Many big companies also hired Hard party market research firms to find gaps in the replication and suggest new features or what we are, what they can do, they can scan the competitor websites. So for example, Amazon does something. So Flipkart will also do that. So these are some of the ways in which requirements would come. And when the requirements come at the initial point of we create a high level requirement for them. So this is at a very high level and it creates a project vision document with use case. So guys, this is how a use case looks like. And as you can see that it is capturing the requirements are to a very high level. It's not going into each and every tiny detail. And this is the use case for an online shopping site. So as you can see, there are various icons in here, like these or these and what these icons are, they are nothing but the end-user. So the use case is always designed keeping in mind the end user. So like for example, this is an online customer and the requirements for him is that he can view the products, he can purchase the products, he can manage his account information, he can create reviews like dat. If we talk from the perspective of a warehouse guy, he should be able to keep a check on the inventory, manage the inventory, all these things. So we will use this particular example for the online customer Weir. He's able to view the products. So at a high level requirement they use case would be like, I wonder online customer to come to the website and he should be able to view all the products. That would be my high level requirement in the form of a use case. So at a high level, now that we have a use case, the next step is that these use cases are translated into low level requirements, which are called as functional requirements. So this is an example of transforming a high-level use case into a low level functional requirement. So for example, we saw in the use case that we wanted the end customer to be able to view products. So for this view product use case to work, we would need some requirements around website design and website navigation, product search, product refinement category, all of those things. So what we have done here is we have classified these use cases into low level requirements. And the next step that would happen is we would turn these lower low-level requirements into user stories. So we are talking in terms of h l here. And as we saw in our earlier lecture, AGI works in small cycles called sprints. And each sprint takes in some user stories, which is the requirement. So each level, each low level requirement will have been owed more stories to achieve it. So like example, we talked about view products use case which caught translated into all these low level requirements. And for the product such requirement we would have three user stories and story one story to story three, they would be taken into one sprint and they would be worked on. And once these stories are done, we would be able to say that we have implemented the search requirement. So, so this was at a very high level how requirements work. And this was mostly we were talking about the business requirements. Remember, apart from the business requirements that get translated into businesses stories, there would be technical requirements also would come from the technical architect, a technical manager, the development manager, etc.. So those requirements would not be in the form of use cases. They would be more in terms of technical aspect like design, a user database, designer product database integrated with the website, et cetera. So that was at a very high level how requirements work and what we actually did in this slide was work as a business analyst and see how the requirements would be gathered and translated. The work of a tester mode is start form those user stories. But as I said, I wanted you to know the entire process so you can understand how things work. And then only you can our dive deep into it and raise queries and improve the process. So now we talked about how BAS work and how they managed requirement. Now we would go back again into our role as a tester. And we will understand how these requirements work and how we can make sure to not miss on them. So in the next lecture, guys will cover the next step, which is understanding how to effectively understand requirements and convert them into correct test cases. So I'll see you in the next lecture. Till then, keep learning and happy testing. 18. 5.2 - RTM & Test Coverage: Hello everyone and welcome to this a to Zed deep learning course on software testing. So let's start on our journey of how we can understand requirements clearly and convert them into effective tests scenarios. We have already discussed in the past slides that requirements are the foundation of effective testing. If we miss a requirement or if we understand it in correctly, then it can lead to incorrect testing and defect leakage to production. So when someone puts a requirement before you, and that would normally be the business analyst or the product owner or the technical manager. So whenever they put the requirement in front of you, always make sure that it has the following attributes. Number one, it should be complete with all the information. There should be no assumptions. So if there is something that is not there, do not assume at your end to fill in the gaps and raise it to the B, get clarification from him because if we make assumptions from our side, they might be wrong and then we would be testing in correctly. Number two, requirements should be clear, so well-written, language transparent. It should make sense. And remember guys, if, if there's something that needs to be changed in the requirements, like if it is not clear, then we cannot make it change it ourselves. We will have to work with the beam business analysts will have to coordinate with him and ask him to make the changes and published a new requirement. Document. Number three, it should be correct. No false statements. Number four, it should be consistent, so it should not be like that. It says something in the beginning and then later it contradicts that requirement and changes it to something else. Last point, it should be testable, so it should not be, so the requirement should not be like that. Check the Product Search with each of the 1 million products sold on m isn't because that's not possible. So instead it should give up. It should be mentioned as it has in a testable way. It should give a proper technique or it should give a proper classification on how we can make the requirement test testable. And last point, remember always that whenever somebody says requirements, we have to include both the functional and non-functional is stuff. Alright, let's continue to the next slide. So guys testers have complete knowledge of system, like I mentioned earlier also. So they are very useful assets in formulating the requirement. And companies nowadays expect testers to get, give feedback on the requirements because of their end-to-end flow understanding. And this would mean that you would work with the business analysts a lot. And that's why you remember I mentioned in the first chapter itself, lot of testers end up working as full-time B, because we have knowledge of the system. We have. We are working with the BSON. We understand how things work and that's why many of us would translate our curious later into full-time business analyst. Next point, always asked questions, do not leave anything to assumption. And this is the most common problem. When people don't get all the information, they would make assumption on their end for the missing part. And that might be wrong because remember, we don't know what business analysts or product owner has in their mind. So we would be making the wrong assumption and that would result in wrong testing. So never assume things. Always ask questions. And remember, no, no question is bad. Nothing like a bad question. It could actually bring up something that everyone missed and it would help the entire process. So don't hesitate to ask questions. Point number three, always insist on documented requirements so people do not remember verbal discussion. And we will need the requirements over time and we would have to refresh them again. So for example, when we will be executing the test case and we found a defect, we would have to check back on the requirements to confirm. And if it was something that was done verbally with no written text, we want remember it anymore and we would be stuck. So always asked for requirements in writing. It's a little old school rule, but it always works. Next point, via the user hat. Think Like a user, if the requirements is Products search box should be at the bottom of the page. You should challenge it. It's not what something uses with like so it's not a good requirement. And lastly, user tracking method Laika requirements traceability matrix. So the RPM is very effective in making sure we capture all the requirements into test scenarios and don't miss anything. And RPM is something that's also asked a lot in the interview questions. So let's look at them in a little detail. So what is a RPM, the RTL or the requirements traceability matrix is used to map requirements into test cases and trace them for coverage analysis. So the purpose of art is to make sure that all requirements are covered. And it's basically a document that would help you to map your requirements so that test cases and there are many ways to do RT m. So in fact, what happens is today. Nowadays all test tools are tests management tools. They have an RPM capability built in themselves. But most simply what an RPM would do is that it would contain the requirement id, which is the user is story number, that description and a corresponding test cases. So now we can record other fields also, like test case. Who wrote the test case? What was the date on victor test case was returned. Who reviewed the test cases, et cetera. But these are all optional. So guys, let's understand in a practical way how a simple rpm can be made on, like I said, are today, most of the tests tools have their own in-built rpm and we would not have to do a lot of work on our end except pulling in the requirements and linking them to the test case. But what I'm going to explain here is a very simple way of creating art TEM. And as you would see, it's a very effective way. And if you follow it, then you would be always be clear that your requirements are mapped to test cases one-to-one, right? So this was the slide, this was the requirement sheet debt will look in the last slide and it contains these User Stories, which is a word, functional requirements. So for the Product Search, sorry, for new products, we are detailed low-level requirement of Product Search. And for that product search, we are implementing it by medium of three stories, the story one story to, and a story three. So what we can do it on a very high level is we can create something like this. Which would say that, okay, the high level requirement is beauty products. The low-level requirement is Product Search. And we have three stories for this story. One story to end is 2340 story. When I created three test cases, test case 001002003, story 2V created test case 004, story three, we created zeros, 050060073 test cases. So innovated. We now know that for all these three stories, we have created test cases. So all these three stories are now covered and I can, I can sign off debt, I have full coverage of these user stories. So this is what the rpm does at a very high level. If you want, you can add more columns to it. Like who created this test case when it was created, whether it was reviewed by somebody or not, all these details. But at a very minimum level, this is a very good RT m. And as you saw, we were able to sign off on the basis of it that we have covered all the requirements. So as we saw guys, we have an RPM now. So if somebody wants to know Are requirement whether it is covered or not, what we would do is we would go simply to debt rpm. And if the requirement is marked in green, we will say that, okay, we have full coverage of this requirement and we would test it with all the possible details. So last point, there are three ways to do a requirement traceability. The first one is forward traceability, where we have requirements and we map them to test cases. So this is what we saw. The second one is backward traceability, where we have the test cases and then we would map them to requirements. And us on is a by directional traceability, which as you would understand, is a combination of both forward and backward techniques. So now you can do it any technique, the forward traceability is the most common one that we saw. And once again, I would say that our Tm is something that is very important because it helps you to map your requirements, two test cases. If you are working in your organization on a test management tool, there would already be capability in built for our team. We would not have to do anything except simple browser and link. But we also saw how to create a simple RPM and sign off on the basis of coverage. Okay, so now we know about our team. Let's move to the last topic of requirement analysis, which is test coverage. So what is test coverage? Our test coverage is a measurement of amount of testing performed by a set of test cases. So we are just measuring how much of a test case is covering in terms of requirement. So it helps us to identify requirements covered and check the quality of products. So if we are able to say that we have covered all ten out of ten requirements, then we would note that our product would be high-quality. So what test coverages doing test coverage is basically telling us how much percentage of requirements have been covered by the test cases. And based on debt coverage, we are able to say that whether our product quality goal has been met or not, right? So let's say we have five requirements and we designed ten test cases covering all those requirements, then we have achieved a 100% testing coverage. So it's a very simple concept are the Andi, that is a little tricky is to design the system for putting the requirements and the test cases that we saw in the RPM. But once you have that, it's very easy to provide your test coverage percentage 0.3. There is a similar term that developers also used, which is called code coverage. But our dont confuse with it, that's not what test coverage is. The developers code coverage is about calculations are based on how much the quote discovering all the scenarios. But when we are talking about test coverage, it's a measurement of how much we are covering the requirements, why our test cases. Next point, test coverage can be covered by static reviews code inside defect check, test management tool, etc. So reviews can help in covering percentage increase. Looking at the code that defects can help. Also test management tools can also calculate the coverage percentage for you. So just as I said in the case of our team, these are very basic things which are nowadays imbedded into all the test management tools that we use. And lastly, an ideal test coverage should include product coverage. So now it should be able to tell you which areas of product are being tested. It should cover the risks. So you should be able to tell you which risks are being tested. And it should be able to cover the requirements also. So it should be able to tell you which requirements are being tested. So all these three areas. Okay, so guys, this was all about requirement analysis phase of SDLC. We have in fact covered more things then that is normally expected from a tester. Because we also saw that how requirements are formed and how they are converted from a high level use cases to low-level requirements and ten users stories. We also saw that how we can make sure that the requirements are correct and how we can make sure that there is no assumption. What we have to do in case there is some misses. We also saw what an RT m is and what test coverages. So in all, we have covered the first phase of our SDLC, which is the requirement analysis. And now we will move to the next phase of your SDLC, which is test planning. So I'll see you in the next chapter about test planning. Till then, keep learning and Hep-C testing. 19. 5.3 - Test Planning: Hello everyone and welcome to this a to Zed deep learning course on software testing. Now this is the second stage of our SDLC that we are going to cover in this chapter. And this is one of the most important topics in testing lifecycle, which is test planning. So guys, as I talked about earlier, test planning is a very important and strategic phase of SDLC. In this phase only we define all the testing plans for future stages. So when we were in the previous state, that is during requirement analysis, we were dealing with requirements. And those requirements were created by different team like the Product Owner, the business, and list, and they were the ones who were creating it. We were only involved in it. But it's starting this phase. The testers role is off total ownership. So we are not supporting somebody. This is entirely the work of it tester. This is the phase where we start our practical ownership work from a testing team perspective. And we define the scope of testing, the estimations, that resource planning, that tools, etcetera that we will use during our testing. And we will document all those things into a document that we will call as the test plan. So this test plan is like a reference guide i strategy guide for us for the next fetus phases of SDLC. This test plan is prepared mostly by the test managers or test leads. And it lists out the various things that we discussed earlier, like what would be the scope of testing, what would be the schedule of testing, what would be the estimation, the resourcing, the risk, etc. And last point guys, it has been noticed at many times companies or test us escape the creation of test plan despite it being such an important thing. And that is simply because of the over-confidence debt. It is a small project or there might not be sufficient time or effort to do it. But that's a very bad practice. Remember there's nothing that can be done without a proper planning. And this test plan is the outcome of that planning show. So whatever be the project, it should always be created and it should always be published. And it should, all our testing in the future phases should be based upon this test plan only. Or it let's move on. Let's quickly see what are the objectives and purposes of test planning. So number one is determining the scope of testing. So the test plan will lay out clearly what are the scope of testing? What we will test and most important, what's more important, what we will not test. So like I pointed earlier also, we should set out expectations very clearly in the beginning. Other test plan on what we are going to test and what we're not going to test. And as you will see later in the demo part is a separate section in the test plan that talks about the scope of testing, what we will test and what we will not test. Number two, document strategy. So like I said earlier, the test plan is our strategy document for the next stages. And in fact, not just for the testis, the test plan is also shared with business and development teams. So they are also aware of what the testing strategy would be. Number three, planning for testing activities. So particularly in the test plan contains details of all the testing activities that we plan to do. And remember, it should plan for testing both the functional and non-functional stuff. Next up is estimate resourcing roles and responsibility. So that test plan is where we estimate for time, budget, and resourcing. We mentioned what will be the roles and responsibilities of everyone? What would a test lead do? What would individual testers two, etcetera. Fifth entry and exit criteria. So as we discussed earlier, each phase of SDLC has an entry and exit criteria, meaning when to start testing and when to end at stage. So we can talk about some of that in the test plan. This is important, especially for cases where these criteria have a dependency on some team outside the testing team. So for example, if we talk about test execution, we cannot begin test execution until the test environment is ready. So that is the entry phase for test execution. And that is dependent on the external team, the system admin team, who will set up the environment and provide it to us. So it's necessary to point out those entry and exit criteria in the test planning document. Next point, risks. So the test plan is also a place to mention any risks that you foresee. So for example, if you don't get the environment for testing by so and so date, the testing deadline will have to be shifted. So it's things like this that every one should be aware of from the beginning instead of getting hit suddenly. And like I said, the test plan is something that is circulated to the business manager, the development manager also. So it's a good place to call out these risks. Last point, the reporting metrics. So the test plan also contains mention of the different metrics that we are going to create like execution report, resourcing report, etcetera. Alright, let's move on to the next slide n, very quickly check what are the advantages of the test plan. I hope that by now you would understand what are the advantages of a test plan and how important it is. But let's do a recap of it. Foster test plan is the roadmap for entire testing. So we don't need to say anything more on this point. I have repeated again and again that the test plan is the strategy for entire testing and it is very, very important. Second, that test plan helps to keep track of all estimates, budgets, resourcing, etc. Third, the test plan contains a section on roles and responsibilities, so it's a clear guide to what everybody is supposed to do. Number for the test plan is sent out to other stake holders, also, like the development team, business team, client, etc. So it clarifies to everyone what testing would be about. And last, we can reference our test plan if any future project comes up. So the test plan is something that goes into the organization project library. And if there is some project that would come up in the future, just like the current project. Or if we are, if we have to redo the same project against same type of project, again, the test plan would serve as a very good reference guide. So this is all about test planning guys in the theory concept, I could go on and on talking about the test plan and why it is important. But it's better to leave the theory aspects here and walk to the next chapter, which is the walk-through of a real test plan. So that will further explain all the details and give a real-world example. So now without taking any more time, let's quickly go into the next lecture, which is the bonus content of this chapter, and learn how a real test plan is. So I'll see you in the next lecture. Till then, keep learning and Hep-C testing. 20. 5.4 - Bonus Content - Walk through of a real Test Plan: Hello everyone and welcome to this a2 set deep learning course on software testing. So guys, this is the bonus lecture of this chapter, which is the walk-through of a real test plan. The test plan is usually made by the test manager or test leads on the team. But here in this course you are getting an insight into what a test plan is and how you can create it. So once you are done with this section, you will have all the knowledge of test plan and you can create it also yourself. Now before I start, I know I have spent a lot of times earlier also. So I promise you I'm repeating it for one last final time. That test plan is the most important document of a testing lifecycle. It is the strategy and guide on how to proceed and all the stages of SDLC.com after this will be guided by this test plan. And so it is very, very important that we always have a solid test plan that covers all the testing aspects that is shared to all the stake holders and that is approved by l. So let's begin. Ok guys, so here is our test plan, and this is created for a hypothetical company called E web services.com. They are having a release in 2020. This is the front page of the test plan. So this is where you will mention the name of the project. You can put your company logo Also, et cetera. And as you can see here, this is the version 2 of the document. So it means that there was a version 1.00 also that was originally created and it went some revision. And so this is the next version. We will see about this version, how it happens on the next page. And as you can see mentioned, I have mentioned the created date, the date on which it was created, the last modified date, and the status of this document, which you can see here is draft. So it is still in drafting stage. Now, we have circulated it to all the stake holders for their feedback. And once everybody signs off on it, it will move into the approved stage. Once the project is completed, it would move into the completed state. So the current is stages draft. Now before I go to the next page, let's notice this small footnote at the bottom that says private and confidential. So the test plan is a confidential document. You should be very careful not to share it with everyone because there are a lot of factors in it. Like it talks about changes that have not yet happened on the website, they are not public. Second, test plan talks about money matters also like cost, resourcing, budgeting, etc. So that is also confidential information. So if you are creating the test plan or if you've got it from somebody else, be sure not to forward it to anybody who is not involved in the project. Or it's page two is the version history we saw on the first page that this document is version 2.0. and we can see why. So the first version was created on January 31st, but then some changes came in and so a second version was published on February tenth. And what was the change? As you can see in the last column, the change wasn't revision to the schedule. So you can see that we are providing each and every minute details here. We are just not putting out that this is a version two. We are also letting everybody know why there is a version two. Okay, moving on to the next page. This is the table of contents, so we don't need to read each and every line because we would be covering these anyway in the next slides. But there are couple of things that we have to check in here. And the first thing is this reference. So at the end of the test plan, we would give some reference documents if we have. So it helps people to link it up to something in the past. And we would also provide the key terms here. So if there is any term that we are using through the test plan that would not make sense to everybody, then we would provide them definition of debt Keaton at the end of the test plan. Okay, moving on. So the first section is introduction. What is the project and what is the objective of the test plan? So the test plan describes the testing approach for 20-20 release of E webservices.com portal and a test plan has following objectives. Number one is stressed his strategy. So we are listing the things about requirements, share dueling, entry, exit criteria, etc. Number two is the execution strategy. So we will mention the procedures in execution of our test cases. What are the different statuses? What is the closure activity, et cetera? And last is the management aspects. So we will talk about the communication risk-management, escalation effort, all of these things. So these are the three points that are telling us at a high level what the test plan objectives would be. The next section is about the project description. So we will keep, we will keep it very brief. We will not talk about too much about the purpose, about the project. Because remember the purpose of this test plan is to talk about the testing aspects, not the project in general. So we have mentioned a very short description, like we are launching a new service in May 20-20. And a project involves testing support for the website, mobile site, and mobile application. The project is spans the entire platform of web services, making information available anywhere, anytime. So we have taken this content from the business requirement document, but again, we're keeping it very short just to give a brief summary. The next section is on a scope. And you will recall I kept saying earlier In the past slides that we need to mention in the test plan what we will test, and more importantly, what all we will not test. So dat is here the first part. We are mentioning the features that we would be testing. And as you can see that we are mentioning the items clearly. We are giving a short description about it. We are mentioning that date also. And then finally, who will test? So in this case, like VR, making this test plan from the purpose of ABC IT tech limited. So IBEC tick IT tech limited is responsible for all these aspects. And as you can see, we are not just talking about the functional aspects, we're also talking about the non-functional aspects. So as I mentioned to you in the past that the test plan is something that should provide descriptions about both the functional aspects as well as the non-functional aspects. The next part is what we will not test. So we will not test the hardware software setup. We will not test the compliance testing, we will not do the security testing, etc. And for each of these things, we are mentioning that reason also why it is not in the scope, may be it is not needed. Maybe another team is doing it and other companies doing it, whatever. So very important we have to mention the scope of testing, what we are going to test, and what we are not going to test. The next section is on test approach. So what are the different kinds of testing we will do? We will do is smoke testing with the purpose of verifying builds stability. What will be the scope of this testing? What all the things we will cover. What is the method that we will use? So we will do it manually and from the Excel sheet for defect logging, we will use the JIRA tool. What is the frequency that we will do? We will do it every day, as many times as we get a new built. So likewise, we have mentioned for the functional regression testing also. Here we are saying that we will do both the manual and automation testing. So manual testing we will do via the cutest test management tool and automation testing we will do via the selenium tool. And in both the cases, any defects that we will find, we will be recording it in the JIRA tool. As you can see here, apart from the functional aspects, you've also mentioned, mentioned the non-functional testing. So we have given the performance testing details. We have mentioned the things very clearly that we will do the load testing for 10 thousand users. We will do the load testing of navigation, login, and checkout flows. We will use the Load Runner tool for it, and we will do it after the functional testing is completed and no critical blocker defects are open. That means that the side bill is stable. Okay, the next topic is pass-fail criteria. So when do we call it test cases passed, when do we call it as failed, blogged, et cetera? If there are more status, we can put it here also. So the purpose of mentioning this section is to let everybody know what is the expectation. When they see this status in their report, they would know what it points to end. They would be aware of it. Next is the test entry and exit criteria. So we talked about entry and exit criteria when we were doing the stages of SDLC. So those sort of things go here. And I have given only some high-level examples. So like example, we need the requirement documents to be signed off. Unless the requirement documents are not signed off, we cannot enter into the testing stage. Who has to sign it off? It has to be completed by that bn dev manager. And we are mentioning that it has to be completed by April first 2020. If it is not done by that date, then it would be a risk. So here, as you can see, I have pointed these things in green, so it means that they have been done. But the last aspect that the testers have access to environment, test data and tools for testing. This is not completed. So there is some risk in it. We can mention that risk detail here and which team is owning debt risk. And we have mentioned in the note here that this was supposed to be done by April tenth. So let's say it is not done by Appleton, then we would be impacting the schedule of the project. Likewise, we have given the exit criteria also end. I give just one high level example here. So we are saying that we will complete all test case execution one week before the release. So that releases plan for, let's say me 18. We are seeing that we will complete all the test case execution by mutant. We will call our testing has completed if at least 95% test cases passed and there is no critical or block or defect open. Soviet mentioned the exit, exit criteria of testing both in terms of our execution percentage and also in terms of defect. Next, what are the test deliverables from our side? So now V will provide these reports during the testing, we will provide an test execution report that would include the percentage of completion along with the defects. And it would be sent out daily at the end of working hour, 06:00 PM. So we're very we're mentioning all the details very precisely. We are not just seeing that we will send it out at the end of working hour. We are mentioning the time also so that everybody knows we are trying to set the expectation and everybody should be set given the clear expectations. So that's why we are mentioning it at the clear thorough details. We are also saying that we will provide the effort report that would be sent out weekly every Monday. And we are saying that we will be sending out the project status report, which will be sent out by the project manager every Monday. So these are the sort of reports dad would go up to the senior management also. And oftentimes they would be very interested to find this section in the test plan. So that is why we have mentioned here. Next we are mentioning that criterias in which testing would be suspended. So let's see if there's a problem with the environment. The environment is not a stable, then testing will get suspended. Or if there is a problem in getting the test data from production, then also testing would be suspended. And like I have mentioned to you earlier, also, whenever we are giving a risk or a blocker, we should always mention the way out of it. So we are also saying that the testing will resume as soon as we get a new healthy build. And testing will resume as soon as we get the test data. So we are providing both the information here. Next sub-section, do we have any staffing or training needs are IF that does a team need any sort of technical training or tools training, et cetera? So we are saying that the team is already trained on tools, but we need a general process training like what is the process of creating defects in the organization? Or who do we need to assign the defects, those sort of things. So we are telling again from our end dead days has dependency on the client. That dependency is that the client should arrange to provide us training for these sort of things. Okay, the next section, section number three, is for risk. So we are mentioning any risk that is there. What is the probability of that risk happening? And if it happens, what is the impact? We are also mentioned in the mitigation plan of the risk because as I said, we should always provide this information. So like one example is, is if there is a delay in the requirement sign-off or test environment is not stable. The testing will be delayed. Makes sense if we're not getting the requirements on time or if we are not getting a healthy test environment or testing will be delayed, the probability of it is happening very high. And we can say that because let say we are, We had to sign off on the requirements by next week and we are still debating on the requirements. So that way we can say that the probability of not reaching dead deadline is high. And we are also saying that if the deadline is not reached, there will be high impact on the deliverables, so we would not be able to complete testing on time. So what is the mitigation plan? The mitigation plan is to sign off on the requirements one week before testing and to keep some buffer time between the end of testing and go live. So data, even if there is some Shut deal slippage, we still have some time to make up. We're also mentioning other details like if there is any risk with onboarding people or if there is any risk of a scope change, etc. So guys, the idea is that we should provide the true picture. We should not try to hide things. We have to put every detail clearly because now is the time that people need to know if there is any risks so they can take action on it and resolve it. Okay, moving on, the next section is for test environment and infrastructure. So what do we need for testing? What is the device we need for testing? What is the operating system, the browser's, etcetera. And as you can see that we have given the details right up to the point of OS version and browser also. So we have to be as precise as possible. And we are also telling them that we need these things are one week before they start off testing. Right here. Right? Next we talk about the roles and responsibilities. So who will do what, what would be the role of the project manager? What would be the role of the test lead? What would be the role of test team and what would be their responsibilities? So this is kind of setting the expectations. Who would do what, and it is also providing the communication plan in a way because let's say if there is an issue with the resourcing and budgeting, we know we have to reach out to the project manager. If there is a problem with the matrix, we have to reach out to doctests lead. If there is a problem when individual defects retesting them, we have to reach out to the reported that a regular test team. So in a way we're setting out the expectations. We are telling them that who will do what. And next we move on to the dual. So how much time it will take in test design, how much time it will take in test execution, reporting, etc. So you can be more granular if you want. If there is automation, we can say Automation setup also our training times also those sort of things, right? So we are publishing the schedule for everybody, so everybody knows what is the effort needed for each section and what is the start and end date? So in a way, we are also telling them that test design needs 1000 man hour. And if we have to start by April 15th, we would complete by April 30th. Now, if there is a delay for some reason, the requirements are not clear or anything and that we are not able to start test designed by April 15th, then there would be a similar delay in the end also. So that's what we are clearing here. And we are also given the total effort in here so that everybody knows what is their effort from the testing team. Moving on, here is the page to get a sign off on the test plan. So like I said earlier, it's not just important to create this test plan, e-mail it to everybody and forget about it. No. We have to make sure that every team that is the stakeholder beat business team or the development manager or anybody in the client side, they are agreeing to this test plan. They are approving it. So we will put their details here, the name, title, date, and we will just put a virtual signature like their firstName, lastName like debt. Finally, we have the appendix four offenses so we can provide the reference for something that the team can refer to for clarification. So for example, this test plan is for the 2020 release of E web services.com. We have provided the link to the 2009 teen release plan so that anybody can go there and they can look at it, what it is we have we are also providing the link to the SharePoint portal, the Cloud Drive wherever it is placed so that anybody can go and anybody can take a look at it. And finally, the last section is the key term sections. So if we talked about some terms that might not be clear to everybody, we can put them here. So like for example, in the past pages we said that we would be reporting defects in JIRA. So let's say somebody does not know what Gita is. So we are telling here that it's a test management tool. We said, we will say that OK, the tests that would be able to pull the data from SQL. So what is SQL sequel is the database of test data just like this. So from a layman perspective, they know what we are referring to. So guys, this is it. This is the end of the entire test plan. And as you would have noticed, it contained every fine detail of testing. What we will test, what we will not test. What is the kind of testing we will do? What are the risks? What is the schedule, effort, communication, everything. So I hope you liked it and it helped you get an insight into the practical aspects of things, as I promised in the course. If you have any questions, please do not hesitate to put it in the Q and a section, or you can email me also. So we will continue on our course journey. And I will see you in the next chapter with the next stage of SDLC. Till then, keep learning and Hep-C testing. 21. 6.1 - Introduction to Test case design: Hello everyone, and welcome to the sixth chapter of this deep learning course on software testing. So this is our D6 of learning. And in the past chapters we have already covered the first two stages of SDLC, which is the requirement analysis and test planning. So now we have a clear requirement and a solid test plan. And in this chapter we will cover the next two stages, which are tests designed and environment setup. Once again, environment setup is a topic which most courses do not cover, but it is equally important parts, so I've included it here. Alright, let's begin. Here's what we will cover in this lecture. We will start with basic guidelines to writing test cases. Some of the techniques we use for effective test case creation like boundary value analysis, equivalence, partitioning decision table use case. We will see reviewing and maintaining test cases and why they are important. We will see tests management tools. And then we will move to test environment and data setup. As part of the bonus content of this lecture, we will actually write test cases for an e-commerce website. So pretty exciting stuff. Let's start with the first topic, which is writing test cases. So what is a test case? A test case is nothing but a series of steps to verify a particular functionality or flow. So let say there is a functionality like login to Facebook and we will write test cases to validate it. Or there is an end-to-end functionality like placing order on an m isn't mobile app. So we will write test cases for that. So our test case does nothing except our verifying a particular functionality or flow. Next, what details will be put into a task is when it test case should have fields like Test Case ID, which is the unique identifier of the test case. Test case name, which gives a brief idea what the test case is about. Objective, which is the purpose of the test case. Precondition, which is anything that we need to do before doing the test case. For example, if the test case is fourth order history verification, we need to have a user account with some order so we can verify it. Next, the test data. So what is the login details, the product name, that card number, etcetera, in a test case for order placement. Next thing that is in our test case is the E-step, so very important. What are the exact steps by which we can test the functionality or flow? Next, what is the expected reserves? So what is the requirement that we are testing? What is the actual results? So what really happened when we were running the test case? Next, what is the status? So whether the test case passed or failed or incomplete or got blogged. And we will see what each of these is status means in the next slides. Next, we would put in the test case any defects. So if there was a scenario debt failed and we logged a defect, we will mention that defect number. And finally, we will put some comments also in their test case. So this section is therefore anything that we want to add. Like example in the Place Order test case, we will normally put the order number that we play so for, so it is there for future reference. So these are some of the fields that are present in a test case. Of course, this is not a standard list. All organizations add or drop some of the fields, but this is the most common and mostly mandatory fields steps should be used. Next point, that test case should be designed on functional requirements. So what is the input to the test case? How do we create the test case? We create test cases exactly on the basis of the business requirements. So we should not make any assumptions when creating test cases. We should not we should not put anything there based on our understanding. The only thing that should come in the test cases should be from the business requirements and the expected results should be exactly the same as the requirement mentions. Next, the test cases should be reviewed and updated frequently. So guys review and maintenance are two activities that often get dropped in the real world. But they are very important because if it, because if we do not do these things, then it would make our testing ineffective after sometime. And we discussed this principle of testing that is called pests parasite pesticide paradox in the initial chapter. And we have two slides in this chapter to discuss more about review and maintenance. So before we move ahead a footnote, you might hear the word test scenario and test cases at the same time in your discussions when you are working in any company. But these two terms are actually different. Test scenario is a wider term, which means you are covering more than one test case. So login is a scenario with separate test cases for valid login, invalid login, disabled logging, et cetera. So I hope you now understand the difference between tests scenario and test case. Alright, lets move to the next slide. What are the best practices to follow when writing a test case? So here they are. First of all, the test case should be simple, clear, and of course provides sufficient coverage. So do not write heavy worked sort of validation state are not achievable. Instead, keep the details simple and clear and most important, make sure you are keeping sufficient coverage, whatever else or test case does, its most important job is to verify the requirements and it should never compromise on coverage. Next, the test case should get expected reserves from requirements. So we already talked a bit of this in the last slide. And we should always pick the expected result from the business requirements and not the correct current application behavior. So one of the most terrible mistakes that we can do is to go to the application, see how it works currently and put data as the expected result of test case. And that's a big no because remember you might be making the incorrect behavior of the application, the expected functionality, which would be a very big blender. So do not put in how it works. Do not go by what the developer says or do not go by what the adult testers are seeing, always refer the requirement document to make sure that you are putting the expected results from there. And if you're not sure of the expected result or if there is a confusion with the requirements, just check with the B. Next, do not repeat test cases. So there's no point testing. Same thing again and again in different test cases. Number four, follow the navigation flow. Do not create test cases like, let's say if you are creating a test cases for e-commerce website, do not create test cases like login, then checkout, then add a second item, then Logout, then checkout, then login know are tried to keep the flowed natural and tried to keep the flow as a real world user would do. Next, keep the end-user in mind. So remember we are testing for the benefit of end-user. So we want to design test cases that would replicate the user behavior as much as possible. So however the user would normally do it, we would try to do it in the same vein, our test cases as much as possible. Our next keep a balance between positive and negative scenarios. So most of the times testers are mainly interested in doing negative testing. So let's see if there is a quantity field. We will fill 9,999 there and see what happens. So this is a valid flow, but it's not the only flow. It is more important to first test the positive flows data user would mostly do, like putting in quantity one, quantity ten, quantity 100, etc. And once we have sufficient coverage for positive scenarios, then only focus on the negative scenarios. And last review the test cases, keep them updated. So this is one of the points that I will keep stressing this chapter. Remember if we are not updating our test cases, they will lose their effectiveness after awhile and he will not find any defects. So it's very important to keep, to review our test cases and to maintain our test cases. So these were some of the best practices when creating a test case. Another best practice, or rather say, scientific method, is to use some techniques when designing test cases so we get the best possible coverage in the minimum number of test cases. So in the next chapter we will cover four of these most common techniques. So I'll see you in the next lecture with these techniques. Till then, keep learning and Hep-C testing. 22. 6.2 - Test Case Design Techniques - Boundary value, Equivalence Partitioning, Decision Table: Hello everyone, and welcome to this K2s and deep learning course on software testing. So let's see now four techniques that we can use for effective test design. And that means to achieve sufficient coverage in the least possible number of test cases. So let's read about them quickly and then we will get into an example to understand them better. So the first technique that we have is called equivalence partitioning. And what it does is it divides the test conditions into equal number of partitions. And then you can test each of the partitions. So let's say for example, if somebody wants you to check five different fruits, so what you will do is you will not eat the entire fruit to figure out what it is, you will just take one portion from the, from each of the fruits and then you would be able to tell which, which fruit it is. So the same logic works for equivalence partitioning. We take the dataset that we have to verify and we divide it into partitions. And then we take one sample value from each partition. And that way we are able to test each of the different partitions using very minimal number of combinations. Right? So let's say for example, if I have to test numbers instead of King and each number one-by-one, I will verify the negative numbers are 0 positive numbers like that. Or if there is a quantity box that accepts four digits. So what we will do, we will put in 0110110100 and so on to get the grouped combinations. So this was equivalence partitioning. The next one is boundary value analysis. So this particular technique is based on the assumption that boundary conditions are most likely to fail. So if there is a quantity box that accepts quantity one to 99, then it would most likely not fair in the center range that it will not fail in the array values like 30-50, XX, right, would not fail there. Instead, the risk of failure is more at the boundary. So if the quantity accepted is one to 99, then we should verify it with minus1, 0, one ninety eight, ninety nine hundred to these kinds of value that means along the boundaries. And the third technique is decision table. So our decision table is something that we have all done at some point or the other. It basically means putting the combinations for different inputs in a tabular form. And then we test each of them. The last one is use case testing. So this is based on the use case that we saw earlier in the requirement analysis chapter. We don't design test cases based on the siloed areas. We designed Dart test cases based on the entire US case status. The way the user interacts on the system from its starting to end point. So this was a brief introduction about the four design techniques. Let's see them using an example so that it's more clear. Okay, so let's look at an example. Let's think that we are working on a website. And that particular website takes in the age of the person. And based on dat age, they tell him what would be his insurance premium. So very simple use case and let's figure out let's think about it that you go to a website like policy bizarre.com or something. And there is a field there that asks for your age. And there is a field here that outputs the premium. So the moment you put in your ages 30, it shows some premium over here, right? So very simple use case. And how that use case works is the rules that are designed for it is example, if you put your age in S ten to 20, the premium would be 1010 thousand. Let me just make it ten to 20. Okay. If you put 21 to 30, then it would be 20 thousand. If it put in 31 to 40, then it would be 30 thousand. If you put in for T1 to 50, then it would be 50 thousand. So very simple use case and based on very minimal number of combinations, Let's say this is our requirement and we have to verify it. So if we want to verify it a 100%, then the, then the, then what we would have to do is we would have to key in each of these numbers. So we would have to do 10111213 all the way till forty seven forty eight forty nine fifty. We would have put in all these numbers one by one and make sure that the premium matches the value over here. But as you can assume, this is not possible because these are so many permutations and combinations entities where it, time taking plus this is a very simple scenario that we are discussing here. What if you have to test the H from 0 to 99, right? Or what if there are many other combinations also to consider except the age? So as you can see, we cannot test all the combinations that's very time taking. And that is why we will use the technique of equivalence partitioning. So what equivalence partitioning would have done? The first thing would, it would have divided it into partitions. So here it is already divided in partitions. If you did not had it, you can divide it into partitions like this h of 1010. Or if you think that there's a lot of combinations that are happening for each, each type. So you can divide in the range of 55, for example, ten to 1515 to 2020 to 25. It depends upon the requirement. What is the business case? But what we have to do is we have to try to keep equal partitions so that that data is divided equally, right? So once we have the partitions, what we will do is we will take one value from each partition. So I'll take 15, twenty three, thirty seven, forty six and datas, and that's it. And then for each of these values, I will check the expected results. So if I key in 15, it should show 10 thousand, 23, 20 thousand and like debt. So that's it. We have achieved sufficient coverage. We were able to reduce our inputs scenarios heavily from all these different values to just four different values. And even by doing those four different values, we have been able to test all the possible combinations. So that's what equivalence partitioning is all about. Number one, divide the test conditions into partitions, like we see here. And number two, take some input from each of the partition and then test the application using it. So that was equivalence partitioning. Let me just write here equivalent partitioning. And next is let's say if I want to do boundary value analysis, right? So boundary value analysis also works on the concept of partitions. So first we would have to partition the data are that would help in determining the boundary values. And then next what we will do is we will identify the boundary values for it. So the boundary values are 9102021 along these partitions because like I said in the boundary value analysis. The assumption is that the system would most likely fail at the border value. So I have taken the border values. Remember I did not take 11 or 19 because that's in the same bracket as ten to 20. Alright, next I'll take from here 20, 21, 30313231404140415051. So that's it, that's our data or my boundary value combinations. As you can see that some of the combinations overlap. So let's get a unique list. This is the unique list. So this is the, this is the unique list of boundary values. I think it's ten boundary values. So what we will do is we will just take this ten boundary values and test the application by entering these values. And it, and that way we would, we would have covered all the possible combinations. Now, some of these boundary values are not valid. For example, 951 sort for dat it should the application should give me a proper error message that please enter Age between so-and-so number or you have incur entered an incorrect H, Please? Correct again and something like that. So as you can see, we have been able to test both the positive and negative scenarios for this. So now this was the technique of boundary value analysis also. Now there's something that I want you guys to practice. So what you can do is at your end, you can think about some more scenarios that use boundary value analysis and equivalence partitioning. So let say the quantity box of an e-commerce website like Amazon that accepts quantity 12999. Or if you go to a clothing website like month roar Zhong, they have opera offers like if you spend 2 thousand rupees, you will get 5% off. If you spend 3 thousand rupees, you will get 10% of unlike debt. So think about some of these scenarios, right down these requirements, and then you can apply the techniques of boundary value and equivalence partitioning on them. If you have any questions, you can post them in the queue end section and I'll help you solve it. Alright, so this was the technique for boundary value and equivalence partitioning. Let, let's think about the third technique now, which is decision table. So decision table works on the concept of electronic statistic called as decision table. So what we do is we created tabular representation using the combination of each values. And we tried to put in all the permutation and combination for each values. And then based on that, we identify the outcome. So that way we are able to get the combinations for all the values. So let's think about Facebook. So if I go to Facebook, there is a box for login and there is a box for password, right? And then there is an OK button or sign-in button or login button. So the scenario is that if you enter a valid login ID and password, it will log you in. And if you enter an invalid login ID or password, it, it should show you an error message, right? So as you can see, there are two combinations here. So the number of venues that would come in would be two to the power two means for soul, if I have to put four values, this is how I would put it. By y n, n, by n, y n. So the y's here mean nothing but valid login. So I'll just change all the y's to valid. And the Ns mean the invalid login soil change all the ends to invalid on it. So this is the combinations that I got, and this is covering all the possible permutation and combination. So let's figure out what would be the expected value if I'm entering valid login and password will be logged in. So I can log in. And for each of these conditions, it would give me an error message. Why? Because either one or both the conditions are invalid, right? So this is how we design our decision table. This was for a simple two-by-two combination. We'll see you also. What is the how to design it for a 33 value combination? But before we do that, I just want to plant a question in your head. So think about these three error scenarios. Like this error is happening because the password is invalid. The center is happening because the login name is invalid and this error is happening because both the combinations are invalid. So for these three error scenarios are, do you think the error message will be the same on the website? So think about it for a while, while I draw the three combination, our decision table and then we'll get back to this question, right? So again, for the three combination value, that means I have to do two to the power three is equal to eight. So combination one, combination two, combination three. And when I have to design eight value our decision table, it goes like this. Y, Y, Y, Y, and n, n, n, n n. So 444, next is 22, and next is 11. So this is pretty standard technique and a thing that nothing's too complex here, this is up your sound, simple technique. You only have to figure it out what is the number of combinations and take the power of two for that combination. And this is the value plotted here. And then depending upon this condition, you can figure out the requirement that if all the three conditions are true, maybe it will log in. If anyone of them is false, it will not login like that. So that is how you are tests using a decision table for three by three combinations. And in fact, if you are testing for a huge number of combinations, you don't even need to draw it. You can simply go to Google and search for decision table tool. And there are a lot of tools available in the market. For example, Jae rap is one of them. So what it does, you just give them the combination. And based on that, they give you all the possible permutation and combination for those inputs. And then you can figure out what is the expected result and design your test cases accordingly. So this way you have been able to verify all the scenarios and you have been able to create your test cases properly. Right, so dat was decision table. We have covered three techniques so far, equivalence, partitioning, boundary value analysis and decision table. Right, so pretty nice. Now, before we go into the last technique, let's recap back to this question here that I asked. So my question was that in these three error conditions, the error is happening because one of the digitize invalid or both that datas are invalid, right? So in that scenario, do you think that the error message that the website will show would be the same or different, right? So if you guessed it correctly, the answer is no. And that is because in any login scenario, we should never tell the customer debt your login id is wrong or that your password is wrong. We should always go with the common message that would say something like either you login, ID or password is wrong. Please try again. You can try this thing out on any of the website and see what they would give you. And data is something that we do because we don't want to help the fraud makers by telling them that their debt, the password you entered was incorrect, but hey, the login ID that you gave, it was correct. So now we have indirectly told them that whatever login you gave them is correct. The only thing that you gave incorrect was the password. So keep that login ID and run a random password generator and you would be able to have this account. So in a way we would have we would have made the work easier for them. That is why we do not tell it directly at your login, IT IS wrong or your password is wrong. We always go by your dual error message. And the same thing happens when you are using credit cards. So we will never tell you that your credit card number was correct, but your CV has wrong because then again, we are telling the customer that whatever number they put in credit card was valid. Now they only need to have the three digit CPV number. So that is why in case of payments also the error message says that please enter your payment information or your payment information might not be correct. Please try again. Okay, so that was something new we learned in addition to the testing techniques. Now let us see the last technique that is the use case. So Use Case technique works on the basis of the use case diagram that we saw last on chapter. And it does nothing different. It on it creates the test case. And it creates those test cases only on the assumption that you are doing it from the entry point of a user. So it would do something like this. Let's say you're happy path would be enter, login ID and password, and login to system. So this is very simple, very basic test case for a login system. This is the step, this is the scenario, and this would be the expected result. User should be logged in to the system. Right? So this is the expected result, and this was for the happy path. Likewise for the sad path, we will do things like we said, this is one and invalid login and valid password. And number three, click login. User should get error message that either you login id is incorrect or your password is incorrect. So we have done nothing but what you bought we have done is we have combined two techniques. So we have written the test cases as the, from the viewpoint of a user. And we have also used the decision table and to make sure that we have the correct combination, right. So that's also something that you would do in the real life. We never used just one test case design technique to figure out all the combinations. We always use a multiple, all different types of test design techniques. So you'll be using equivalence partition also. You would be using boundary value also you will be using decision table also, you will make use of all these test design techniques. Men's, you are working in an organization and especially for this use case one, as you can see that it's normally just a translation of what we have done. It does not, it might not look too different to you because we are taking only a simple scenario of login. But if you are thinking about a bigger system like the end-to-end checkout flow for an e-commerce website, then it would be very different because you would have to cover the end-to-end flow from a user point of view. So alright, so we have learned for our techniques to get a good test case coverage. Once again, they were equivalence partitioning, boundary value analysis, decision table, and use case. You can use these techniques in your day-to-day testing work. And it will help you avoid too many scenarios. And you would be able to cover everything using the minimum number of test cases and it would save you time. Remember, don't just go with one technique. Tried to use as many of these techniques possible in the same input test combination. So you are able to achieve maximum coverage with the minimum number of test cases. Alright, so now that we have learned how to create test cases and how to create them scientifically using all these techniques. We will proceed with the next lecture, which is about review and maintenance of test cases. And we will also talk a bit about tests management tools where all this activity of creation, maintenance, and review happens. So I'll see you in the next lecture with these topics. Till then, keep learning and happy testing. 23. 6.3 - Test Case Review & Maintenance, Test Management tools: Hello everyone and welcome to this a2 deep learning course on software testing. Let's talk about test case review now. And as I had mentioned in the past, also, this is a very important activity. And why it is important? It is important because anyone of us can miss things when we are creating test cases. Or we might not understand the requirements correctly. Or it might be that we cannot single-handedly Think of all the flows. So these are just normal gaps that can come in our way of working. And that is why it's important that whenever somebody is creating test cases and other person on the team is reviewing it. So let's look further on this topic. Number one, test case reviews, important activity that should always be done. In fact, test case review should always be planned for each test case design is step and there should not be any excuse to ignore it. Second, even if it is not explicitly mentioned, test case design should include test case review also. So whenever we are designing test cases, Let's not wait for somebody to ask if it is reviewed. We should go ahead ourselves and ask for it to be reviewed from whoever the company Processes. Third, the test cases should be reviewed by your peers or by your supervisor. Even Weekend Review our test cases ourself, but it's not recommended because we can make the same mistakes again. Fourth, why we need test case review? Well, it's needed because we need to make sure that we have sufficient coverage of all the requirements. It is needed to find errors like incorrect flow, missing test data, missing precondition, etc. And last, it is needed to ensure compliance to that test case design best practices, whatever it is the rule in our companies. Lastly, test case review should be documented for future reference. So remember guys, it's not like pinpointing and telling your mistakes. It's all about improving things. So we have to capture what was missing in the test case and it would help us to avoid making the same mistake in the future. Alright, so this was about test case review. Once again, it's a very important activity. Companies normally tend to ignore this activity, but we should be very, very careful that whenever we are writing any test case, it should always be reviewed. Okay, the next aspect that we have to cover in task is designed is test case maintenance. So Let's think about it in real life. Let's say that our threat, our favorite social media site is changing its CY. So Facebook is coming up with a release every few weeks. And in that release they are changing the layout of their homepage. They are adding new features every time. So if we keep on using the same test case again and again to verify their website, at some point we are going to miss the important detail because our test cases bond have debt validation, right? So they keep on making changes to their website, but we are not updating our test cases. So at some point, we will miss the validation data that should have happened for the website. And that's why it's very important to maintain our test cases. So to summarize, as applications changeover time, test case maintenance is needed. In between designing test cases for new changes and getting them reviewed. We should, we should also plan to maintain the regression test cases. Second, if test cases are not maintained, it can cause in correct testing misdeeds, scope, or increased effort. And the last point is especially true for new resources. So when somebody new joins into the team and you ask them to go over the test cases to understand the flow. They won't be able to understand things correctly. Why? Because of our test cases itself are not correct. Right? Next point in an automated project test case maintenance also requests maintenance of automation is script. If you are working in a project where we are automating things. Also, whenever you are changing the manual test cases, we should also update our automation scripts so that they are always in-sync. Last point, test case maintenance can be simplified by number one, keeping a track of new requirements and finding the impacted test cases. Number two, keeping test cases in a modular structure. And number three, updating test cases rather than creating new ones. So pretty straightforward, but let's art. Let's think about it. If our test suit is, is structured correctly, like for example, we know where our homepage test cases are, we know where our search test cases are. We know where our checkout test cases are. We can quickly find them and update them for any changes. Also, if our homepage is changing, then it does not mean that we should create a new test case every time and add it to the test suit. No, we should try to find existing test cases and see that if the functionality is already covered there and we should just update them. So do not create new test cases because the way you would have confusing old and new test cases always tried to find already present as cases and update them. Okay, so we have very quickly covered these two important points, reviewing test cases and maintaining them. And we had also looked at creating test cases in the past. So that way our entire journey of test case creation is completed. We know how to create test cases. Now, we know how to create test cases using scientific techniques like equivalence, partitioning, boundary value, etc. We know how to review test cases. Byte is important and we know how to maintain test cases and why it is important. So this was all about test cases. But the next question that comes to our mind is where all of this activity is done. So where do we create test cases? We, or do we maintain them? Where do we create test suit, etc. So let's check that out in the next topic, which is test management tools. So we talked about writing test cases, updating them, creating a suit of them, etc.. And we will also see executing those test cases in the next lecture. But we need an application to do all this. And data application is called the test management tool. So originally the test management tools were used mostly for creation and execution. But nowadays they support lots of activities like reporting, defect tracking, our TM requirement, mapping, et cetera. All most all the tools that are present in the market. They support the basic SDLC activities and they differ from each other in terms of cost feature is scalability, integration with third party, etcetera. Some of the most common tools that are present in the market, or ALM, Q test, DFS, et cetera. Alm is something that was used a lot in the past. It is still used a lot today. But Q test in particular is a new tool that is gaining lot of market these days because it is very closely integrated with all other tools like JIRA. And what you can do is you can go to their website, which is, which you can Google on Google for Q test. And then you would find their website and they have a free trial version over there. So you can sign up for a 30-day free trial period and you can look how the tool works. Alright? So, alright guys, so this was all about test case design techniques, review, maintenance and test management tools. We have learned how to write test cases. Good further read would be to go online and search for terms like test cases for Android app, test cases for Facebook, et cetera. If you are going to an interview, they also asked you for test cases of a pen, test cases off a lift our door, et cetera. So you can read about them. It's just to check your analytical skills. Anyway, we are going to cover these questions in the interview lecture of this course. And we will also write test cases for an e-commerce website in this chapter itself as part of the bonus content. All right, so let's move on and we will see you in the next stage of SDLC, which as I mentioned earlier, is a very important but neglected stage known as test environment set up. So as soon the next lecture about this topic, till then, keep learning and happy testing. 24. 6.4 - Test Environment & Data Setup: Hello everyone and welcome to this a to Z deep learning course on software testing. So in today's lecture, we are going to cover the test environment setup. And as I mentioned in the end of the previous slide also, this is one of those topics which is not covered unfortunately by the other courses. And that might be because this is one of those areas where the testers are not directly having the ownership. We've worked with the other teams to help with the environment setup, but we are not the ones who are actually doing it or have the full ownership. But as I said earlier, this is a very important phase of SDLC. And as I have mentioned several times in the past, we cannot improve on things or we would not get a full understanding of things if we do not understand the entire process. So that is why I have included the test environment setup as part of this course. So let's take a look at it. Let's think about what is test environment first. So we talked a lot about different aspects of testing, but we actually need some place to try them out, right? And that is the test environment. So example, if I go to facebook.com or m is n.com dat is there live environment or production environment? We can test things there, but it's not the right thing to do cause if even there is an issue found, it means that it's already live and it could affect real-time users. So obviously we also needed test environment to verify things first, and then once it is verified, we then move it to production. Okay, so looks like we need to environments production and test, right? Well, no, because we are, we'll developers write their quotes and check in all of it. So we don't want them to write their quotes and check it directly to the test environment because it would make the test environment unstable. And obviously we don't want them to do it directly on production. So that is why we needed to herd environment also, which is the development environment. So as you can see, there's a lot of logic that goes behind how environments are setup. And once again, that is why it's an important topic and it's a very crucial aspect of testing. So let's see what the slide says. First, the test environment is a setup of hardware and software for testing team. So particular test environment is a combination of the hardware and software aspects both required for the setup. Second, a test environment setup is done by system admins or operation teams and Development Team mostly. So these are the two teams which would work mostly on test environment setup. Although testers would also be involved. Once these are teams confirmed at the environment is available via testers would run I smoke test on it to certify its Health and Disability. And even after these teams have certified the environment as ready for use, they would the system admins would continue to monitor the environment for stability. Third thing, the test environment should be isolated from the production environment. So we want to keep all environments in separate. They should not impact each other. And last, let's see what some of the common test environments are. So first we have an environment where development happens and as part of validation that unit tests are run. Second, we have a QA or test environment. We're most of the testing happens. So this is the place where we would do the bulk of our testing, regression testing, retesting, new changes, testing everything. Third is the UAT or pre brought environment. So it's just like the test environment. But the difference is that that data here more closely replicates production. So this is where the acceptance tests are run by the business analysts or end-users. Oftentimes this can be done on the test environment also, but we want to keep it separate for stability. And finally, we have the production environment. So this is the live environment. We're real users are accessing the site and obviously they are the ones who are testing it, right? So the list above also shows the progression of environments. The new changes or fixes are first ready on dev environment, then they are moved to QA environment, then UAT environment, and finally to production. So this is a very basic list. Depending upon the organization, there may be more or few environments and sometimes they are. There is a load test that is the, there would be a performance environment also which will be used for the purpose of performance testing. Okay, so we know now what testing environments are, but to test our scenarios apart from the test cases and environments, we need test data also. So let's talk a bit about test data. And data. Test data setup is an essential activity. So what this activity means, it means creating test data that we will need in the execution phase. So in fact, testers usually spend lot of time creating the test data. And if you think about it, it makes sense. If I have the test data for valid login, invalid login, valid user ID, but incorrect password, etcetera. All that is left is to enter them and verify the results. So obviously, creating test it is the more important part and a more time ticking and tedious part. Using it for validation becomes very easy once you have the correct test data. Second, inadequate or incorrect test data can cause invalid or miss testing. So pretty clear, If we do not have all the data to verify, we would probably skip some scenarios and that would lead to invalid or miss testing. Our target. We want our test data to be realistic, valid, and versatile. So again, we want to use as much as possible in the real world. The last term where versatile means that we should use test data that gives lots of variation. So for example, if we are testing for login ID username, we should use long username, short user name, email username, alphanumeric user name, et cetera. Just so that we are doing a lot of variation. Fourth, test data can be created or copied from production. So let's talk about this point. We know that we would need lot of test data, but how can we get it? The easiest way would be to copy the data from production into the test systems. So we would copy that data from production database to the testing environment database. Now, it sounds very easy, but remember we have to keep in mind that data privacy aspect. We do not want to copy over the user's credit cards and start showing them in the test environment. Or we do not want to copy over the user's password and you start showing them under test environment. So both these cases are in breach of data privacy. So while some data can be copied from production, we also need to hide the other data, such as passwords and credit cards, or we need to mask them. Next thing we can use border value analysis, equivalence partitioning executor techniques that we saw earlier in data creation also. So just to give you a basic example, equivalence partitioning will tell us that we should create password test data with five to nine characters, tend to 15 characters using combinations like alphabet, numeric, alphanumeric, et cetera. And last point, automated test generation tools are also used nowadays for test data generation. So there are a lot of tools that generate credit card numbers, password combinations, et cetera. And in a lot of places, testers are also required to use SQL queries to pull out existing test data from database. And in fact, SQL is one thing gets asked a lot interesting jobs nowadays, and it's something that is very fairly easy to learn. So I would suggest that you try your hands on SQL also if it interests you. Okay, so we are at the end of this chapter, we learned a lot of new things. We saw. What is test case design? What are the techniques to design effective test cases? What is review and maintenance of test cases invited at is important. And we also covered discussions on test environment setup and test data set up. In the next slide, we are going to dive into some practical work because it's time for the bonus content of the chapter. So we will look at test_data, our test case creation for an e-commerce website. So I'll see you in the next lecture with that topic. Till then, keep learning and Hep-C testing. 25. 6.5 - Bonus Content - Lets Write Test Cases (Part 1): Hello everyone and welcome to this a2 set deep learning course on software testing. So guys, this is the bonus content lecture of this chapter. And we are going to see how to actually create test cases. And we are going to do the demo using an e-commerce website. So we learned about test cases. We learnt about how to write better test cases. What are the different scientific techniques that we can use for writing better test cases? Now is the time queued utilize all this NC, this demo. So let's begin. So guys, I am sure everybody of you knows about this website. It's the biggest e-commerce website in the world. It's a true example of a transactional end-to-end big project. So that's why it's best to look at the things here. Let's begin. Now, as you can see, this is the homepage of Amazon and there are multiple sections on it. So like there is this hamburger menu. There is the logo of the website, the search box, the language change option, the account options, the shopping cart, some quick links and some ad banners, et cetera. So DES is the homepage of the m is n, and as we saw, there are multiple sections on it. So now the question comes up debt, when you are designing the test cases, how should you approach it? So the best approach is to think about all the scenarios present on this page. Now remember, our thinking about all of these scenarios is the easy, is the tough part. Come converting it into test cases. Writing it into test cases is the easy part. First, we have to spend lot of time in trying to analyze the requirements. Try to know what are the scenarios that are impacted, what are the scenarios that we need to test, etcetera. So let's say for an example, if Amazon is coming up with a requirement that they have these drop-down for different categories and they want to add a new category to it. So we know that we have to test this particular drop-down and this drop-down box in parallel with this search box. So I select something here and then I search for it here. So we know that ok, we have to check this dropdown, the different options here, and we have to check this search box so it becomes relatively easier. But if you are testing the same thing for regression, if you're doing the regression scenarios for the entire website, then how can you figure out the scenarios? Because it's a vast website, there are so many flows, so you are also not aware about it, so how to approach it? So the best approach is that if you are in a company where there are already testing it, Amazon, you already have test cases. You can refer those test cases. You can go through the training phase and know about the behaviour of the website or let's see if that option is not there. You are supposed to start work on a new website, you are starting a new project. Then you can contact the site owner, the product donor, or the business analyst. And you can ask them to give a demo of the website to show that feature so that you know what the flow is, right? It's not correct to assume that whatever is coming here is correct and make the test cases on that basis because something might not be right here and we would be making it the actual expected result. So it's not correct to do it that way. We should ideally approach the site owners and asked them to provide a transition. Or we can refer the past requirement documents. We can refer the past test cases if they exist. So let's try to start on the homepage itself and let's see what this homepage contains. So as we saw, there are some sections at the top, but let's start from here. So there is a big ad banner here that is called as the hero banner. There are small, small add tiles for here. Then if we keep going all the way down, there is a recommendation section you will see right here, which requires us to sign in and then it would show us the matching recommended products. There is a footer section, there are links for all the different websites, etcetera. So that is the layout of them isn't homepage, website. And lets us start to write some test cases around it. So let me go to my Excel document and let's start with writing the test scenarios. So the first test scenario, we are writing the test scenario for the homepage ads section. The first test case that we can, the first scenario that we can write is for this hero brand ma banner. So as you can see, there are a scroller, right and left options on this ad banner, so we can write test cases for that. So let's do that. So I can say hero banner, scroll left and right, right. So that could be our first test scenario. Then there is another scenario that if you would come on to this website, you would notice that these hero banners, they do not change automatically. You don't sorry, you don't have to click on it. Or every time they would change, like every now ten seconds or 15 seconds. So that is the auto scroll functionality. So let's test that also. So I'll say hero banner auto scroll. Then what is the next scenario? We can try to click on this ad banner. So let say. And this is something that you would have to do a little bit intelligently because remember these ad banners are not permanent. They would change it every now and then. So light we are getting this ad banner tomorrow and we create test cases for this does not mean that the same ad banner would be present tomorrow. It can't change. So we need to be a little open. We need to keep a little intelligence in it. Like it says here, that this is the ad banner for m isn't pantry. So if I click on it, it should actually take me to m isn't pantry. Alright. That is the part to verify. And as you can see, there would be some intelligence involved in it. So let's write test cases for that hero banner. Click on any banner and verify landing page. Right. The other test case scenario that we can do is we can, we should be able to click anywhere on this banner. Like it should not be necessary that we click on these images only. We can click on this blank part also, and then also it should take us to the correct landing page, right, so that's one scenario. Let's write it down. Hero banner, click any, we're on banner and verify landing page. Alright. What else? So let's do some scenarios for mobile. Remember, in today's world, a lot of requirements happen on the mobile also. So we just need to focus on the desktop version of the website. We should also focus on the mobile version. So if you click on this option here and then you go to a web developer and you go to responsive design mode. So this might vary in your browser if you are using a different browser version. But what you can do is you can Google for how to go to the responsive mode. And the responsive mode allows you to test for different devices or different screen size, etc. So I'll go here, I have, I will select the Android option and I would refresh the page. So you can see that it loaded the mobile site for me and we have to be very careful to check all the different options on mobile because, you know, the mobile size is, screen size is smaller, so things have to contract. There has to be some scroll options to see the, all the different details, et cetera. So the bottom line is that whenever you are testing anything, whenever you are creating test cases, it's not just important to create test cases for desktop. You should also create test cases for mobile site. You should also create test cases for mobile app. You should also check with the business and development team. If there are users who are using the website on tablet devices, then you should test on the tablet devices also, etc. So let's go back to the desktop mode again and lets note down this scenario. So we have to test the hero banner on mobile site, mobile app, tablet, etc. Right? So that is our scenario. And remember guys, we're only writing the scenario here. This is not a test case. The next part is to convert it into test case. And as I said, the tough part is to write the scenarios, converting it into the test cases becomes relatively easier. It still somewhat tough part, but it's relatively easier because the only thing that we have to take care off is to write it correctly. So let's write, try to write the first one here. So if I, if I want to write a test case for the hero banner is scroll left and right this particular scenario. So I would write it something like this. The first step would be go to Amazon website. And I am doing it on the notepad in your company, you would be doing it on our test management tool that we discuss. So the E-step is to go to Amazon website. What is the expected result? The expected result is that verify, There is a hero banner showing on the page. There is a left and right is scroll arrows present on the ad banner. Right? So we have to write it like this. We have to write it in a read that whoever is reading this test case, even if he does not know what the ad banner does or et cetera, he can figure it out. It should be able to understand it, right? Because remember you are writing the test case, you are executing it now. So you would think that okay, everything is clear to me. I can write it casually and just go ahead. But remember tomorrow somebody else might be referring this test cases, so we have to write it in a way that everybody can understand. And then we have to test the functionality is also so just seeing that these arrows are present here is not sufficient. We have to actually click on these arrows and verify the flow. So if I click on the right arrow, then expected result is that verify, it should IQ user to the next ad banner. Click on the left arrow. Expected result is that verify it should take user to the previous ad banner. So we have to test everything. I mean, it's not like just we, we said that okay, the arrows are coming, does is sufficient or we have to test it. The other part is that we should also check the cyclic is scroll so it should not be like I kept on clicking and, and I came to the first ad banner and now it would not go left. Again, the user would have to use it. No, that's not a user-friendly approach. We should be checking showed that this ad banner is actually cyclic after it comes to the first image and then you click on this arrow button, it should go again to the last advantage should be like this. So let's test that also click on the arrows to navigate through each ad banner. And expected result is that users can navigate to each ad banner. Verify the arrow links do not get disabled. On the first or last ad banner. When the user clicks on the last ad banner, they should be brought back to the first ad banner. So we are writing everything in our ligamentum, everybody can understand it. Plus as you saw that we are writing the test cases with reference to the user. So we are testing here on behalf of the user. We have to make sure that the test cases referred the scenarios that the user should be doing. So this is how you would convert a test scenario into test case and you would write it into your test design tool. So your test management tool, and then somebody would execute it from there. As I said, this is the way to write the test cases, but the biggest part is to identify these scenarios and write them correctly. So we have already done the scenarios for the hero banner, the homepage. Now we can try some other page. For example, let's go to the website. What else we can try? Let's try out the Login option. So the Login option is right here. It's called a sign in here. So let's try it out. So what, what all we can try and here, let's, of course that's the first thing that we have two tries, the happy path. So you should be able to enter your email address or phone number here. It should then ask you for the password and you should be able to login. So the first thing to verifies the happy path. So login, which is so I go to the login is flow. And I should be able to verify the valid login first. So this is the happy path. We have to verify the happy path first, the mean flow that the customer would do. Next, what we can verify our let's click on this button and verify that it shows an error message. So the field name was email or mobile phone number. So the error message should also tell me that you should enter your email or mobile phone number. So these two things should match. That is a very good test. So let's say blank data. What else we can enter any non-existing login id. So let's see, I enter anything that I assume is not existing login ID. So it should give me an error message that we cannot find an account with that email address, right? So non-existing login id. Then we can try a valid login but invalid password. So if you have an account on Amazon, you can try to enter your login id, but an incorrect password C data, it gives you the error message. Now, when we were in that test scientific techniques section where we were looking at boundary value analysis and equivalence partitioning and decision table. I mentioned this to you and I said that the decision table. Error messages for incorrect logins should give you the unique error message that the login ID or password is incorrect. So I found at that thing does not happen on Amazon. Amazon tells you that the email address is incorrect or the password is incorrect straight away does not give you a generic error message. But I tried it on several other websites like Flipkart, Walmart, etc. But they show you that dwell error message. So it looks like that something is a gap in Amazon. But let's see anyway, so while entered valid login, invalid password. And you can try it with your own account. Are there are some workflows also data I checked in here. So let's say for example, if I enter like this, somebody has already created this dummy account. So if I proceed with it, it asks me for password, I'll enter the wrong password. It will give me an error message, but it will also give me this capture option. So it might not happen the first time, but if you tried to enter the password several time, the site is very intelligent. It assumes that there might be a hacker attack happening or something. So they ask you to enter this capture option. So we can keep that scenario also capture on too many tries, Right? I think it's five tries, but you can try it out yourself. What else? So we can try out this, keep me signed in button so the behavior should be Dad, when you click on it, you should not be logged out automatically after remaining ideal for some time, the site should still keep you logged in. So it's a pretty common feature on all the websites. You can test it also, so keep me signed in. What else? So we you can try to enter the incorrect password several times. One of the things that I noticed was if you enter the incorrect password several times, then it would show you chat option that looks like you are having a troubling with your password. Do you want to reset it or like dad? So that's one of the cool features. Now, these are the examples of, like I mentioned in the beginning, you would not be able to know everything by your own. So that's why it's very important that you design the test cases based on the requirement or you check back with the product owner or the business analyst because remember what would happen is the other site owners, so they know about all these flows. If you come to the website and you try on your own, you would not be knowing debt flow. So maybe you'd be testing incompletely or you'd be testing encouraged scenario. So it's always better to test on the basis of the requirement design. You should never be testing based on what you are seeing on the actual website. So what else we can check? Yeah. So the next thing guys is remember whenever you are in any of the our transactional flows like transactional does not mean just checkout and placing order. Transactional means any flow that the user is doing with the end result. He's not just shopping around for things he's doing a transaction is trying to login, he's trying to create a count. So at that time, we need to give the users both the options. We need to give him the option for login or we need to give them the option to exit out also. So as you can see, there is no Cancel button here so that user can come out of the flow. But we need to test that secondary part also. How can if somebody does not want to login, how can they come out of the websites? So the way to do it is by clicking on this icon over here. So let's add that to our test case. We can click on the logo to exit out. Because remember that's something that the user would want to do a lot. They come to this screen but they decided that they do not want to login, so how they can come out of that flow. So that's my dad scenarios important. What else? So let's try the create account also. We have done the sign-in. Let's try the create account also. So this is the create account model. So obviously the first thing that we will try and here is the happy part to create a new account. So we will create test cases for Create Account. And the first test case would be to create the account with valid data. That is our happy path. So remember, we always would want to test the happy path first because that's something that the user would do a lot. I mean, we are the tester, so we are coming to this page and trying to break it with different options. But a genuine user would always come with an intention to create an account. So the first thing that we should test is to test the happy path of account creation. Then we can test other things like example, we can click on the Continue button and make sure that the error message are correct. So the field name is name, so the error message should say enter your name, mobile number. So enter your mobile number passwords, so enter your password so we can verify those, that think blank fields. What L. So the password says that the password should be at least six characters. So let's try to just put in three characters here and continue. So as you can see, the error message change to passwords must be at least six characters. So we can verify this thing. Password, less than six character error message. Right? What else? So you can try with creating unique username with spatial characters or dot, or you can try email addresses over here, all the emails and optional fields. So we should verify that the email is not a required field. Let's try debt also e-mail not required field. But let's say somebody wants to fill an email, then we should verify that email is getting saved to his account. I have seen that sometimes sites have a problem with email addresses like example, test at yahoo dot co dot in. So dad, something that we should verify that these dual emails are working normally, the websites might show you an error message that there should not be a dot after this on the first dot. So we should verify this scenario also. So let's note it down. Email with dual domain name, like dot co dot in water. So we can verify this mobile number drop-down. So as you can see, there are a lot of options in here. So if I select a bigger option-like this option right here, the code is 5-0 too, so it should collapse it into the initials, but it should still keep the 5-0 to show the user knows that the option they have selected is retained. So let's verify that also mobile number, short code, right. So that's it that some of the scenarios you can verify it. There can be several other scenarios are less than ten character mobile number invalid mobile number alphabets in mobile number, all those things. So these are the secondary flows. Remember, we have to first make sure that the primary flows are covered like creating Account, creating account with dual domain name, creating account with the dot in the first_name, etc. So those other scenarios we should do first and then we can go to the secondary negative flows. Let's go back to the home page and let's see what other things we can explore. So let's take this search bar. It's sitting right at the top. We have not yet tried it yet. So let's try this search bar. So what are the things that you should do with the search bar? What is the user's expectation from the search bar? So the first expectation is obviously that he should be able to search with it. So for the search bar, which is zoom in on the font for everything, right, so what is the first thing that the user expects from the search bar? He should be able to do a valid search with characters. So for example, if he enters laptops, he should be able to do a valid search with numbers. For example, if somebody enters our tucked T2, then we should be able to show him our 32 GB laptops start to do GB pen drive, exec, exec tra. Let's try a combination of both. So valid search with alpha numeric, like example 32 GB, right? So both the combination of numbers and characters. So we should be, we should try all those things like laptops should work. If I try here 32, then it should understand that. It should understand that 32 and show me 32 GB memory card, TV, pen drives, everything, right? If I want to do a combination like I changed is 32 to 32 GB, then it should show me that things on the right. So all these are valid search criteria. We should be able to search with it. Next thing as you saw, there was an option for a predictive search. So as soon as I type l, it shows me laptops, laptop. So everything that begins with an L. So this is called as predictive search. This is a very important feature. So let's write it down. Predictive search. Then what else? So we have tried out the valid search scenarios. Let's try the invalid such scenario. So I will just ski in anything over here. And it's actually giving me something, but let's try to. So looks like Amazon is giving you search results for everything that you verify. It would be tough to find something or I think it's just showing us all the results because there are 800 research showing here. So maybe it's trying to find something or saying that, OK, it's a spatial character and bounded basis like this thing has a special character in the name. So it's showing that result. So these are the sorts of things, guys, where you need to refer back to the requirement document or raise a query with the business team that OK, what should be the expected result? Like we should not just assume that, okay, if, if, because there was a special character in the name, so it showed it in here in the desert or because it did not find anything, it showed me all the 1000 products that are present on the website. That's not the correct assumption. We should go back to the business team and ask them that what should happen in this case, right? So invalid search. What else we can try. So one of the things that we saw earlier also is if I enter incorrectly spelling pencil, it would put me back on the correct spelling and show me the search results. So that's one of the scenarios we can do. So typo in search, I mean, we are not expecting that the user would do it genuinely, but he might make a mistake in typing something. So we have to make sure that we are correcting debt mistake. And we're showing him the product categories that is matching with debt search. Another thing that I saw when I was doing it was when you are typing of character to search. You can use the keyboards also. So I am not using the mouse, I am using the arrow keys to navigate to each of these categories. So the keyboard navigation should work. I should also be able to hit the Enter key on any requirement and it should search with that particular keyword. So the next option to do is use of keywords, keyboard to search. All right, what else we can do? So lot of times what happens is people are not sure where to find any option. Like you, let's say you placed an order on Amazon and you are not sure where it's the order tracking option. Where can I find my order? So what people do did pasted options here. So example, I can write my account and if I hit Enter, it should take me to my account. But there should be an option to go to your accounted should. And it should suggest that, okay, maybe the user is not trying to find a book for m is an account. Maybe it's trying to look at his own. M is an account, so the site is very intelligent as you can see, it shows me both the options, so user can go into their account also. So searching for account options like my account, right? That is also very good scenario. So as you can see, we have to figure out lot of scenarios. We have to hit end try. There might be some scenarios that are not there in the requirement document if it is not done correctly. So there are a lot of ways that we can explore by triangle. So And still they should work because, you know, you never know what the real user can do. Maybe v as it is, to know that there is assigned account option here, so v will go here, but a dummy user comes to the website for the first time. He does not know where my account is. We're my order tracking is. So he might do this flow. It's not like we are doing a random flow. It might be possible. And that's why it's very important to try out things on your own. Also, the exploratory testing that we mentioned, we should do dat also after our formal testing is completed. So that was the search box. Let's try on the search list. Spit these results that we are seeing. 26. 6.6 - Bonus Content - Lets Write Test Cases (Part 2): So let me write quickly search list page. And what all we can verify in here we can actually be for verifying it. Let's try out something more of. So far we have only used this search bar to go to anything. But remember the user can also use this category options. So let's try out this category option now. So I click on something and then I click on something and I should go to the landing page for that particular thing. And now, what are the scenarios that we can verify on this list page? We can verify these refinements. So if I let see, if I click on this particular brand, then all the results that I see on this page should be from that particular brand only. I can select some more refinement options and then it should work. So remember guys, when we are testing this refinement options, we just don't have good test data, it was clicked or it was selected. We also have to make sure that the results that are coming are in line with those options. So there is a bit of data testing also. Then we can check the removal of the refinement options. So let me remove this refinement options and then we should be able to see results from all the different brands. So these were a couple of scenarios. Let's write them down. So refinements, single, multiple, remove refinements. And remember, we have to cover the data aspect also. What else we can try on this page? We can try this sorting options. So let me sort price too low and then we have to make sure that the price is coming correctly in the correct sorted order. As you can see, looks like there is some defect on them, isn't website. It shows that there is the willow cricket bat, but the images showing wrong, so we found a defect on the website also. Congratulations. It's not a functional defect, it's a data defect, minor defect, but nevertheless. So let me mention sorting also and that we found a defect with it, so we would probably have to report it later. Right? Then what else we can try it out. So if we scroll all the way to the bottom, there would be some pagination options. So we have to try those petty nation options also. Page number previous next, those sort of things. We should also make sure that these delivery options are coming bill. So as you know, lot of people shop on Amazon because of the Prime membership. So they want to make sure that they can see the prime details over here, how soon they will get the items. So we have to verify the Apache nation option, we have to verify the delivery options, etcetera. There is one more thing that I wanted to show you in here. So these items that you show see in here, these are actually they sponsored items. So he sponsored Items Means that these, this is like an advertisement. These guys are paying Amazon money to show these products on their page. So it's not like a user experience behavior. Even if these are not coming, it's okay for the user, they would buy something else. But this is something from which m is and makes a lot of money, it would impact the Amazon business. So from the business point of view, we have to make sure that these sponsored scenarios are coming. So I can click on these is sponsored. And verify that this is sponsored items are working fine. What else? So let's go to the product detail page now let's click on the product detail page. And we can verify couple of details here. We can verify the name of the product uprising, the delivery options. We can verify this section. This is called as the upsell section. So it means that they are trying to sell you something more. You wanted to buy a cricket ball for this much they wanted to sell you and other options. So this is the upsell section, we can verify it. So let's note on the product detail page what we can verify. We can verify the normal details, we can verify the upsells. We can verify that delivery options. We can obviously verify the quantity at two card add to wish list. So add to wish list is a very nice scenarios guys. When you click on it. So you are trying to add the item to your shopping list. So it should first ask you to login. So this is something that we call as the forced login scenario. So it's very good scenario to verify. So let's note it out. So we have verified quantity add to cart, we have to verify add to wish list and forced login scenario with it. There is also an option that you would have seen some time. So let's see if I go to the red pen and let me see if I can find as q2 showed that scenario. So if I go to this particular item, you can see these small boxes here. So they are called as swatches. And what swatches means is that it's a variation of the same product. So we searched for red pen, but there is a variant of it that comes in blue, that comes in black. There's a pack size of 205170, also different style, so these are called as swatches. It's just to show the different variations of the same item. So that's also something we have to verify. Now if we talk about data, this is probably a good scenario, ten days replacement. So we have to make sure that things like the return policy, the number of days you can return, whether you can return it or not, those sort of things should show you. It might appear to us very minor things, just one functionality, but it's very important for the user. They may use those things to make the decision. So it's very important to check them. Same thing for the images. So when you hover over this item are let me just go to a laptop and let me just open this laptop. So for this laptop items and et cetera, we have to make sure that the image that shows up is of the high-quality. So as you know that when we're looking at the requirement, the requirement would probably only say that the images should come, but having the high-quality image, being able to see the product correctly, it's a big ask for the user. The users make their decision based on these things. So even if it is not written clearly in the requirement document, we should Anyway check that the images that are coming are of good quality. It should be of good resolution, etc. So let's note that down. So that's it. I think we have verified a lot of things in product details page. Let's go to the shopping cart page now. What we can verify on the shopping cart page so we can verify the general layout. We can verify adding, removing Item, deleting the item, save for later, we can change the quantity and remember the quantity works in line with the pricing. So when you are changing the quantity, updating it, decreasing gate, et cetera, the price should also change the option in the header showing the quantity of item though should also change. So we have to keep an eye on data also, I am increasing the price and as you can see, this has changed, this has changed. So on the cart page, we have to verify the details of the item that's pretty much necessary everywhere. We have to verify the prize quantity, updation. And it's linked to price. Next weekend verify there is sometimes a rule for minimum quantity options. So for example, this particular product that you have here cannot be brought less than one r, sorry, in line. So let's see if I want to do the quantity to one, it would automatically change it to nine because that's the minimum quantity you can order. So there can be scenarios for minimum and maximum quantity. So we have to verify that also. We can verify these recommendations. We can verify the save for later. We can verify these recommendations that are coming here. They are called as carousels, so we can verify all those things. Right. So these were some of the things that we could verify on the cart page, some of the scenarios. Let's pick some non transactional page, right? So let's pick the account page. So if I go to the account page, what all things we can verify here. So as you can see the layout of the page here are a couple of sections that are coming in here. And obviously these sections would be important for the user. Everybody wants to check what is their status of their order. You want to make changes to your member shape, balance, etcetera. So there are things to verify in here. So let's try it account page. And we can verify the different options. We can verify let say if you see if I mouseover on this item, it changes the color of the box. So that's something we can verify from a UI perspective. So mouseover, color change. And we can verify all these different links. So these are some other links for different kinds of things. So remember these links are pretty static, they would not change. So this is one good place that we can make use of automation. We can use our automation scripts to verify these links every time that they are not broken, that they are taking to the correct page, et cetera, so we can verify the links. The recommendations are coming here, the carousels are coming here, the browsing history back to top. We can verify all those things. So recommendations, carousels, back to top, etc. So let's verify One last thing. What else should we verify? Let's verify this customer service and customer service guys is a very important page. It should always be thought of in any testing because if you think from a user perspective, you would come to the Customer Service page whenever there is some problem with the website, you are not able to place the order, you are not able to know about your order, you are facing any problem. So that's when you would come to the customer service. Let's say there is some defect on customer service. It is not working, so it would cause a lot of problem to the user. It would cause a lot of bad reputation to the company. So that's why customer service pages something that we should always verify. And let's see what all things we can verify here. We can verify the different boxes, the color change on the boxes, and we can verify the messaging also. And in fact, I'm telling you this scenario because when I tried it out, the messaging was different for the pre and post login page. So before login it tells you that hello, what can we help you with? Once you are logged in, it will say hi, your firstName and what you can what can we help with you for the order section, because we are not logged in. It's only showing the empty box over here. But when we are logged in, it will show you the image of the product that is on delivery. So these are the things that changed between pre and pre login and post login. So very important to verify pre login and post login contents. We can verify the different options that we're showing there. We can verify mouseover color change. We can verify the different LINCS data here. We can verify this search box, etc. Right? So that's a lot of things that we can verify here. In fact, we saw a lot of things that we can test out on Amazon, the different areas. So let's wrap it up here. But before I end, I just wanted to recap the quick things that we did. Remember. Number one, whenever you are creating test cases or test scenarios, always make sure that it is based out of requirements. It's not correct to do go to the website to listen what others are saying, etc. Because remember you might be testing incorrectly, you might be testing incompletely. So it's always best to refer to the requirement documents. If there is no requirement documents, you can take help from the product owner or the business analyst asked them to give you a demo of the changes that they are planning. Ask them to give a demo of the website so that you can know the things from the expert, right? They would tell you what the exact requirements are and you can create the test cases based on it. Number three, when you are creating the test cases for new requirements, it, it's relatively easier because you only have to focus on some areas which are changing. But for the purposes of regression testing, you have to verify the entire website. So that's a lot of scenarios. It's very important to make sure, especially for regression testing that we are covering everything. Number four, whenever you are testing something, make sure that you are testing it from the user's point of view, you are doing things as a user would do. And lastly, whenever you are testing things, make sure that you are giving sufficient attention to the positive flows. Remember, we are coming to the website from the objective of testing it. But a real user would come from the to the website with the objective of buying things for logging in or for creating his account. So it's very important at the primary flows would work only once the, once we have verified the primary flows, we can go ahead and verify the secondary flow. So that's very important. So guys, this was all about test case creation demo. We would continue on our learning journey and I will see you in the next chapter. Till then, keep learning and Hep-C testing. 27. 7.1 - When to start testing, When to stop testing: Hello everyone and welcome to the seventh chapter of this a to Zed deep learning course on software testing. This is day seven of our learning and today we are going to cover Test execution and reporting. So this is the chapter where all the action will happen. In the past chapters we saw how to analyze requirements, convert them into test, our test cases, setup test environment and test data. So now is the part where we will execute those test cases and verify the application. So let's get started. Here is what we will cover in this lecture. We will start with two very important questions, when to start testing and when to stop testing. We will see general practices on how to execute test cases. What are the different results of execution? Next, we will take a quick recap of non-functional testing to refresh our memory. And then we will see how to log defects, defect lifecycle and what to do when the defects are fixed or not fixed. Next, what is the cost of defect? Very interesting concept. And finally, we will discuss reporting of executions and defects. We will in fact see a real-world execution is status report as part of the bonus content of this chapter. So as you can see, it's a very detailed list. And like I said earlier, this is going to be an action filled lecture. So I am very excited to get started and see all these interesting things. Let's start on our journey. So the first question that comes up in test execution is when to start testing? And the most simple answer is as early as possible. We saw this as a testing principle also, it's important to test early and eat. And at each stage. That's why at first glance it 1c MAC tough question. Shouldn't we test early starting as soon as things have ready? Well, yes and no. There are few more things we need to take care before test execution can be started. And this is to avoid unnecessary problems. Let's consider an example. Let's say that the code is not deployed to the test environment and you start testing. So of course things will not work and you would log, let say, five defects while the developer is going to be very mad at you and for starting testing before deployment. So there are some preconditions that we need to check before we can start testing. Number one is approved requirements. If the requirements are not approved, your testing will be incorrect or missing things. And that's why it's important that the requirements are complete and signed off by the business team before we can begin testing. In fact, this is a prerequisite for test, is designed itself. If you did not have approved requirement when you were creating test cases, the alarm bells should have been raised at that point only. So no approved requirement. Notice, case creation, noticed execution. Number two is an approved test plan. We shouldn't work without an approved test plan. Why? Because the test applies every strategy. It contains our shared dual resourcing everything. Third, test cases are ready and reviewed, so we obviously need test cases written before execution. And as we discussed in last lecture, they should be reviewed also for correctness and coverage. The maintenance of these test cases, if needed, should also be completed by this time. Next, test infrastructure and test environments should be ready. So test infrastructure means everyone has the required hardware and software to do their job. And test environment means QA environment is stable and ready with the latest code deployed. This also means that we have already done I smoke test on the environment and it has passed. Number five, test data is available, so obviously we cannot test things without proper test data. And last point, availability of code to test. So this is a little different from the test environment discussion in 0.4.4 was about environment setup and stability. And here we mean that the latest code from the developer should be deployed. That is, we are testing on the right code. It's available on the test environment. Okay, so these were some of the points to check before you starting test execution. Remember, we want to test as early as possible, but we also want to test things the right way. So make sure that about points are confirmed before we start testing. So now that we have seen when to start test execution, let's look at the oppose it also, which is when to stop testing. So if you taught that when to start testing was a tough question, this one is even tougher. And that is because testing is a never ending process. But now we have to figure out when to call it is stopped. So to help with this, there are some conditions that we can figure out when we should stop testing. So the first condition that we can follow to stop our testing is when our test execution is completed. And this makes sense. Let's say we had one hundred, ten hundred test cases to execute. We have executed all of them. Lets you stop testing. But think about it for a moment. Does execution of all test cases is a sufficient check? Did we cover everything in that test case? Maybe not. That's why the next condition is important, which is all requirement coverage should be done. So instead of tracking completion just by the number of test cases, we should also keep track of whether all requirements are covered or not. And this could be a part of the test coverage that we talked about in the previous chapter. Card. No critical or Blocker defects are open. So this is a good estimate of testing completion because if there is nothing critical or block or open, we can say that the current event of application is good and it won't go any further changes. And so it is good for release. Next, defect rate below accepted rate. So we can compare number of defects, let say per 1000 test cases or requirement, which is called as defect density. And we can compare that defect density with our baseline. And if it is below baseline, then we can say that the system is stable enough for this release. Otherwise we need more testing. And remember this might not be a very good estimation of testing, but it's more like a confidence building measure that we can stop the testing. And last the famous condition that happens a lot, that deadline is reached. So this is the Management condition. The time that they had given for testing is over. So we have to stop now. Now this is something that would hit each of us at some point or the other in our career. But the good thing about deadlines is that they don't pop out. Certainly, you would have most likely discuss the deadlines when creating the test plan in your schedule section. So you were pretty aware of it from the beginning and you should have plant as per our deadline already. So last two conditions are not so accurate, but they do happen in real organizations, especially when you're dealing with the crucial release. So I would suggest to keep tap on the first three conditions related to number one, test cases, number two, requirements and number three defects to get a clear picture of when to stop testing. Ok, So we have seen the basic questions, went to start testing and when to stop testing. So now we are ready to talk about the execution stage. So let's start that in the next lecture. I'll see you in the next lecture. Till then, keep learning and happy testing. 28. 7.2 - Test execution, Test statuses & Non-Functional Testing: Hello everyone and welcome to this a to Z and deep learning course on software testing. So let's talk about the test execution stage now. We should start test execution ones. All the code is deployed and the environment has passed a smoke test. So that means that the developer has deployed the latest code on the test environment. We have done a round of smoke testing on the environment and we have confounded the built-in looks stable. We are good to begin our testing. Now before we execute one quick note from where we will do our execution. We will do our execution from the test management tool. We talked about test management tools in the last chapter. So whichever test management tool you are using in your organization, you can begin execution from there. Now if we are working on small projects, it might happen that we use Microsoft Excel for that, but it's not recommended if we are working on medium sized projects, we should always insist on a test management tool to create and execute our test cases. Alright, execution means that we are testing both the new changes that are going in and also we are doing the regression testing. So as we talked earlier, regression testing means testing of functionality that is impacted due to the change. So let's say if we are making any change that allows the user to login with their mobile number. We would need to test that particular change, but at the same time, we would also need to regression tests the existing functionalities. That is, we are able to login with email ID, user ID, alphanumeric login id. We are getting all the different errors that are associated with invalid login, etcetera. So apart from the change that is going in, we also need to verify all these existing functionalities. And as you can see that our testing these existing functionalities is I'm taking activity. So the primary activity that consumes the most time in any test execution cycle is the regression test. Next point, we will utilize both mediums of testing. We will use manual testing and automation testing at this point. So the regression tests scenarios that we talked about earlier, they are the best suited candidate for automation. So if you have automation in your project, if you have automated the regression test cases now is the time to use them also. Next, when we run our test cases, one of the following things will happen. It would either pass or fail, it would get incomplete or blocked are these are the statuses in which the test cases eventually end up. And what are these status? When we select what is status, we will discuss all these aspects in the next slide. Fifth, failed test cases should always have a defect ID. So let's say we are executing any test case and it fails. It means that there is a defect present and we should report a defect and link that defect to debt failed test cases. If there, if there are other test cases whose execution is also blocked due to this defect, then what we can do, we can set those test cases to blogged by mentioning the same defect ID. This would help us in reporting both the execution and the defects. Next thing, that defect should be tracked, so B should own our defects are good testers work is to log defects, but at the same time also follow up on those defects and check on it's a status check on any comments that have come on it. And once the defect is fixed, the tester should verify it. On the same line, one, that defect is fixed, the retesting is also required. So whenever we get any defect fixed from the developer, we should not only verify the fixed scenario, but we should also analyze if there is any other functionality that could have been impacted because of this fixed and verify that also. So that would mean that we would also have to do our regression testing when that defect is fixed. Next point, continuous reporting. So as I mentioned earlier also, we are in the execution stage and we are testing things daily. So obviously there is a, there is a attention from the stakeholders that they want to know our progress daily. So that's why it's very important to report our execution. It won't be helpful if we just keep on running our test cases, but there's no visibility to the stake holders. So that's why reporting is a very key component. The summary report that which send out should ideally contain both the execution and the defect details. And like I have mentioned in the past, also, the purpose of this particular course is to provide you with practical examples wherever required. So in the end of this chapter, we have a bonus content where we will look at one of the real-world execution report and how it is created and what all aspects its report. Last point, risk discussion and mitigation should be done. So when we are executing test cases, obviously some hurdles would come. And it's very important to point out those risk to all the stake holders. So some of the common examples of risk could be like we have a blocker defect. Debt is affecting too many scenarios. It has been opened for three days or we have not got any test data, and that is why some of our test cases are blocked, so we have to report all these risks. Remember as I told you earlier, also, whenever we are reporting any risks, it is also better to include the mitigation plan for it. So for example, we have a blocker defect that has been opened for three days and it's impacting about test cases. So the mitigation plan is to close their defect as early as possible. We have some test data that is not available and it is blocking our test case. So the mitigation plan is that we should migrate those test test data from production so that all of our scenarios can be checked. So this was about execution. As you can see, we started by discussing the test case execution are then we moved into the defects. So these are two areas that are very important during execution. These are the two main components of execution, test cases and defect. So we would try to keep a parallel between both these aspects and discuss them accordingly. So let's talk first about test cases in more detail. So as we saw above, when we are executing the test cases, they would land in separately status like pass-fail, incomplete, et cetera. So let's talk a bit about those are status. So these are the different status that can happen when we are running a test case. The end we will select this appropriate is status in the test management tool. And that way it would also get included in our execution reports. So what you see here are the most common test status. You might see some more or different in your organization, but these are the ones that are most common and they are short used anywhere. So the first is status is passed. That means everything is good. We call it test cases passed if it's actual result matches its expected result. And remember, all the steps in the test case have to be passed. Then only we can call the test case as past. The next is status is failed. So did not things did not go well. Our test cases failed if it's actual result does not match its expected result. Plus let's see if you have a test case with tennis steps. Even if one of these steps failed, we would call the entire test case as failed. But there is one word of advice here. So let's think about it from an example. Let's say I had a test case for check-out on our e-commerce website. Right? The flow is that we would login, we would search for any product checkout and place order. Now when I went ahead to run this test case, I found that there is an issue with not being able to search with one particular term like, let's see, I'm not able to search with laptops. So it works for other terms like I am able to search with pen, paper, phone, tablet, etc. But I'm not able to search with only one term data's laptop. So what I would do, I would login defect, I will fail that test case. But what most people do is then they failed the test case and move to another test case which is wrong. Because think about what would happen. Let's say tomorrow that reported defect will be fixed. We would be able to search with laptop added to cart and checkout. Now what would happen is I would find a new issue with Checkout, which I could not report the previous day because I simply abandoned my test case and went to the next test case. So you can see what's happening. We are reporting things in bits and pieces, and that is not the best way. It's very important debt, even if one step failed and we know delta test case will fail, we should still execute the remaining test cases if possible. This would help us in finding defects early. Now, one of the exception would be when we find a blocker defect. In that case, the entire test case would be blocked. And that makes sense. But in all other test scenarios, we should try to execute other steps if possible, so we can report defects early. The 30 status is incomplete. So now this is used when a test case did not complete execution due to several reasons. For example, we raised a query to the business analyst for more clarification on requirements, or we raised a query to the developer, or there was a gap in the understanding of requirements, etc. So incomplete means that we had a question and we need more details on that cushion before we can proceed to the next status is blocked. And this is used in cases where some pre-condition did not fulfill, like the environment was down or the test data was not available. So in those cases, we would mark the test cases blogged. Now it can also happen that we find a blocker defect, which is impacting multiple test cases. So what we will do, we will mark one test case has failed and we will blog the other test cases. Once the defect is fixed, we will re-execute all these test cases. The last dish status is deferred, and this means that the test case cannot be run completely in this release, but it will run later in a different release. So this happens for test cases that are related to functionality that is not fully done. So this functional debt functionality would be developed in full in the later stages. So this is a test case that is not valid today. But once that functionality goes live in the next cycle of execution, this would be a valid test case that sway we are not removing this desk is we are only deferring it for the time being. All right, so we talked about test execution and we talked about different statuses. Let's talk a bit about non-functional testing also, because remember, we are in the test execution phase and it's important to not only focus on the functional aspects, but also the non-functional aspects of testing. So let's talk a bit about non-functional testing. Now, we saw in the beginning chapter what non-functional testing is. It is the testing debt relates more to the non-functional aspects like performance, security, usability, compliance, et cetera. And as I mentioned back then, debt non-functional testing is something that is done after functional testing. So let's think about it for a while. Why do we do Non-Functional testing? Usually after for functional testing, we do it because while our functional testing is going on, we would find bugs. There would be bug fixes, there would be quote changes happening. And so the code that we're testing on would not be the final are tested stable code. So we want to wait till all our testing has ended. The code that we have out there is pretty stable and then we want to jump into non-functional testing. So debts by nonfunctional testing happens at a later stage after functional testing and on a stable code. So when we say stable quote, there is a term for it that is called as the stage of code freeze. So when we enter the stage of code freeze, we're not making any changes to the code unless we find any blocker or critical defects over code is frozen, it would not undergo any more changes. We can now do the non-functional testing. So let's see what non-functional testing is. What the slide says. First, non-functional testing is important to ensure application meets customer expectations. So as we talked in the past, functional testing was about customer requirements, but non-functional testing is about customer expectations. The objective of non-functional testing is to verify non-functional aspects like performance, security, usability, et cetera. Again, we discussed this in the earlier chapters. Third, the common non-functional testing techniques or performance testing, security testing, usability testing, compatibility testing, compliance testing, accessibility testing, etc. We saw all these types, what they are in the past chapters. And we also saw that these are specific techniques that are very commonly done using a tool. Next up, non-functional testing is done after functional testing, like we discussed earlier, but it should be planned from the beginning. So whenever we are in the planning stage, in the requirement stage or in the test design stage, we should not only discuss functional aspects, we always talk about non-functional testing also. And lastly, non-functional testing also includes same processes, functional testing. So like we plan for functional testing, we create test cases, we execute them, we report them, we improve on them, etc. Similarly, we plan for nonfunctional testing. Also, we create non-functional scripts. We execute them, we report their results, and then we improve on them as needed. So that was all about non-functional testing. Now it might happen that when you are working in an organization, you would be working mainly in functional areas. You would be working as a functional manual tester or is a functional automation tester. But nevertheless, you should always check on the non-functional aspects. And you should discuss with your client or manager that it should be a part of the function are testing lifecycle. Because as we have talked in the past, non-functional testing is also as important as functional testing. Alright, so that was all about test case execution, functional and non-functional. We also discussed about the different status that we use when you're running your test case. So we have talked about the first aspect of test execution, which is the test cases. Now is starting next lecture, we would go into the other aspect of test execution, which is defects. So I'll see you in the next lecture. Till then, keep learning and Hep-C testing. 29. 7.3 - What are Defects and how to write a defect: Hello everyone and welcome to this a2 set deep learning course on software testing. So let's talk a bit about defects Now. We have already discussed about test case execution. So the other aspect that comes up in the execution phase is defects. So what are defects? As we saw in the second chapter, defect is nothing but the variation between actual results and expected result. So when we are executing your test case and the test case fails, that means that the actual result does not match the expected result. We logger defect or a bug or a ticket, however, we call it in the organization. In this particular course, we will be using the word defect throughout, but you might be calling it as a bug in your organization. So the defect is nothing but a discrepancy between the requirements and how it actually works on the application. So finding defects and reporting them clearly and in detail is a necessary skill for testis. As I said in the first chapters exercise, our testers should have an eye for catching defects. In fact, it's a joke. Debt testers feel happy only when they have logged at least one defect each day. Before we see how to log a defect, let's figure out where it should be reported. So for reporting defects, most company user defect tracking tool like RG or Bugzilla or mantis. These are the names of some of the most common defect reporting tool. Jira is the most popular defect tracking tool in today's time. And the best part for you is that we have a separate chapter to cover JIRA because it's a very important tool. It's used a lot in organizations these days. And it's an important component to effectively implement HAL debts y, we will take a look at HL and Gita in one of the bonus chapters. Third, whenever we are reporting a defect in JIRA or Bugzilla or in Word or Excel like something small companies do. There are a few details that are essential or defects should have a defect ID, which is its unique identifier, a title which it gives a quick introduction to what the defect is, the built-in formation or the version in which the defect exists. So we can help the developer know which codebase it exists on, the severity of the defect, the status of the defect, whether it's open or in-progress, et cetera. And we will talk more about his status in the next slides. Next, we need to put the steps to reproduce in the defect. And remember the steps should also include any test data that we used. Example, the login ID debt we used, the product that we used, etcetera. In fact, we should provide as minute information, whichever information that is necessary to help the developer or the business guys in replicating the issue again. Next, we should provide the expected results so we know what the requirement is, that is our expected result. Also, we should provide the actual result at how it is actually working on the system. We should provide the assignee name, the person whom that defect is assigned, the reporter who is the person who reported the defect. And we should also provide any attachment. Like the screenshot or the video, which helps to explain that defect quickly. If you're reporting a defect in any email, you can attach a screenshot or the PDF of the email also. So these are some of the most common information that is needed in a defect. Again, there can be some variations in some of the fields in your organization. But what we discussed here are the most common and the most mandatory fields. All right, let's see what are the best practices when reporting a defect. Number one, our defect should provide clear information with precise steps to reproduce. So if you are logging or defect for orders not getting placed, don't just say that orders are not getting placed. Instead, patina sequentially step is starting from access the site login with any user search for laptops added to cart check-out. And then when you place the order, notice that an error comes up. So that's how we should report a defect by providing sequentially steps. Second, put in as much as information as helpful, but no assumptions. So do not make any assumptions like the order might not be getting placed because the backend database would be down. No. We don't want to put all this information because it can make us look wrong and it can also divert the attention of the developer into the wrong direction. So we do not need to make any assumptions. We only need to put the actual factual information. Third, assign, CERT and priority properly. So whichever medium you are using in your organization, you have to assign it correctly. Most testers would like to highlight their defects by logging everything as critical or major. That is incorrect. We have to give an accurate severity based on our knowledge of the application. If there is any confusion, we can check with others on what CVR TV should use rather than bracketing everything as major or critical. Next point, provide environment test data is screenshot videos, etc. So we have to put in everything every minute detail that will help to reproduce the defect, provide the environment ends up build where it's happening so the developer knows which quote to look at it if possible. You can also mention how it works on the higher environment. Let's say we are logging a defect for search with laptop not happen. So we should mention that it is working fine on production because then it helps to determine the priority of the defect. We should also give any test data we use. For example, the defect that we discussed earlier. We are we are not able to place an order. We should give all the minute details, all the minute test data like login id, which item we added to cart, which address we used on Checkout credit card, we used everything because we never know where the fault would be. Also adding a screenshot, especially if you are logging a look and feel UI defect. You can also attach a video if they steps in the defect are too tricky, too tricky to reproduce. Or if the defect is going back and forth between the UN developers can not reproducible. So you can put up video also in the defect. Last do not put multiple issues in one defect, so don't say login with the user issues. One is that you cannot search with laptop issue too, is that if you search with Ben, you cannot proceed any place order no data is incorrect. We should log these as two separate defects. Instead of putting everything into one defect. And you should also check that the defect is not already logged, so we should not log duplicate defects. We can check in our defect management tool, Gita or Bugzilla, whichever dead this defect is not already logged or we can check with our team also locally that it's not a duplicate issue. Alright, so this was all about defects and some of the best practices when we are reporting defects. And also some of the common fields that we have to use. Let's look at a sample defect to understand these things more clearly. So this is a sample defect and it's taken from the marker dot IU website. As you can see, the defect has a short but accurate title. It's related to pricing and it says that the price is not updated to $1.29. So we have very clearly and in very short terms, given the introduction to what the defect is, it has high-priority, meaning that it's impacting several flows. In some companies, they might also use high, medium, low, whereas in others they may use blocker, critical major, minor or trivial. I usually prefer the later denominations of using blocker critical major, minor trivial because it helps give you more options. But whichever levels are being used in your organization, you can accordingly classify the defect in one of those categories. Remember, don't over-hyped it by putting everything as high or major, Make sure that you are selecting the CB2, your priority accordingly. Next, as you can see, the status is to do, meaning that it is something that developers will work on. The environment is also given clearly. So this is very helpful, especially when you are logging a UI look and feel defect. And you give the environment so that helps them to compare with the other environment how it is working there. Also, as you can see that because it was a UID fit, they gave the screen size, the resolution, the browser, etc. So any detail that would help in reproducing that defect accurately, we should provide in the defect summary. Next, the defect was reported by Christopher and it was assigned to Gary. So the reporter would obviously be whoever is reporting that defect, you cannot change it. But the assignee depends upon whom your organization wants 35 to assigned to. Whether it goes to a developer, development manager or it goes to the business manager, what are, whatever is the norm there. So you should always assign by default to that person. Next, look at the summary, how clearly it is given with clearest steps to reproduce. It also has clearly pointed out what is the expected result and what is the actual results so that people know what is happening and how it is supposed to work. We cannot see the attachment here, but there is also a screenshot. Data is attached to the Gita. And in data screenshot we should always clearly point out what the issue is. Once again, if we are logging a UI issue, look and feel issue, it's very helpful to give a JIRA pointing out what u i is broken so that the, so that everybody who sees the Gita can immediately know what we are pointing to. So this is how we should logger defect with clear and sufficient information. The patterns that are followed in this defect are the best practice. There might be some variations in your organization, but remember, what we have to always make sure is we are providing all the required information. We are explaining the issue clearly. We are giving any test data that is required for explaining the defect. We are giving any screenshotted helps to pinpoint a defect and we are selecting the fields like priority CERT, that type of defect, the environment, all of these things clearly. All right, so now we have come a long way in our execution journey. We have learned both the aspects. We have learned how to execute test cases and also how to log defects. These are two or four most important work in execution stage, and we have covered both of them. In the next lecture, we are going to dive more into defects and we will see what happens when a defect is locked, how it flows through in a journey that is called as the defect lifecycle. So I'll see you in the next lecture about it. Till then, keep learning and Hep-C testing. 30. 7.4 - Defect (Bug) life cycle: Hello everyone and welcome to this a to Zed deep learning course on software testing. Let's learn this nice chart here, which is nothing but the deaf are defect lifecycle. So this is the journey that a defect goes through from the point at it is logged by the tester until the point at it is verified and closed. So we start from the top with the status statistic called as new. So when the tester has logged and new defect, the status of that defect is new. And at this point, this defect is either assigned to a development manager or a business analyst, whatever is the rule in your organization. And dad development manager or business analyst would go through that defect. He would read the summary of that defect. He would try it out using the test data that we gave, and he would try to make sure that it's a valid defect or not. If it's not a valid defect means that defect could either be rejected, means that the business analyst and development manager do not think that it's a defect. They are agreeing to not fix it. Or it could be a duplicate issue means that there is already an issue, Lord, for that particular scenario and it is being done. So that's why this issue is this defect that will log is a duplicate and it does not need to be worked on. The next is it can be deferred, so it's a valid issue, but it's something that they do not need to work on right now. So they would differ it and put it into a backlog where they would pull it out later and fix it at some later is states. So it does not mean that the defect is not valid. The defect is valid, but at this time it's not a priority for them. The last invalid status is called VAD, short for working as designed. So what it means is that that issued at the defect that we reported, the expected, the actual result that we put in here is, is the way that it is supposed to work. It's not a defect, it's the intended functionality. So it is actually working the way it should be. And that is why it is working as designed and it's an invalid defect. So these are the four cases in which the defects can be considered as invalid. Let's say if the defect was not invalid and it's some valid defect, then at this point the development manager or the business analyst would assign it to a developer and it would move to the open state. So when the defect moves to the open state, two things have happened. First, the defect has been accepted as valid. Its priority has been confirmed or updated by the initial reviewer. Whether he was the development manager or he was the business analyst, whatever was the organization rule. And second thing, they have agreed debt this defect needs to be worked on, so they have assigned it to a particular developer who will work on it. Now when the developer is starts working on debt defect, he will change the status of the defect from open to in-progress. So at this point that defect is being actively worked on. The developer is trying to go into the code, debug his code, and try to find out why these defect is happening. He's looking into each of the modules, are trying to find out the root cause. And when this state happens, remember, the developer would have some questions. He might need more test data to verify it. He might not be clear on the functionality that expected result that we want. So this is the stage where the developer might communicate back to the test of for any information he needs. So that is why, when I was discussing in the past slide also, I mentioned that we testers should not just log that defect and forget about it. We should own the defect. So even though the defect is not in our queue. It's assigned to a developer. We should still check the defect. We should still keep looking for any comments that may come on the defect in the test manager, defect management tool, or if the developer drops as an email or chat with us or meets us in person, we should keep a track of this defect that we had logged. Or it once the developer would find the root cause and he would fix it, he would move the defect into the status status called ready for test. So ready for test means that the defect is again back in the testis bucket and it is ready for re verification. So what would happen is that our tester will then re-verify the defect and if it is working fine, he will move it into the closed status. If it was not working fine, the tester would reopen the defect and he would assign it back to the developer who was working on it. So the status of the defect would change back to reopened. And once the developer is starts working on it, it would again change back into in progress. So this cycle that you see here around ready for test will keep on going until the defect has been actually fixed and move to the close to status. So this is the lifecycle of a defect. There might be some status that would be different in your organization. But this is the most common journey and I'm sure that it would have given you an idea about how the defect flows. Once again, as I said, that in the lifecycle of a defect, there are multiple parties that are involved in the defect, like the tester obviously is involved, but along with him, that developer, the business analyst, they, they would add some point B also working on the defect. So that is why when ever we log a defect, there might be some communication between all these teams. And that's why we should always keep an eye on the defect irrespective of whichever is status it is in right now. Alright, mo