so let's get started with the test estimation so testing is often a sub project within the large project testing is is kind of complete project in itself so you have a large project strategy with which which has all the the strategy of the complete project development testing and support and everything so testing is a sub project within that large project you should start with work breakdown structure that identifies stages activities and tasks so in order to do test estimation because testing is a sub project and test in test estimation you need to estimate how long it will take or what are the efforts required to achieve the testing cycle to achieve all the test tasks so you should start with work breakdown structure that identifies stages activities and tasks you should break down the stages that are involved in the testing what are the activities within those stages and what are the tasks in those stages so first break down the testing project into phases using fundamental test process so first thing is to break down your testing project into different phases as we have already discussed the fundamental test process initially so you can first break down what are the phases in the testing cycle for example planning and control analysis and design implementation and execution and evaluating exit criteria and reporting and test closure activity so usually all the testing activities all the testing cycle has these phases so first thing is to identify what phases are there in your testing cycle then identify what will be the activities within each phase so for example what will be the activities in the planning and control phase what will be the activities in analysis and design phase and then identify tasks and sub tasks for those activities in these phases so once you are done with identifying activities and tasks and subtasks then you can estimate how long these tasks and subtasks will take to finish so this is a flow for doing test estimation this is the right way to do the test estimation in the test cycle so let's understand some of the estimation techniques for in ist qb foundation level syllabus there are two common techniques that you need to be aware of uh the one is the consultative approach and the other is matrix based so consultative approach is the estimation technique in which you take input from people who will do the tasks and the domain or technology expert so you will take input from these people and estimate what time will be required to complete the tasks other is the matrix based in which you analyze metrics from the past project and estimate your current project task based on the past matrix so in the consultative approach individual contributors and experts prepare the work breakdown structure for the project so individual contributors for example technology experts business experts and testers they prepare a work breakdown structure for the project so the work breakdown structure is being prepared then after that team works together to understand effort duration dependencies and resource requirements so once the work breakdown structure is prepared all the tasks have been tasked and sub tasks have been prepared then the team works together to understand effort duration dependencies and resource requirement then this is a bottom-up approach because you start with the lowest level of work breakdown structures for example you have work breakdown structure task and subtask so you start estimating those the the effort required for that task and sub task and then you add up to the higher level so it's a bottom-up approach so whatever effort is required to complete the tasks in the work breakdown structure that is added up at the um till the top level to get a fair bit of idea of complete testing effort that will be required so this is mostly followed previous matrix because previous matrix about the project are not available so if the previous matrix about the project are not available then you follow consultative approach the disadvantages of this approach is that you have to rely on estimation done by the task owner or the technology expert or business expert so you have to rely whatever they say that this will this task will take this much amount of time to have to rely on their estimation that's the disadvantage of consultative approach then what is the matrix based approach so in this approach metric from similar previous projects are used for estimation so the matrix from previous projects are already collected if phase one of project has ended you have the matrix from phrase one you use you use those matrix to estimate phase two of the project so the simplest approach for this this approach is to take developer and tester ratio okay so for example in your previous phase you had a similar similar level of functionality being added in the previous phase as well you had a ratio of 3 is to 2 so you can have same ratio in this phase as well but this is the simplest approach and doesn't give you a proper estimation so more reliable approach for matrix based approach is to classify the project in terms of size complexity and then compare how long similar project took in the past so that is more this is more reliable what size of project was previous one what time it took how complex the functionalities were in the previous project and then you can compare same thing with the current project and estimate that then average time required to execute one test case in past and estimating the total effort so this is another approach in matrix based approach for example average time to execute one test case in previous test cycle was one hour then you estimate the same using that estimate for one test case you can estimate the total effort in this phase as well so that's another matrix based approach so other sophisticated approaches can also be applied in matrix based approach so for example you can build a mathematical model to compare key parameters from past project and then estimate the effort for current tasks for example how many test case were documented in previous similar projects what time it took to execute 100 test cases in previous project so similarly you you build the model based on the complexity of the test cases how much time it took how many defects were raised per 100 test cases how much time was required to fix those defects and retest them so all this information can be entered into mathematical models and which will in turn generate estimate the effort required for the current task but this requires to build a mathematical model where you can feed the previous matrix um data and get the current estimate so what are the factors that affect the test effort first factor is the product so for example if you do not have sufficient product documentation you will require more time for understanding the product and doing the testing so that's one factor that affects the test effort you'll require more effort if you have less documentation and bad documentation and if the project is more complex complexity of the project if com project is more complex test effort will be more if the project size is more big or it's huge then the test effort for that project will be more if the project is just a simple web application or a website then the test effort for that will be very less so depending on the product that is available the complexity size and the documentation that affects the test effort then the process so what is the availability of test tools that will be used in the testing that's first factor that can affect test effort if the tools are available once you start the testing it will take less effort if tools are not available everything has to be done manually then the test effort will be more then availability of test and development environment if there are development and test environment already ready and up-to-date will require less test effort rather than you have to prepare development environment test environment before starting the testing which will require more time to set up test and dev environment before starting testing then what is the maturity in the organization if the process maturity in organization is is high then the test effort required will be less because the processes are already mature and you have to follow the specific processes to get the testing done and what are the then the people factors for example what are the team skills available if there is no automation skill available in the team and you want to do automation it will require more test effort it will require more effort because team has to do training and learn about automation tool before they can go ahead and start working if your team already has good automation skills they can just go ahead and start with automation and it will require less test effort because you save time of training and ramping up with the automation skills and other factors might be the relationship within the team then what are the time factors so time factors also affect the test effort then the test results so defects found during test execution if there are many many defects found during test execution it will extend the test effort it will extend the test cycle defects failing re-testing the defect many defects found developers are fixing them and they are failing re-test in that case it will again affect the test effort more effort will be required to re-test those um defects then any rework required due to changing requirements in case the rework is required due to any changes in the requirement for example the requirements were not clear or are incorrect then if there is any rework involved in the development team then that needs to be tested and which in case will affect the test effort and more testing will be required to test those changed requirements