then test planning has um another step to it that is called test control so the first step um of the fundamental test process was test planning and test control so we discussed some of the steps of test planning now let's see what test control means so after test planning we need to measure and control the progress so test control is nothing but uh once your your planning has been done you there has to be some criteria to measure and control the progress so test control is nothing but you are you you are basically measuring how the test progress is going on and you are controlling the progress test control is an ongoing activity of comparing actual progress against the plan the test control is an ongoing activity is it's it's not something which which need which will be done once so it's an ongoing activity and every day um test control uh is is is done and um suppose you are working in a team and every day test every day defect report is being prepared uh to see how many defects have been raised how many are still um how many are in progress how many are fixed how many are still need to be verified or how many are still need to be fixed by the developers so this this is all these activities are the test control activities that you are monitoring your defects on daily basis or monitoring the execution of monitoring the test execution on daily basis suppose there are 100 test cases to be executed you monitor your test cases that today we how many test cases were executed how many are still pending how many are still need to be done in next five days so all these activities that you do um on daily basis is is all test control activity because you compare actual progress against the plan then test control reports the status of test progress including any deviations from the actual plan so test control also um gives you a proper report if there are any deviations from the actual plan so suppose you are doing the testing and you were supposed to finish all your 100 test cases by end of end of this week and you are just done with 80 test cases um by mid of um mid of friday and you don't expect to complete all of them then test control gives the the status of the progress that by friday we won't be able to tell so it also gives you um any uh gives you a fair bit of idea about any deviations from the actual plan the test control monitors the testing throughout the project so test control is an ongoing activity and it monitors testing throughout the project it's not a activity that will be done in in particular test level it it's done in all test level and it's an ongoing activity in complete testing life cycle the major tasks of test control are to measure analyze results of reviews and testing so the major tasks like you track test file uh test pass and fail percentage you track test remaining okay so you measure and analyze results of reviews and testing so in this step you basically see how many test cases are allocated in test cycle how many of them passed how many of them failed what's the percentage how many test cases are still remaining to be executed so this this is the major um you can you can say first task of the test control activity then the second thing is you monitor and document test progress coverage and exit criteria so you monitor how many test cases um got executed what is the testing outcome so you also monitor um like how many what what is the outcome of the testing how many passed and failed and then you'd also do the risk assessment of test outcome then the other task is provide information on testing you in test control you provide regular test progress report to the stakeholder so if you are working as a test lead you monitor the test progress percentage of test executed how many of them passed how many of them failed um where are we standing today how many test cases are still remaining to be executed you provide all this report on daily basis to your manager or whosoever the stakeholders are so this is another major task of test control activity then you also initiate corrective action so test control not only it just doesn't mean uh not only means that you will be just providing the progress report and what the status looks like on daily basis the test control task the major task in test control is also to initiate corrective action so if something is not going right or your the the test execution is not going as per plan you need to you need to initiate corrective actions so that you can um you can complete uh whatever tasks were assigned or whatever task you want to achieve in that cycle within the specified time frame so corrective actions can be to spend half an hour more every day so that you um you can execute five more test cases every day and you can achieve uh you can um achieve the backlog or you can clear the backlog of test cases so that you can finish um all 500 test cases by end of this week okay so these are some some of the corrective actions that you can take you can either execute spend more time per day or hire more resources get more resources to execute the test cases so that you don't miss the deadline so these are some of the corrective actions that needs to be taken care so like um other thing is for the corrective actions is like putting more efforts in deep debugging and then prioritizing defects as well so in the corrective actions uh so suppose there are a lot of defects and defect backlog is being being you know um more and more so you need to prioritize defects and make sure that all the highs and criticals are getting fixed and verified continuously and every day so all all these kind of activities when you are kind of missing the deadline because of defect or because of um test cases not being executed fully needs to be corrected and the major to initiate a corrective action is another major task of test control then make release decisions so another task of test control is to make release decisions so based on information gathered during testing decisions are made whether you want to release the software whether you want to continue testing stop testing whether you want to release the software or not so test control also helps to make the release decisions because since you are since you're monitoring the progress of test and defect how how the product looked likes um on daily basis you can make release decisions based on the in information uh the test execution information if you have 500 test cases to be executed and you are done with all those 500 test cases all major defects so suppose 500 test cases um when 500 test cases it got executed there were 80 defects found um among 80 defects um 40 were high and critical all those 40 were fixed in medium and lows only 20 defects are remaining so you can make the release decisions based on those criteria so if just 20 low low priority defects are remaining which don't hamper the release of software you can decide based on those those test control figures that you have got so that's the another major task of test control then the second step is test analysis and design so during test analysis and design we build test designs and test procedures the major task of test analysis and design are reviewing the test basis so test basis is nothing but any any document or any system which you use um to figure out any of your your test scenario or test cases so it can be test basis can be an existing software existing system or any existing documentation or software requirement specification functional specification document something like that so what you do in test analysis and design you review the test basis so suppose you have a software requirement specification document you review srs document and design document then you'd start designing black box test cases black box test cases using the test basis so using this document using existing system if the system is already there um you start designing black box tests then this identifies gaps and ambiguities in specification and prevents defects so um if you start reviewing test basis um from initial phase it itself it helps to identify if there are any gaps in the requirements and what you want to achieve during testing and helps us to prevent defect because you have already started reviewing the test basis um all the test documentation started documenting uh blackbox test so it figure figures out any loopholes in the requirements or if the requirement is not clear or is not testable so you clarify that initially and it helps to prevent defect so that's the first first step in test analysis then you identify the test conditions so the second step is based on the analysis of test items and specifications you prepare test conditions so test condition is nothing but anything that can be tested any any um any part of a system that is testable or can be tested is is a sort of test condition then the third step is designing the tests so you apply your test design techniques to design your tests so like equivalence partitioning boundary value analysis um so all different sort of test design techniques are applied to design the tests then you evaluate testability of the requirements and system whether the requirements that are being gathered or the system is actually testable or not okay so if a tester starts doing all this um analysis thing in the beginning itself you can figure out any loopholes or any um kind of shortcomings in the requirements whether the requirement is clear or not so you figure out the testability of the requirement so you evaluate testability of the requirements and the system so make sure that all requirements are testable so let's let's take an example to understand what testable means so suppose um that there is a system that you are developing and there is a performance requirement which says the system should perform the system should respond quickly that's that's the only one line of requirement so if if this requirement is given to any tester he'll i mean you will you won't be able to figure out what exactly that line means system should be fast there has to be some baseline against which uh you will be figuring out whether um how how you will be figuring out the performance so the clear requirement would be that given there are 200 users logged in in an e-commerce portal simultaneously this response time for the user should be no more than five seconds that's that's more testable requirement it gives a clear idea how many users will be logged on an e-commerce website and what should be the response time what should be the performance what how fast should be the response rather than the initial requirement which just says the system uh the e-commerce website or the system should respond fast so that's what the testability is so you need to make sure that all requirements are testable if there is any ambiguity in requirement you need to make sure you need to clarify that you can write test cases for that requirement and you can test that requirement using the real test data then you design the test environment designing test environment is very important because it's where you will be you know executing your test cases so in test environment you need to figure out hardware and software required to test and any supporting tools like test management effect management tools required while you are doing the test execution then third step is to test implementation and execution now in test implementation and execution you take test conditions and make them into test cases then you build test environment where test execution needs to be done so this is these are the two major steps in test implementation and execution so in test implementation you take test conditions whatever test conditions you have figured out from the requirements and you convert them into actual test cases and then you build the test environment where you will be executing your test cases so test implementation and execution test implementation and execution have the following major tasks what are the major tasks in test implementation develop test cases and prioritize them so you already have test conditions with you you need to convert those into test cases and you need to prioritize those test cases based on the risks or whatever factors have been considered in the test planning phase then you apply test design techniques to develop the test cases so there are a lot of black box test design techniques equivalence partitioning boundary value analysis straight transition diagram so you need to apply those techniques um for developing and designing your test cases you need to prioritize test cases based on any risk assessment so suppose um a particular module of software is is of high risk so you need to have more number of test cases covering that module and those test cases need to be pri need to be high of high priority rather than any any module which will be you know kind of used by very less number of users and is of less priority then you create test suites so test suites is nothing but a logical collection of tests so like you you would be doing functional testing of some modules so just create a functional test suite of functional test suite which has the test cases of certain specific models then you will be doing regression testing so um you figure out what test cases are ideal candidate for regression testing so you create another test suite and add test regression test cases into the suite so you create test suites in test implementation as well and then you create um you prepare the test environment on which you will be executing your test cases so the actual setup um the software hardware set up where we'll be performing the test execution so the other step is the test execution so once you have done your test implementation then you will start test execution so in test execution you will be executing test cases so you have prepared all your develop all your test cases based on test design techniques you have i have the test environment everything is ready test suites are ready then you will start the test execution you will take your test case see um execute this the actual step and then you will match with it with the expected result okay so if actual meets the expected test passes otherwise test fails so in test execution you record the text execution outcome with details like environment and software version so as soon as you execute a test case you mention on which environment on which software version which browser that's applicable you record all those details for the test execution then you also compare actual with expected results okay so suppose that your your test case says um open e-commerce login uh portal so login page should open is is an expected result so if login page opens successfully you it meets the expected result you mark it as tick yes it passed okay in case it doesn't open you report an incident and then you report a defect if that is that incident is actually analyzed as a defect and then that defect will be fixed and you will verify that again uh once that is fixed so during test execution you go step by step um from the actual versus expected result and if any of the actual result doesn't match the expected you mark it as incident and a defect and then that gets fixed then you perform re-test after defect is fixed to ensure that defect is corrected after fixed okay so during test execution you execute your test cases if your test cases um actual result doesn't match expected result your logger defect that defect is fixed by developers once that is fixed you get another build install a new build on your test environment the test environment that you have prepared in test implementation step you re-test you re-execute the same test case same steps again and verify that now whatever expected results um whatever um actual result uh is is coming is matching with the expected result and reach re-test is re-test passed and a defect is corrected so these are some of the tests