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

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

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

teacher avatar Aakriti E-Learning, Passion to learn and teach

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

43 Lessons (7h 40m)
    • 1. 1 - Introduction to the Course

    • 2. 2.1 - What is testing and its objectives

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

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

    • 5. 2.4 - STLC quick first introduction

    • 6. 2.5 - Testing models

    • 7. 3.1 - Different types of testing

    • 8. 3.2 - Static & Dynamic testing

    • 9. 3.3 - Functional Testing

    • 10. 3.4 - Non Functional Testing

    • 11. 3.5 - User Acceptance Testing

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

    • 13. 4.1 - Introduction to STLC

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

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

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

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

    • 18. 5.2 - RTM & Test Coverage

    • 19. 5.3 - Test Planning

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

    • 21. 6.1 - Introduction to Test case design

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

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

    • 24. 6.4 - Test Environment & Data Setup

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

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

    • 27. 7.1 - When to start testing, When to stop testing

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

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

    • 30. 7.4 - Defect (Bug) life cycle

    • 31. 7.5 - Cost of defect

    • 32. 7.6 - Test Execution reporting

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

    • 34. 8.1 - Sufficient Testing & Test Closure

    • 35. 8.2 - Product release stages

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

    • 37. 9.1 - Introduction to Agile

    • 38. 9.2 - JIRA tool and its importance

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

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

    • 41. 10.2 - Automation tools & Process

    • 42. 10.3 - Bonus content - Automation framework explanation

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

  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





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!!

Meet Your Teacher

Teacher Profile Image

Aakriti E-Learning

Passion to learn and teach


Hi, I've 10+ years of experience in Software industry, primarily in Project Management and QA. I've also worked as part-time trainer and corporate instructor. 

I believe its very important for all of us to keep learning new topics, keep upskilling ourselves, and improve on things. This spirit and desire to learn is important and you will see it reflected in my courses where I touch on real life examples (as practiced in organizations) and the learning from them that will actually help in our day to day work.

I try to explain each topic in the simplest possible manner, so it caters to beginner audiences, and from there we move on to cover advanced concepts.

Last thing, all my courses come with life time query support, so if you ever have any questions, conc... See full profile

Class Ratings

Expectations Met?
  • Exceeded!
  • Yes
  • Somewhat
  • Not really
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


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 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 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 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, there can be so many combinations in it. We can test it by numbers, alphabet, characters,, 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, 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 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 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 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 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 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 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 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 or m is 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