ISTQB – CTFL Certified Tester Foundation Level – Test Management

1. Risk And Testing [CC]

Risk and Testing we have mentioned before how risk is an important factor in the testing activity. We base our testing efforts upon the amount of risk in delivering the product to early. If the risk is high, then we need to spend more efforts in testing the software. If the risk is low, then enough we can deliver the software. But what is risk? After all, risk can be defined as the chance of an event hazard, threat or situation occurring and resulting in future negative consequences or a potential problem. My friends who are PMP certified might not like these definitions because in PMP a risk may result in future negative or positive consequences. But people in Isttb consider risks as only may result in future negative consequences. Risks are used to decide where to start testing, where to test more, making some testing decisions, and when to stop testing. I will try here to give you a risk management course in five minutes. You might not need to fully understand it for the exam, but the whole idea will make other concepts more clear. Risk management involves the following activities risk Identification trying to figure out what risks we might face risk analysis, which involves assessing the identified risks and determining which risks are more important to deal with.

Risk Response implement actions to deal with those risks. First, we will talk about risk identification. We can classify the risks into two categories project risks and product risks. What is the difference between project and product? Easy. A product is the software itself. A project is the activities needed to create the product. So product risk is any risk related to the software itself, while project risk is any risk related to how we develop the software. Now, one of the famous questions I have seen is to distinguish between the two types of risks. I even have gotten this question in my advanced level test manager exam. I will tell you here a small trick to help you answer this question. Imagine you are developing a software in your company, say in Egypt and your customer will be using the software, say in Italy. Look at each event in the question.

If the event could happen at your company in Egypt, then it’s a broader risk. If the event could happen at the client’s company in Italy, then it’s a product risk. Keep this scenario in mind while looking at examples of both project risks and product risks. Let’s look at some examples now for project risks. Project risks include technical issues, problems in defining the right requirement, the extent to which requirement cannot be met, giving existing constraints, test environment not ready on time, old test tools, low quality of the design, code configuration data, test data and tests and so on. Late data conversion, migration, planning and development, and testing data. Again, all those can only happen while we are developing the software.

So they are project twists, organizational factors, skill training and staff shortage that can only happen while we are developing the software. So it’s a project risk. Personal issues between developers and testers political issues such as problems with testers, communicating with the developers failure by the team to follow up on information found in testing and reviews, for example, not improving development and testing practices improper attitude towards expectation of testing, for example, not abbreviating the value of finding defects during testing. All of these can only happen while we are developing the software. So it’s a project risk. Sublime issues failure of a third party to deliver maybe the hardware on time or contractual issues with suppliers, vendors or contractors. And now for the second type of risks product risks. Product risk is a potential of a defect or caring in the life environment. Examples of product risks are failure prone software delivered the potential that a defect in a software or hardware could cause harm to an individual or company. Poor software characteristics such as functionality, security, performance poor data integrity and quality such as data migration issues software that doesn’t perform its intended functions. All of these events can happen at the customer site on a live environment. So they are broader risks. Now let’s talk about risk analysis. The level of risk or the risk score will be determined by the likelihood of the adverse event happening and its impact. There is an equation that we need to know level of risk equals probability of the risk multiplied by impact if the risk happened. So for example, if we have two risks, the first is the risk of having a UI issue. The probability of this risk happening is four. Four on a scale of one to five where one is a low risk and five is a high risk. But the impact of this risk happens is very low, only one using the same scale.

Then the level of risk of the risk score for that risk is four multiplied by one equals four. A second risk might be a miscalculation in one of the reboots the probability of such a risk is very low, say two. But the impact of such a risk is very high. The customer will really get based off for that defect. So let’s say the impact equals three. So the level of risk equals two multiplied by three equals six. So the level of risk for the miscalculation is higher than that of the UI issue. Which means that if we have a very limited time for testing, then we would concentrate our effort to test the report to lower the probability of the miscalculation. Barrierizing risk is an attempt to find the potential critical areas of the software as early as possible. Now we have analyzed our risks and barritorize them. I have a problem with this word, so forgive me about that. Then what we need to do now handle those risks or lower their risk levels. There are four ways we can handle or respond to risks. One is to avoid the risk doing anything to make this risk level equal zero, meaning either making the probability zero or making the impact of that risk zero. Let’s imagine a risk let’s imagine a risk that you have heard rumors that one of your team members let’s call him Jack might move to another company.

To avoid such a risk, you wouldn’t assign Jack to your project in the first place and get another one, so the risk will be zero. The second way to handle risks is mitigate. Mitigate means that you will lower the risk level. And you can achieve this by either lowering the probability or lowering the impact of the risk. Well, what do you think we should do with Jack? How can you lower the mobility of him moving to another country? We can lower the mobility by giving him a promotion or salary increase. Or you can lower the impact by giving him minor tasks to welcome. The third way to handle risks is transfer, meaning we should try to move the risk from our side to another side. You might ask Jack’s manager to assure you that if Jack left the company, then he would be responsible for finding you another resource with the same qualification. Or maybe by outsourcing the whole job to another company. The last method to handle risks is accept. And you can accept actively by putting a plan to be executed in case Jack lifted the company, like planning for two weeks handover from Jack to a new resource. Or you can accept the risk passively by simply waiting for the risk to happen and do nothing and see what’s going to happen. Wow, that was a tough risk management course. In five minutes or less. I hope it does make sense to you. It’s clear that any project risk will later affect the product itself. So the objective of all our risk management efforts is to minimize product risks. A riskbased approach to testing provides proactive activities to reduce the risk levels of product risk as early as possible in the software development lifecycle.

2. Independent Testing [CC]

Test organization and Independence in the first section we talked about independent testing from the psychology perspective of the tester. In this lecture we will elaborate more on this topic, but from the point of view of how independence affects the test management of the software project. The approaches to organizing test team vary from a company to another and from a project to another. But testing independence should be put into consideration when organizing a testing team. On one side of testing independence lies at a developer with low independence who tests his own code. A little higher independence is tested from the development team, then the independent testing team inside the organization, the customers testing specialist. And on the very other side lies a third party or a contractor with very high independence. Independent testing is sure a good thing, but it doesn’t mean that we should only consider highly independent testers. Moreover, independent testing also has its drawbacks. So let’s look at each type of testers from the independence point of view and see the pros and cons of considering this type of tester to the testing team. First, the developer, the author of the code. Should we allow him to test the code even if he is highly dependent on the code? The pros of using the developer for testing are he knows the code best. He will find problems that the testers will miss. They can find and fix faults achievedly.

The cause of using the developer for testing are difficult to destroy on work. It’s his own baby after all. Tendency to see expected results, not actual results. Subjective assessment. Now let’s consider a tester from the development team other than the developer himself. The bows are independent view of the software more independent than the developer. He is dedicated to testing, not coding and testing at the same time. Both of the team working to the same goal quality. The cons are lack of respect. He’s a body after all. He’s lonely. Thankless task. He is the only tester in the budget. There will be some sort of peer pressure. He has a single view opinion. Again, he is the only tester in the budget. Then comes the independent testing team whose main job is testing. The pros dedicated team just to do testing, especially testing exhibits. Testing is more objective and more consistent. The cons off of the the world syndrome. There’s a barrier between the developers and testers. And there could be some sort of politics issues between the two teams. Maybe confrontational overreliance on testers. Developers will be lazy to test their code depending on the tester to do the job for them. Now, what about the customer?

Can we debnd on the customer to test the software? Sure. They are the highest specialist business expertise. They know the business very well. And they might have a dedicated team just to do the testing as well. But they might not have testing expertise. And communication with the developers will be tougher. What about testing consultants or subject matter experts? They are highly specialist testing expertise. Better planning and control from a broad view of testing in the organization. But do they have the level of expertise to do the job? They need good people, skills and communication. They might not have the authority to do the job. Last with the highest independence comes third party organization where we outsource the testing of the software to another organization. There are highly specialist testing expertise if outsourced to a good organization independent of internal politics. But they might lack the knowledge of the product. Expertise gained in that case will go outside of our company. They could be very expensive and there might be some sort of leaking of confidential information. So what is the best way to organize a team for large, complex or safety critical projects? It’s usually best to have multiple levels of testing with some of all of the levels done by independent testers. Development staff may participate in testing, especially at the lower levels and we can ask the users to help with the testing. We can also ask testing subject matter experts to test the critical bars of your application if needed and so on and so forth.

Therefore, the idea is to get as much as possible from the bows of independent testing and try to avoid as much as possible from the cons of independent testing. To summarize, the pros or benefits of independent testing are independent testers see other and different defects and are unbiased. An independent tester can verify assumptions that others made during the specification and implementation of the system. If a developer assumed that a value should be in a specific range then the tester will verify this assumption and will not take it for granted. Cons or drawbacks of independent testings include isolation from the development team. At least they will be in a different team with a lot with a lot of politics governing the relationship between the teams. Developers may lose a sense of responsibility for quality. Developers may lose a sense of responsibility for quality. Many times I’ve heard developers think that they shouldn’t test their code because it’s the tester’s responsibility which of course is not right. I’m saying that in the nicest possible way.

3. Tasks of Test Leader and Tester [CC]

Testing tasks may be done by people in a specific testing role or may be done by someone in another role, such as the project manager, quality manager, developer, business and Domain Expert Infrastructure or It operation. The ICTB curriculum talks in detail about two roles only the test leader and the tester. Though the same people may play both rules at various points during the project. Let’s take a look at the work done by these rules, starting with the test leader. Test leader tasks include he will write overview, a test strategy for the project and test policy for the organization if not already in place. He should coordinate the test strategy and plan with project managers and others. They blend the tests, considering the context and undertaking the test objectives and risks including selecting test approaches, estimating the time, effort and cost of testing acquiring resources, defining test levels, cycles, and blending incident management and also they schedule the tests.

They should introduce suitable metrics for measuring test to progress and evaluating the quality of the testing and the product. They should contribute the testing perspective to other project activities such as integration planning. They will initiate the specification, preparation, implementation and execution of tests, monitor the test results and check the exit criteria. They control the project and adopt a blending based on test results and progress sometimes documented in status reports and take any action necessary to compensate for problems. They will select tools to support testing and organize any training in tool used for testers. They will write test summary reports based on the information gathered during testing. They make sure that the test environment is put into place before test execution and managed during test execution. Configuration management is taking care of different versions of different projects. Deliverables test leaders ensure proper configuration management of the test where reduced, and traceability of the test to the test basis. We will talk more about configuration management in coming lectures. They recognize when test automation is appropriate and if it is. They will blend the effort, select the tools, and ensure training of the team. Sometimes test leaders are called test managers or test coordinator. Alternatively, the test leader role may wind up assigned to a project manager, a development manager, or a quality assurance manager. Now let’s talk about the tasks of the tester. The tester will analyze, review and assess user requirements, specifications and models for testability.

The tester will set up the tester environment, setting up the hardware and software needed for testing. They will create testification and prepare test conditions and test cases. Testers will prepare and acquire test data. Testers will implement tests on all test levels. They will execute and log the tests, evaluate the results. They will measure performance of components and systems. They will report deviations they will automate. Tests may be supported by a developer or a test automation expert. They will use test administration or management tools and test monitoring tools as required. They will review and to contribute to testable lens and also review tests developed by others. The equations in this but are usually to differentiate between the tasks of a tester and a test leader. As you may have noticed, the test leader tasks are related to how we do things, but the tester tasks are related to the actual hands on of doing those things. Thank you.

4. Test Strategy and Test Approach [CC]

Test strategy and test Approach the test strategy describes Test strategy and test Approach the test strategy describes at a high level, independent of any specific project, at a high level, independent of any specific project, the how of testing for an organization. the how of testing for an organization. The test approach is the implementation of The test approach is the implementation of the test strategy for a specific project. the test strategy for a specific project. When you assess the risk of your project, as When you assess the risk of your project, as we mentioned in the previous lecture to refine your we mentioned in the previous lecture to refine your project objectives, then you can decide on the test project objectives, then you can decide on the test approach you will take to test your project based approach you will take to test your project based on your organization test strategy. on your organization test strategy.

The test approach will be reflected in your The test approach will be reflected in your decisions in the test plans and test designs. decisions in the test plans and test designs. It is a starting point for blending the It is a starting point for blending the test process, for selecting the test design techniques test process, for selecting the test design techniques and test types to be applied, and for and test types to be applied, and for defining the entry and exit criteria. defining the entry and exit criteria. Therefore, the choice of test approaches and strategies is Therefore, the choice of test approaches and strategies is one of the powerful factors, if not the most one of the powerful factors, if not the most powerful factor in the success of the test effort powerful factor in the success of the test effort and the accuracy of the test plans and estimates. and the accuracy of the test plans and estimates. We want to decide on the different test We want to decide on the different test strategy to test our newly developed software. strategy to test our newly developed software.

You can use different strategies You can use different strategies in testing a single software. in testing a single software. Now let’s look at the major types of Now let’s look at the major types of test approaches that are commonly found analytical. test approaches that are commonly found analytical. In analytical test approaches we use some formal In analytical test approaches we use some formal or informal analytical techniques, usually during the requirements or informal analytical techniques, usually during the requirements and design stages of the project, to decide and design stages of the project, to decide where to test first and where to test where to test first and where to test more and when to stop testing. more and when to stop testing. For example, the risk based strategy For example, the risk based strategy involves performing a risk analysis using involves performing a risk analysis using project documents and stakeholder input. project documents and stakeholder input. Then testing is directed to areas of greatest risk.

Then testing is directed to areas of greatest risk. Another analytical test strategy is the requirements Another analytical test strategy is the requirements based strategy where an analysis of the based strategy where an analysis of the requirement specification forms the basis for planning, requirement specification forms the basis for planning, estimating and designing tests. estimating and designing tests. Model Based In model based approach we Model Based In model based approach we create, design or benchmark some formal or create, design or benchmark some formal or informal models that our system must follow. informal models that our system must follow. For example, our software response time should For example, our software response time should be faster than that of the competitors. be faster than that of the competitors. We will keep on testing our software until We will keep on testing our software until the behavior of the system under test confirms the behavior of the system under test confirms to that predicted by the model. to that predicted by the model. Example of model based is the Stochastic Example of model based is the Stochastic testing where we use statistical information about testing where we use statistical information about failure rates as a model methodical approach. failure rates as a model methodical approach.

For example, you might have a checklist that For example, you might have a checklist that you have put together over the years that you have put together over the years that suggested the major areas of testing to run, suggested the major areas of testing to run, use then methodically design, implement and execute tests. use then methodically design, implement and execute tests. Following this outline material, test strategies have in common Following this outline material, test strategies have in common following a Briebled approach that has been following a brie bland approach that has been developed developed in house and gathered from outside or in house and gathered from outside or adapted from adapted from outside ideas and may have an outside ideas and may have an early or late early or late point of involvement for testing. point of involvement for testing.

Example of mechanical approaches are failure based, Example of mechanical approaches are failure based including error guessing and false attacks, a including ever guessing and false attacks, a checklist based and quality characteristic based process checklist based and quality characteristic based process or a standard compliant. or a standard compliant. In this approach, you might adopt an industry In this approach you might adopt an industry standard or unknown process to test the system. standard or unknown process to test the system. For example, you might adopt the Itbelle For example, you might adopt the Itbe 829 standard for your testing. E 829 standard for your testing. Alternatively, you might adopt one of the agile Alternatively, you might adopt one of the agile methodologies such as extreme programming bosses or standard methodologies such as extreme programming bosses or standard compliance strategies have in common reliance upon an compliance strategies have in common reliance upon an externally developed approach for testing, often with little externally developed approach for testing, often with little if any customization and may have an early if any customization and may have an early or late point of involvement for testing. or late point of involvement for testing. Dynamic approach in dynamic of holistic strategies such as Dynamic approach in dynamic of holistic strategies such as exploratory testing, where testing is exploratory testing, where testing is more reactive to events more reactive to events than reblond and than reblant and where execution and evaluation are concurrent well execution and evaluation are concurrent tasks. tasks, we try to learn from the current state We try to learn from the current state of the system under test to make more educated of the system under test to make more educated guesses of where to focus the testing.

Those techniques concentrate more on finding as Those techniques concentrate more on finding as many defects as possible during test execution many defects as possible during test execution and adapting to the outcome of the and adapting to the outcome of the testing actively, consultative or directed. testing activity consultative or directed. For example, you might ask the users or developers of For example, you might ask the users or developers of the system to tell you where to test or even the system to tell you where to test or even rely on them to do the testing regression adverse for rely on them to do the testing regression averse for example, you might try to meet all the tests of example, you might try to meet all the tests of system functionality so that whenever anything changes, you can rerun system functionality so that whenever anything changes, you can rerun every test to ensure nothing has broken. every test to ensure nothing has broken. Migration adverse approaches also includes the Regression adverse approaches also includes the reuse of existing test material. reuse of existing test material.

So which approach is the best? So which approach is the best? Again, there is no one best approach. Again, there is no one best approach. You can adopt whatever test approaches make sense to You can adopt whatever test approaches make sense to you and to your particular situation and feel free you and to your particular situation and feel free to borrow and blend between the approaches. to borrow and blend between the approaches. Questions in this topic in the Ihtqb exam Questions in this topic in the ISTQB exam are more about defining a situation and ask are more about defining a situation and ask you which best approach to use. you which best approach to use. For example, if you are using Azhar or Waterfall For example, if you are using Azure or Waterfall then what is the approach you are using? then what is the approach you are using? Process or standard compliant? Process or standard compliant? If you are asking the user which areas to If you are asking the user which areas to test then what is the approach you are using? test then what is the approach you are using? Consultative if you are using test cases from Consultative if you are using test cases from an old version of the software then what an old version of the software then what is the approach you are using? is the approach you are using?

Regression averse and so on how do you know which strategies Regulation averse and so on how do you know which strategies to pick or blend for the best chance of success? to pick or blend for the best chance of success? There are many factors to consider, but let There are many factors to consider, but let us highlight a few of the most important us highlight a few of the most important risks testing is about risk management, so consider risks testing is about risk management, so consider the risks and the level of risk. the risks and the level of risk. For example, for a well established application that is For example, for a well established application that is evolving slowly, regulation is an important risk evolving slowly, regulation is an important risk so regression so regression adverse strategies make sense. adverse strategies make sense for a new application, a For a new application, a risk analysis may risk analysis may reveal different risks if you make reveal different risks if you make a risk a risk based analytical skills so you have to based analytical skills so you have to consider consider which skills your tester possess and lack. which skills your tester possess and lack.

A standard compliance strategy is a smart choice when you A standard compliance strategy is a smart choice when you lack the time and the skills in your team. lack the time and the skills in your team. Testing must satisfy the needs of Testing must satisfy the needs of the stakeholders to be successful. the stakeholders to be successful. If the objective is to find as many defects If the objective is to find as many defects as possible within a minimal amount of upfront time as possible within a minimal amount of upfront time and effort invested, then a dynamic strategy makes sense. and effort invested, then a dynamic strategy makes sense.

Regulations sometimes you must satisfy not Regulations sometimes you must satisfy not only stakeholders but also some regulations. only stakeholders but also some regulations. In this case, a mechanical test In this case, a methodical test strategy may satisfy those regulations. strategy may satisfy those regulations. The nature of the blow that ends The nature of the blow that ends the the business for example, a different approach business for example, a different approach is required is required for testing mobile phone coverage for testing mobile phone coverage than for testing than for testing an online banking operation. an online banking operation, business concern considerations and Business concern considerations and business business continuity are often important. continuity are often important. If you can use a legacy system as a model for If you can use a legacy system as a model for a new system, then you can use a modelbased strategy. a new system, then you can use a modelbased strategy. Thank you. Thank you.

5. Test Plan Sections [CC]

The Italy 829 standard identifies that there should be a minimum of 16 sections present in a tester plan. Those sections are One test blend identifier are unique that will identify or used as a reference for the blend, such as Expert Wave ABC. One to three. Two. Introduction a brief introduction to this document, its purpose and the project for which it has been produced. Three Test Items any document, software, tool, data that the tester will need to accomplish the testing activity is called a test item. So the requirement document is a tester item, the design document is a tester item. The software to be tested is a tester item. The tools to be used for testing are test items and so on. This section should list all the test items that the tester will use and when and how the tester will acquire these test items. It should also contain how and who will maintain those items. Four Features to Be Tested In this section, we should identify all software features to be tested by the tester. Five Features Not to Be Tested Here, we should identify all software features that will not be included in the testing activity and the reasons for not including them. This is very important to set the expectations of the stakeholders of what will be accomplished in this plan.

Six approach details the overall approach for testing this could include a detailed process definition or could refer to other documentation where the details are documented. For example, we could refer to the organization’s test strategy. Seven Item Pass Fail Criteria Here we will define what criteria should be satisfied to indicate that the item has passed the testing activity. For example, the item must have less than ten low biology bugs to pass, otherwise it will fail. Eight Suspension and Resumption Criteria if the tester started to test a component he just received from a developer and the tester found some buds are not working at all, so there is no need for the tester to continue the testing activity. It will be a waste of time for the tester to log those many defects. So it’s better to suspend the testing activity until the developer fixes those abundant issues than the tester can resume the testing activity. In this section, suspension requirements define criteria for the stopping part of all of the testing activity. Resumption Requirements Specifies the requirements to resume the testing activity.

Nine test Deliverables Here we will list what we promise to deliver when executing the plan. For example, test the plans for each test level test the specification, design, case and procedure, test summary reports, meeting minutes, and so on. Ten Testing Tasks all tasks for blending and executing the testing, including the dependencies between those tasks. Eleven Environmental Needs Here we will define all the environmental requirements for testing, such as hardware, software, tools, space, locations, and so on. Twelve Responsibilities Here we will identify the rules and tasks to be used in the testing project and who will own those rules. 13. Staffing and Training Needs staffing and training needs identify any actual staffing requirements and any specific skills and training requirements needed by the team such as automation or database knowledge and so on. 14. Schedule Here we will document tasks, dates, durations, delivery dates and key milestones. 15. Risks and Contingencies High level project risks and assumptions and contingency plan for each risk should be documented last.

16. Approvals in this section we will identify all approvals of the document, their titles and the date of signature. Other important elements of the testing plan are defining the entry and exit criteria for testing. Let’s look at them in detail. Integrator are used to determine when a given test activity can start. This could include the beginning of a level of testing, when test design and or when test execution is ready to start. Inter criteria is helpful in making sure that we want to start testing until some aspects are ready. Otherwise we will be wasting our time. You can define different anti criteria for different testing activities. Examples of some typical anti criteria to test execution for example, may include test environment availability and readiness. Test tool readiness in the test environment testable code availability, test data availability if the customer hasn’t provide us with the test data, then there is no need to start testing now and waste our time. All test design activity has completed. Test conditions, test cases and test procedures are ready.

Software documentations, availability requirement document or design documents are ready. Exit Criteria We have heard the term exit criteria before in the test bosses. In the first section, exit criteria are used to determine when a given test activity has been completed or when it should stop. Examples of some typical exit criteria to test execution may include no high priority or severe defects are left outstanding. We have spent the budget for the testing activity. The schedule has been achieved. All high risks area have been fully tested with only minor residual risks left outstanding. All tests blend have been run. The status of the important quality characteristic of the system could be an exit criteria. Remember that according to the tested bosses that when we reach the exit criteria, the tester should provide a reboot of his findings to the test leader or stakeholder to decide if the testing activity should continue or stop. I know here we have learned a lot of many criteria terms in this lecture. So let me give you an example to explain the different terms. Imagine you are testing the performance of a specific web page. You want this webbage Usband’s time to be 6 seconds.

Therefore, when a user loads the bid, it should be loaded within maximum 6 seconds. To measure the response time accurately, you would need to rent a performance tool and you only have a budget of $500. But you must get approval for this budget first. So the anti criteria to start the testing activity would be the budget get approved. The past criteria would be to pass the 6 seconds limit. The exit criteria would be to spend the whole $500. You might also put a suspension criteria that the server itself is not up to your expectation.

Then you would suspend the testing and the resumption criteria in that case would be to upgrade the tool. So as you can see from the example that we can reach the exit criteria which is spent the $500 but the item might fail the test because its response time is say 8 seconds. In this case the tester should write a summary report to the stakeholders indicating his finding and that the base response time is only 8 seconds. The decision makers then should decide if they should continue testing and maybe ask for more budget for the testing or if they are happy with the 8 seconds result and will stop of the testing. At this point I hope this makes sense. Thank you.

6. Test Planning Activities [CC]

Tested planning Activities test managers put a lot of effort to create the test plan. They have to go through various activities and communicating with different stakeholders to build the plan. Those activities include identifying and agreeing on the objectives of the testing. This will enable us to know when we reached our objective or not yet. Determine the scope and the risks that need to be tested. Putting together the overall approach of testing. Ensuring that the test levels and entry and exit criteria are defined. Coordinating with the project manager and making sure that the testing activities have been included within the software lifecycle activities in the correct sequence and dependency decide what needs to be tested, what rules are involved with and who will perform the test activities, deciding how the test results will be evaluated and defining when to stop testing.

Building a schedule Zet identifies when and who will undertake the test analysis and design activities. Also the schedule for test implementation, execution and evaluation. Finding and assigning resources for the different activities that has been defined. Deciding what the documentation for the test project will be level of detail, structure and templates for the test documentation selecting metrics for monitoring and controlling the project setting the level of detail for test procedures in order to provide enough information to support reproducible test vibration and execution thank you.

• Category: Uncategorized