Test plan, test cases, test cycles

- [Instructor] Management of Quality Testing is about taking specific processes, organizing them and then reporting against those actions. There are typically three kinds of actions in a quality test. First is your Test Plan review, the document that is your blueprint for executing the test. Next is the execution of your Test Cases, the specific tasks that help exercise the product. Last, you have the Completion of Cycles, a combination of the plan and cases set against a routine executed over a specific timeframe. All test management begins with the plan. This document is something you will reference again and again throughout the test. It's your guidebook to ensure that you are delivering on what was planned prior to entry test. You'll return to it to ensure you're meeting your goals and objectives, but you will also refer to it scheduled for a test list of what needs to be accomplished. When you execute the test, the plan needs to be close. You will refer to the document time and again to see what's been done and what needs to be completed. It contains all the critical data you need to execute your test. More importantly, if you had a proper buy in from the team, it's a good place to refer partners if anyone questions your processes or results. A subset of the test plan are Test Cases. These are defined routines that you will execute repeatedly to ensure the product is working. As new versions of the application enter test, you'll run the cases to ensure that specific issues are addressed and so that you verify nothing new is broken. Executing test cases, is effectively a tool for bug hunting. Test cases are often regimented, rigid and very specific, there isn't a lot of wiggle room and how they are executed. And if you have to make any changes, it's clearly documented in the plan. Changes are usually dictated by some significant issue which is impacting completion. Test cases are treated like chapters in a book. As each is finished, it's closer to the end of the story. Some labs try to automate their test cases to expedite the process for completion. However, automation is dependent on your software, your project goals and your ability to execute them effectively. You may have some test cases that can be fully automated, some that are partially automated, and others that require manual completion. Managing them is based on your project schedule and the difficulty of each case. Our explore California application has a great feature where users can track their flight information. As part of testing use cases, we need to randomly search each airline servicing the varying airports in California to ensure the various user inputs respond properly and the APIs connecting to the travel databases are delivering the right response. Our Explore California test team is taking a manual approach by going through each airline, one after another, verifying it responds properly, and noting if they encounter any failures. This is a slow process, but it simulates exactly what a customer will experience, so it's imperative it works right. Test cycles are a collection of different activities, test cases and sometimes specific tasks dependent on the project management methodology and your staffing. You can break a test cycle down in a variety of ways. Sometimes it's done by a specific feature, a specific functionality or even a specific team member. It can be a collection of test cases or even a single case. You'll define what constitutes a cycle, and you typically do this in your test plan. The common requirement for your test cycle is both an entrance and exit criteria. Entrance reference is a specific fix or quality marker that defines whether it's ready to be tested in the cycle. Exit happens when the case or cases are completed and you're satisfied the exit criteria is met. If the software is working properly, and you can move through your cases with limited issues, it passes, if it fails, then the cycle is incomplete. As I noted before, our software has been delivered for Explorer California and our team is prepared to run its first test cycle completing the flight search test case. They refer to the test plan and verify all the requirements of the case. This cycle is focused on assessing the searching against the various airline APIs and verifying it's working well. Once the cycle is completed, they'll share it with the team. In an agile scenario test cycles might be aligned with a single sprint. In a waterfall model, the entire quality process may be defined as a single cycle. It's really something that the quality team should work with the development team to define. Cycles act as milestones and when they finish, you can judge whether you can close it. If it's a complicated aspect of the software that mingles with the significant parts of the application, it may need to be revisited in the form of regression testing. If it's a module that doesn't change, you may be able to close it. Defining how cycles run and what's included in a cycle is performed when you author your test plan. However, bugs can change everything. Your entire business team is handing you the software with the intention of meeting the requirements in the PRD. However things can and do change. You may need to evaluate your test plans design and adjust it if you find the software stuck in a particular cycle.