0 Introduction Test strategy A Test Strategy for single high-level test B Combined testing strategy for high-level tests...

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "0 Introduction Test strategy A Test Strategy for single high-level test B Combined testing strategy for high-level tests..."

Transcription

1 TPI Automotive Test Process Improvement Version: 1.01 Author: Sogeti Deutschland GmbH Datum: Sogeti Deutschland GmbH. Version

2 0 Introduction Test strategy A Test Strategy for single high-level test B Combined testing strategy for high-level tests C Combined strategy for high-level tests plus low-level tests or evaluation D Combined strategy for all test and evaluation levels Life cycle model A Planning, Design, Execution B Planning, Preparation, Design, Execution and Completion Moment of involvement A Completion of test basis B Start of test basis C Start of requirements definition D Project initiation Estimating and planning A Substantiated estimating and planning B Statistically substantiated estimating and planning Test design techniques A Informal techniques B Formal techniques C Mathematical methods Static test techniques A Inspection of test basis B Checklists Metrics A Project metrics (product) B Project metrics (process) C System metrics D Organization metrics (>1 system) Test automation A Use of tools B Managed test automation C Optimal test automation Test Environment...48 Sogeti Deutschland GmbH. Version

3 9.A Managed and controlled test environment B Testing in the most suitable environment C Environment on call Office and laboratory environment A Adequate and timely office and laboratory environment Commitment and motivation A Assignment of budget and time B Testing integrated in project organization C Test engineering Test functions and training A Test manager, integrator and testers B (Formal) Methodical, Technical and Functional support, Management of the test process, testware and infrastructure C Formal internal reviewing Scope of methodology A Project specific B Project specific with external scope C Organization generic D Organization optimizing, R&D activities Communication A Internal communication B Project communication (defects, change control) C Communication in organization about the quality of the test processes Reporting A Defects B Progress (status of tests and products), activities (costs and time, milestones), defects with priorities C Risks and recommendations, substantiated with metrics D Recommendations have a Software Process Improvement character Defect management A Internal defect management B Extensive defect management with flexible reporting facilities C Project defect management Testware management A Internal testware management...78 Sogeti Deutschland GmbH. Version

4 17.B External management of test basis and test object and traceability of system requirements to test cases C Reusable testware Test process management A Planning and execution B Planning, executing, monitoring and adjusting C Monitoring and adjustment in organization Evaluation A Informal evaluation B Evaluation techniques C Evaluation strategy Low-level testing A Life cycle: planning, design and execution B White-box techniques C Low-level test strategy Integration testing A Integration identified as a separate and planned process B Test strategy for integration C Standardized approach for integration Test maturity matrix Overview dependencies Glossary Literature Sogeti Deutschland GmbH. Version

5 0 INTRODUCTION In modern car electronics and software development, testing is an important part of the development process. The growing complexity of these electronics and software demands the enhancement of the development process and therefore also of the test process. Since 1998, TPI (Test Process Improvement) [Koomen and Pol, 1999] offers an instrument to stepwise improve the test process. Since then, it was introduced in a lot of projects to bring the test process to a higher level. Initiated by the German automotive industry, the development of TPI Automotive was started in 2003 (and finished in 2004). The objective was to create a model with all the ingredients of the existing TPI-model but translated and extended to cover the automotive peculiarities. The TPI model offers a framework to determine the strengths and weaknesses of the current test process within a project or organization. On the other hand, the model offers support in the formulation of adequate and realizable improvement suggestions for the test process in terms of quality, cost and time. In this introduction a short description is given of the model. This description is followed by an explanation of how the terms high-level, low-level and integration testing are used in this model and what that means for the usage of the model. of the model The TPI model can be visualized as follows: Key Areas Levels TPI Matrix Checkpoints Improvement Suggestions Key Areas In the TPI Automotive-model 21 Key Areas are used covering all the aspects of a structured test process. One key area identifies a typical aspect of the test process and offers a guideline how to improve the test process related to this aspect. Key Area Key Area Test strategy Test functions and training Life-cycle model Scope of methodology Moment of involvement Communication Estimation and planning Reporting Test design techniques Defect management Static test techniques Testware management Metrics Test process management Test automation Evaluation Test environment Low-level testing Office and laboratory environment Integration testing Commitment and motivation Sogeti Deutschland GmbH. Version

6 Levels For every key area different maturity levels are found, starting with Level A for all key areas up to level D for some key areas. Every next level differs in his nature of maturity from the previous one. Every higher maturity level implies the lower maturity level. With determining the maturity level for every key area the current situation of the test process is visualized. Checkpoints To make an objective determination whether the maturity level applies to a certain key area, Checkpoints are given. Only when all the checkpoints belonging to a maturity level are fulfilled, this level applies. Test Maturity Matrix (TPI Matrix) The key areas and their maturity levels are combined in the Test Maturity Matrix (TPI Matrix; see Chapter 22). The distribution of the maturity levels is based on priorities and dependencies between the maturity levels of different key areas. For example to start with test automation, it is necessary to have test cases. These test cases can be derived by using test design techniques. Therefore the maturity level A of the key area Test design techniques has a higher priority (meaning it is placed more to the left in the matrix) as maturity level A of the key area Test automation. Maturity level A of the key area Metrics depends on level B of Test process management, level A of Defect management, Level B Reporting and level B of Commitment and Motivation. Level A of the key area Metrics is therefore situated as far to the right as level B of the key area Commitment and motivation. (All the dependencies between the different levels of the key areas are mentioned in chapter 23). Before improvement suggestions can be formulated, it is necessary to determine the maturity level of each single key area. An analysis of the test process is carried out to collect all necessary information to determine whether the checkpoints of the key areas are fulfilled. If the checkpoints are met, the maturity level applies to the key area. The results are visualized within the matrix, showing which maturity levels apply to which key areas. The same matrix can be used to visualize which maturity levels for the different key areas are desired. Indications, to which measures should be taken to bring the test process to these desired levels, are mentioned in the form of improvement suggestions. Improvement suggestions In the model for every maturity level of each key area, Improvement Suggestions are given. These improvement suggestions can be used as a basis to define tailor made (dedicated to the process that is analyzed) improvement activities. The implementation of these improvement activities should bring the organization the desired maturity levels for the respective key areas. Application of the TPI Automotive model Every change process follows more or less the same procedure: changes are implemented on the basis of specific objectives in order to improve the process from the current towards the desired maturity. The improvement of the test process doesn t differ here from other change processes. The following figure shows the Sogeti Deutschland GmbH. Version

7 different activities of a change process for testing. These activities are described, with special emphasis on the items where the TPI Automotive model can play a specific role. Obtain awareness Determine target, area of consideration, and approach Execute assignment Define Improvement actions Perform evaluation Formulate plan Implement improvement action Obtain awareness The first activity in the change process is to obtain awareness for the necessity to improve the test process. The reason to improve the test process usually lies in experiencing a number of problems within or surrounding testing. The improvement of the test process is usually seen as one of the possibilities to solve these problems. This awareness also implies an agreement on main issues by the parties involved as well as their commitment to the change process. It isn t enough when there is commitment at the start of the change process, this commitment should be maintained throughout the process. This requires a dedicated and continuous effort. Determine objectives, scope and approach This activity includes the formulation of objectives, scope and approach for the change process. Should testing become cheaper, faster or better? Which test levels and which test projects are considered, how much time is available for the improvement activities and which cost are estimated? Execute analysis The analysis is executed in order to describe the current situation of the test process. The usage of the TPI Automotive model is an important part of the analysis, because it offers a framework to determine the strengths and weaknesses of the process under consideration. On the basis of collected data from interviews and document study, for each key area the levels are evaluated by means of the checkpoints. The Test Maturity Matrix is used in order to show the integral situation of the test process. The matrix clearly shows the strengths and weaknesses of the test process by coloring the obtained levels per key area in the matrix. Define improvement activities On the basis of the improvement objectives and the result of the analysis, the improvement activities are defined. The activities are bound to the rule that they support a stepwise and smooth improvement of the test process. The TPI Automotive model helps to determine the improvement activities. The levels of the key areas and the TPI matrix give several possibilities to determine improvement steps. Depending on the objectives, the scope, the timeframe and the Sogeti Deutschland GmbH. Version

8 results of the analysis, it is possible to implement improvement activities for one or more key areas. For each selected key area it is possible to choose for an improvement to the next level or on specific occasions to the subsequent level. Furthermore the TPI Automotive model offers a large amount of improvement suggestions to help achieving the next level of maturity for a specific key area. Formulate plan A plan is formulated in order to obtain commitment and engagement of all stakeholders for the activities to be implemented. The plan includes objectives and a planning of activities in order to achieve the objectives. The plan consists both of activities related to content as well as activities related to the process of change as such. Implement improvement activities The improvement activities are implemented. In this phase the hidden resistance to the improvement activities becomes visible. The implemented activities should be monitored in terms of being and to what extent they were executed. A useful instrument is the so called "self assessment", where the TPI Automotive model is used to quickly determine the current state of the test process. The people involved in the process evaluate their own process with the help of the TPI Automotive model. A crucial part of this phase is to secure the implemented activities in order to make sure that this is not a one time only. Perform evaluation What was the result of the implemented improvement activities? In this phase attention is given to the extent in which the original objectives were met. On the basis of these observations, the way of continuation of the improvement process can be determined. Scope of high-level, low-level and integration testing In the TPI-automotive model a differentiation is made between three test levels: Low-level testing Integration testing High-level testing High-level testing is the process of testing whole, complete products. A whole, complete product means a product as defined in the assignment for this product. The purpose of high-level testing is to show to which extend the requirements are implemented in the system. Low-level testing is the process of testing individual components, one at a time or in combination. To properly test a component, in general, the tester is forced to use stubs and drivers or to replace these with the real component(s). Integration testing is the process to expose faults in the interfaces and in the interaction between integrated components. In contrast with low-level testing the main focus of integration testing is the functioning of the assembly. The scope of integration testing is changing during the complete development process. In the first stages of the development process the focus is on integration testing of components at the lowest level. The testing is not very much different from low-level testing. At the end of the development process it is integration testing of the assembly of complete subsystems where the character of integration testing is more like a highlevel test. Still for these two opposites the same key area (21) is applicable, because the processes of integration testing are the same. Although in the model a differentiation is made between the three test levels, this doesn t mean that for every analysis all three should be in scope. The usage of the model for a situation where the high level is in scope is straight forward. The key areas 1 to 19 are applicable for this situation. If also the low-level testing and integration testing are within the scope of the analysis key areas 20 and 21 are also applicable. In situations where two or more test levels spanning more than one organisation or organisation part, the usage of the model will be a little more complicated. There are Sogeti Deutschland GmbH. Version

9 two possible ways to use the model. In the first approach the test levels are analysed as a complete process and the results are aggregated into one TPI-matrix. In the second approach the test levels are analysed individually and the results of the analyses are presented in a separate TPI-matrix for each test level. For high-level and low-level testing this means that the key areas 1 to 19 are applicable and for integration testing this must be extended with key area 21. However, in practice the low-level testing will most of the time be taken into account when one or more of the other test levels are analysed. Sogeti Deutschland GmbH. Version

10 1 TEST STRATEGY One of the most important key areas is the test strategy. The aim of the test strategy is: Detecting the most important defects as early and as cheap as possible "Most important" is related to the risks for the organization if the product is of insufficient quality. The test strategy defines which requirements and (product) risks are covered by which test level. The better each test level defines its own strategy and the more the different test level strategies are adjusted to each other, the higher the quality of the overall test strategy. Test process improvement usually starts with the high-level tests. As a consequence, for this key area a test process passes through the different levels in maturity: starting with a risk-based test strategy for a single high-level test to a situation where an overall risk-based test strategy is established covering all test levels and evaluation. A feature of the start level is that the test is only controlled by resources and time. Usually only one test design technique is used and only functionality is tested. Also there is no coordination between the different test levels regarding the quality characteristics to be checked, the scope of the test, etc. The test strategy is based on risk estimation (risk based test strategy). This risk estimation offers the possibility to find the optimal balance between the desired quality and the amount of time/money required. Parts with a high risk will be in full focus of the test. The risk estimation in combination with the size of the part determines the amount of time/money required to test this part. Essential steps towards a risk based test strategy are: determine quality characteristics; In consultation with the stakeholders, the quality characteristics are determined on which the test is to be focused. During the test process, the test results of the selected quality characteristics are reported to the commissioner. determine the relative importance of quality characteristics; Based on the results of the preceding step it is indicated how to distribute the test effort among the selected quality characteristics. The starting point is that the testing of each quality characteristic is equally time-consuming. break down into system parts; In this step the system is broken down into system parts based on the logical system architecture. When possible divide the system such that each system part is related to one supplier. If deviations from this division are made, they must be explicitly motivated. Besides this the item "total system" is often taken into consideration to indicate the relative importance of testing the entire system. The aim is to cope with risks, which are not covered by testing all system parts individually. determine the relative importance of system parts; Based on the results of the preceding step, it is indicated how to distribute the test effort among the system parts. The starting point is that testing each system part is equally time-consuming. Next, indicate for each system part which quality characteristics are applicable and how thorough these should be tested, in relation to the assigned importance. If the decomposition has led to a one-on-one relation between system parts and suppliers, concrete entry and/or acceptance criteria can be communicated to the supplier. determine measuring techniques to be used; As a final step within the test strategy, measuring and in particular test design techniques are selected which apply to the selected quality characteristics and system parts. Sogeti Deutschland GmbH. Version

11 In defining the test strategy, specific points of attention in determining the risks are: The functionality of system parts, The complexity of system parts and their interface, The supplied proof of quality of system parts (via test cases, test reports, certificates, established user base, etc.) by suppliers or the desired proof of quality described in the entry criteria. The transparency of the system parts. Transparency means how easy it is to determine how the system part functions and is therefore an indication how easy it is to detect the cause of failures. Transparency can be established for instance by original specifications provided by suppliers of the system parts, by providing source code, by so-called test windows in the software to display intermediate results. The frequency of use of the system parts. The potential damage if a specific part of the software fails. The availability of (test) resources (both staff and (test) infrastructure) Starting point for the risk assessment part of the test strategy are the functional and non-functional requirements, possible standards or regulations and other constraints. Examples may be: performance requirements, legal requirements, safety requirements (e.g. ISO 61508), and memory constraints (ISO: Resource Utilization). Safety related systems or system parts are quite special in the discussion about risks. Although it is possible to make a differentiation between a high or low influence on safety not testing such parts is out of the question. The thoroughness of testing and used test design techniques are the instruments that can be influenced by the risk estimation (although ISO will limit the possibilities). 1.A Test Strategy for single high-level test The commissioner of a test expects certain qualities of the system to be delivered which are very different for each system. It is of great importance that the commissioner and the supplier can communicate with each other about this, and, depending on the commissioners demands, make a translation to a test approach. Discussing the test strategy with the commissioner is often regarded as a revelation. Suddenly, all sorts of choices are available, instead of just for time and money. A well established test strategy contributes to a more manageable test process. The information that is generated during a risk based test strategy is of valuable use to make a well considered choice between demanded quality, time and money. When a commissioner wants testing to be cheaper, the test manager can provide the commissioner a choice: should a particular test be omitted or should another test be performed lighter? This gives the commissioner the opportunity to see the consequences of less time and/or money available. Example I: A car manufacturer will implement a new version of existing software. For this new version an acceptance test is planned and therefore a risk based strategy will be carried out. In the preparation of this strategy it becomes clear that the new version is not really a new piece of software but a newly parameterized version of the old software. This information leads to the conclusion that risks introduced by code changes don t exist and therefore no low level testing is necessary. In this case the risk estimation can focus on which requirements are related to the parameter settings changes and for which requirements a regression test is necessary. This analysis saves a lot of time and effort and made it possible to focus on the risks that are really necessary to be covered. Sogeti Deutschland GmbH. Version

12 Checkpoints 1.A.1 1.A.2 1.A.3 1.A.4 1.A.5 1.A.6 A motivated consideration of the product risks takes place. Typical risk categories to be verified are: technical risks (a FMEA can be used as basis), organizational risks associated to development/test, operational usage of the product, political and contractual risks and liability. The consideration implies at least the following aspects: Regression testing of unmodified parts of the software is part of this strategy when the test object is an update or new release of existing software. Software is often parameterized, for instance because of different country legislation. In such cases, part of the test strategy should be whether and how the different parameter settings are tested, based on the estimated risks. The software to test can be commercial-off-the-shelf (COTS), reuse or core, tailor made and often a combination of these. The test strategy must take into account the different risk profiles of COTS, reuse/core or tailor made software. Risks starting from the dependencies of products of the HW- and SWbaselines are taken into account, e.g. required backward compatibility or HW breaks. The stakeholders of the product are involved in the process of defining the test strategy. At least the stakeholders (especially the acceptant of the product) have to be invited to review the proposed test strategy and its present status. There is a differentiation in test depth, depending on the risks and, if present, on the acceptance and entry and exit criteria: not all system parts, variants and versions are tested equally thoroughly and not all quality characteristics are tested (equally thoroughly). When incremental delivery of functionality takes place (so-called A-Sample, B-Sample, etc) for every increment a clear decision is made what must be tested and which regression tests must be carried out. One or more test design techniques are used, suited for the required depth of a test. For retests also a (simple) strategy determination takes place, in which a motivated choice between "test solutions only" and "full retest" is made. At least a differentiation between changes in parameter settings and changes in source code is made. Dependencies Test design techniques, level A, Informal techniques Test design techniques are necessary to make the choices for lighter or more thorough testing concrete. Commitment and motivation, level A, Assignment of budget and time Strategy needs to be discussed with the commissioner of the test, because it is strongly related to the time and money needed. Improvement suggestions Involve the various interested parties such as commissioner, product line manager, and project manager in determining the test strategy. Create awareness by indicating the risks of the current working method, or indicate how testing can be carried out cheaper and/or faster. Sogeti Deutschland GmbH. Version

13 If there is only one design technique in use, then try to fit in more and/or less depth by means of simple variations. An example of more or less depth is testing or not testing boundary values. Boundary values are values which closely surround the limit of a range. In the condition "A>=10", 9, 10 and 11 are boundary values. For retesting, formulate a working method in which each time the consideration between a full retest, a "thin" retest (per defect/function/subsystem) or even no retest is made. The result of this consideration shall be motivated and documented. For safety related software a full retest is most of the time mandatory. Distinguish system parts and quality characteristics and try to assign a relative importance to each system part and each quality characteristic. Translate this importance into a lighter or a more thorough test. In order to minimize the risk of losing time by a late delivery of certain system parts fall back scenarios can be considered. Replacement of a system part by a previous version with more or less the same functionality can help. The risk of regression (an already tested system part does not function properly anymore after the introduction of a new version of any other system part) should be considered in this case. In case of incremental development the determination and maintenance of a regression test will save a lot of time. The regression test can be build up gradually per increment. The usage of test tools should be considered in this case. Eventually perform the complete determination of strategy. For testing parameterized software, there are some possibilities: test the software using different parameter settings (does the software deal correctly with the set parameters) review or test whether the different parameter settings that are used, are correct (did we set the parameters right for each situation). When the amount of possible parameter settings is too high (because large variant ranges or a lot of regulation differences between different countries) a risk estimation is necessary to find out which parameter settings can be (partly) neglected during test. COTS has compared to tailor made software a different risk profile. As a general rule of thumb, for COTS the functionality risks tend to be smaller, as other users of the software probably have found many of the existing functionality defects already. On the other hand, the risk whether the software is suitable enough for the organization is higher, as it has been designed as a "one size fits all". Identify the commissioner of the test and let the commissioner make clear what is expected of the test. 1.B Combined testing strategy for high-level tests Coordinating the test strategies of the different high-level tests prevents that tests are performed twice or that necessary tests are disregarded. It offers the possibility to determine when the right moment is for performing a certain test. The right moment is the test level where the overall costs for testing plus the costs of rework and retesting are at the minimum. Precondition for this determination is that for each high-level test is known which tests are planned and how thorough testing is planned to take place. The quality of the communication between commissioner and suppliers is of the utmost importance here. Both of them must understand their mutual interest in demanding and providing information concerning tests conducted by the supplier. The commissioner has to ask for the right information and the supplier should give a clear insight in what he has planned to test and what not. Sogeti Deutschland GmbH. Version

14 Checkpoints 1.B.1 1.B.2 1.B.3 1.B.4 1.B.5 Coordination takes place between the different high-level tests, often the system-, acceptance- and production acceptance test, or supplier and commissioner side testing, in the field of test strategy (risks, quality characteristics, area of consideration of the test and planning). The result of the coordination is a coordinated strategy, which is documented. During the total test process this strategy is controlled. Each high-level test determines its own test strategy, based on the coordinating strategy, as is described in level A. Deviations from the coordinating strategy are reported. A substantiated adjustment of the coordinating strategy is made based on the risks identified for these deviations. The validity of the strategy is checked in case of incremental delivery for each increment. For retests coordination takes place between the different test levels. In case the different test levels exceed the borders of the organization, commissioner and supplier make clear decisions about the retest at both sides based on the entry and exit criteria. Dependencies Life cycle model, level A, Planning, Design, Execution For coordinating it must be agreed beforehand about what, how and when to test (phase planning). All activities to be carried out must be documented. This requires insight in the process, for which a life cycle model is a prerequisite. Test design techniques, level B, Formal techniques The coordination of the various tests demands more insight in the quality and the depth of each test. This means the use of more formal test design techniques. Commitment and motivation, level B, Testing integrated in project organization To establish the coordination, commitment from the project management is required. This management must therefore have a desire for insight into the quality and depth of testing. Communication, level B, Project communication (defects, change control) Coordination requires that there is communication throughout the test process between the test levels and with the rest of the project. Test process management, level B, Planning, execution, monitoring and adjusting Insight into the quality of each test means that relying on plans only is not sufficient; the test process should be monitored and adjusted. (if applicable) Integration testing, level B, Test strategy for integration In case integration testing is high-level oriented: this is one of the high-level tests that shall be part of the overall test strategy. Improvement suggestions Begin with obtaining insight in what the different tests do. Important here is the extent to which insight can be obtained into depth and completeness of the individual tests. Indicate possible risks. Often improvement of the test process starts with a certain test level and there is no coordination yet with other test levels. In determining the strategy of this test level, define what is expected of other tests (in the area of test coverage). Try to find obvious deficits or double testing and initiate a discussion about them. Sogeti Deutschland GmbH. Version

15 Implement the role of test coordinator whose task it is to coordinate test levels, to record them in a master test plan and to monitor the coordination. The test coordinator reports to the project manager and the commissioner of the test. To prevent an entanglement of interests, it is preferred that the test coordinator is independent in relation to the various test levels. It can be considered to establish an acquisition inspection, in which testware of a certain test level is evaluated by another party on completeness and correctness. For example the software of an ECU is delivered to the OEM with test plan, test cases including trace-files (if relevant) and test reports. The OEM evaluates the testware to ensure that the entry criteria are fulfilled. Additional to the check on testware a so-called entry test can be defined and communicated to the deliverer of the test object. As part of the acceptance of the delivered test object this test is executed. This test shows clearly and objective whether the test object is ready for the next test level. Make use of exit and entry criteria per test level, where explicitly is asked for documentation and traceability of test coverage. Define entry and exit criteria for each test level to make a clear separation between the different test levels. Typical entry criteria are no defects left with the highest severity category, or prototype car is available in the defined configuration. Typical exit criteria are all planned test cases are executed and no pending defects left anymore. In the case of much overlap between certain test levels it can be an option to combine both test levels, i.e. combining the system test and acceptance test to an integrated test. Points of interest are the responsibilities and expectations. Legitimate reasons for the organization of the integrated test are: the suitability or availability of the test environment; early diagnosis and especially the correction of relatively important defects in the development process by using acceptance test cases; early exchange of knowledge about the system by developers and the commissioner; the common use of the test environment and the related management procedures; the use of test tools which normally cannot be used in the as-if-production environment, are at the disposal of the commissioner, including technical support; timely transferring knowledge to the commissioner about testing; early involvement in testing will stimulate the commissioner to actively think about testing; the integrated test optimizes the use of resources; personnel and test facilities are deployed from one source and conflicts of priorities are prevented in time; placing under one management improves the mutual understanding and the communication between the parties. Example: For new functionality an OEM has given the assignment to develop a new ECU for a brake system. The ABS of the brake system will be enhanced by an electronic brake system which can replace the hand brake. The ABS and the ECU hardware will be developed by the supplier who developed this already for a previous model. The electronic brake system software is developed by another supplier. This supplier can t carry out his system test on the target hardware because the delivery is planned much later in the project. The OEM and the software-supplier decide to combine the system test and the acceptance test. The software-supplier will design test cases for the system test and these will be reviewed by the OEM. The system test will be carried out by OEM and software-supplier together. The OEM will combine these tests with its own test cases for the acceptance test. By combining these tests the test environment (prototype car) can be used very efficiently. The combined execution of the test cases has the advantage that the understanding of the system by the OEM is enhanced and that defect analysis becomes easier by the direct support of the software-supplier. Although the test has to start with a software product that hasn t the right quality to Sogeti Deutschland GmbH. Version

16 start the acceptance test, the reality showed that the combined system and acceptance test led to a product that was accepted with a minimal risk by the OEM in less time than necessary if both tests were carried out separately. 1.C Combined strategy for high-level tests plus low-level tests or evaluation By involving the low-level tests or the evaluation levels in the coordination, yet more possibilities for optimization are available. The advantages of low-level testing are: they require little communication due to the fact that often the one who detects the defect is both the one who created the defect as well as the one who solves the defect. the tests detect defects in an earlier stage of the system development cycle than the high-level tests. Evaluation compared to testing means detecting more in less time and earlier in the development process. However, not everything can be evaluated, that is why testing remains very important. Expanding the scope of coordination from testing to evaluation provides many extra possibilities for optimizing the effort. Especially nonfunctional quality characteristics such as maintainability, portability, or reliability can often better be evaluated than tested. Involving either evaluation or low-level tests in the total test strategy is profitable to the total test process, because this creates more possibilities to optimize the strategy, i.e. detecting the most important defects as early and as cheap as possible. Checkpoints 1.C.1 1.C.2 1.C.3 1.C.4 1.C.5 1.C.6 Coordination takes place between the high-level tests and the low-level tests or the evaluation levels in the area of test strategy (risks, quality characteristics, area of consideration of the test/evaluation and planning) The result of the coordination is a coordinated strategy, which is documented. During the total (evaluation and) test process this strategy is controlled. Each high-level test determines, on the basis of the coordination, its own test strategy, as described in level A. (if applicable) Each low-level test determines, on the basis of the coordination, its own test strategy, as is described in key area "Low-level testing", level C. (if applicable) Each evaluation level determines, on the basis of the coordination, its own evaluation strategy, as is described in key area "Evaluation", level C. Deviations from the coordinating strategy are reported. A substantiated adjustment of the coordinating strategy is made based on the risks identified for these deviations. Dependencies (if applicable) Low-level testing, level C, Low-level test strategy Low-level tests have to be executed following their own test strategy, which is determined by the coordinating test strategy. Sogeti Deutschland GmbH. Version

17 (if applicable) Evaluation, level C, Evaluation strategy Evaluations have to be executed following their own evaluation strategy, which is determined by the coordinating test strategy. (if applicable) Moment of involvement, level C, Start of requirements definition (if applicable) Integration testing, level B, Test strategy for integration In case integration testing is low-level oriented: this is one of the low-level tests that can be part of the overall test strategy. The total strategy must be determined at an early stage. Improvement suggestions Start communicating the coordinating strategy of the high-level tests with the party responsible for the low-level tests (=developers, most of the time of the supplier) or the evaluations (= often quality assurance of the supplier). This communication will almost always exceed the boundaries of the organization. Find overlap and holes in total coverage between all these tests and evaluations. The commissioner has to decide together with the supplier of the test object which test should be carried out when. The quality of the system (part) to be delivered can be raised if early in the project a prototype car is available to use rapid-prototyping techniques by the supplier. Tests defined in this stage of the project can later be used in the system or acceptance test with the real software and hardware. Find out if it is better that certain high-level tests are performed during low-level tests or evaluation and vice versa. The verification of norms and standards of the software (quality characteristic: maintainability) can for example be part of a test or an evaluation. Example: During the development of an Adaptive-Cruise-Control-System (ACC-system) the tests are mutually coordinated under the responsibility of a test coordinator. The system consists of an ACC-ECU, engine-ecu, ESP-ECU and transmission-ecu, which are developed by four different suppliers. The OEM will integrate the four ECU s and test the integrated system. To be sure that he gets the right quality a risk-based test strategy is carried out with the suppliers. Decided is what the focus should be of the tests carried out by the suppliers. Based on the risk-based test strategy entry and exit criteria are formulated. As part of the entry criteria an entry test is formulated for every ECU. This test is carried out by the OEM and the description of this test is communicated to the suppliers. If the ECU doesn t pass the test it will be sent back to the supplier. The requirements will be described together with the suppliers. The suppliers will break down these requirements into detailed software and hardware specifications. The specifications will be reviewed based on what is described in the risk-based test strategy. In this formal review round the OEM is directly involved. With this approach the OEM minimizes the risk that ECU s are not fit to integrate into an ACC-system and that the integrated system will still contain severe defects. Low-level tests as well as evaluation levels start earlier than high-level tests. In the coordination this has to be taken into account. Combine the inspection of the test basis (see also key area Life cycle model, level B) with evaluation of the specifications. Exchange testware between the different test levels, for example between the acceptance test and unit test. The advantage is that certain tests do not have to be prepared twice. Beware that the tendency can arise not to prepare or execute one's own test so that the testware takes over the role of the specifications ("if the test cases are processed well, the system is built well"). Sogeti Deutschland GmbH. Version

18 1.D Combined strategy for all test and evaluation levels This description is similar to the preceding level C, but now there is coordination between high-level tests, low-level tests and the evaluation levels, to achieve further optimization of the total test and evaluation strategy. Checkpoints 1.D.1 1.D.2 1.D.3 1.D.4 1.D.5 1.D.6 Coordination takes place between the high-level tests, the low-level tests and the evaluation levels in the area of test strategy (risks, quality characteristics, area of consideration of the test/evaluation and planning). The result of the coordination is a coordinating strategy, which is documented. During the total evaluation and test process this strategy is controlled. Each high-level test determines its own test strategy on the basis of the coordination, such as described in level A. Each low-level test determines its own test strategy on the basis of the coordination, such as is described in the key area "Low-level testing", level C. Each evaluation level determines its own evaluation strategy on the basis of the coordination, such as is described in the key area "Evaluation", level C. Deviations from the coordinating strategy are reported. A substantiated adjustment of the coordinating strategy is made based on the risks identified for these deviations. Dependencies Low-level testing, level C, Low-level test strategy Low-level tests have to be executed following their own test strategy, which is determined by the coordinating test strategy. Evaluation, level C, Evaluation strategy Evaluations have to be executed following their own evaluation strategy, which is determined by the coordinating test strategy. Moment of involvement, level C, Start of requirements definition The total strategy should be determined at an early stage. Integration testing, level B, Test strategy for integration. Improvement suggestions Appoint a test/evaluation coordinator (TEC) who coordinates the evaluations and tests and who also continuously monitors this coordination. The TEC reports to the project manager and possibly also to the commissioner. Point of interest is the independence of the TEC. Make the test and evaluation plan an integral part of the (system development-) project plan. If suppliers are working with sub-suppliers test levels and evaluations of the subsuppliers should be considered in the overall test strategy. In this case the same procedures that are implemented between commissioner and supplier can be used between supplier and sub-supplier. The supplier is responsible that the commissioner gets the right information to build an overall test strategy for the complete development process of his desired product. Sogeti Deutschland GmbH. Version

19 Take into consideration the total costs and benefits of testing from development till deployment to make a well thought decision about what risk to test when with an optimal balance between benefits and costs. Sogeti Deutschland GmbH. Version

20 2 LIFE CYCLE MODEL Within the test process a number of phases can be distinguished, such as planning, preparation, design, execution and completion. Each phase consists of a number of activities, of which the aim, the products to be delivered and way to implement the activity are described. A life cycle model makes the test process manageable. It becomes clear who has to do what and when and the different activities can be planned and monitored in cooperation of the parties involved. When this transparency is lacking, activities are executed either too late or are forgotten, activities are running out of time because no insight in activity duration is available. There is no insight in the progress of the testing process and because of this finishing the process in time is almost impossible. Finally, the test process probably stays longer than necessary on the critical path of system development. 2.A Planning, Design, Execution The most important phases in the test process are Planning, Design and Execution. The main activity of the Planning phase is defining a test plan. In a test plan it is defined how, by whom, with what, and when the test activities are to be executed. The main activities of the Design phase are defining the test cases and preparing the test execution. In this context, also the necessary test infrastructure is realized. The aim of the Execution phase is to perform the specified tests to gain insight in the quality of the test object. Checkpoints 2.A.1 2.A.2 For the tests (at least) the following phases are recognized: planning, design and execution. These are subsequently performed, possibly per subsystem. A certain overlap between the phases is allowed. Activities to be performed per phase are mentioned below. Each activity contains sub-activities and/or aspects. These sub-activities and/or aspects are meant as additional information and are not obligatory. For the Planning phase: Activity Sub activities / aspects Product - formulate assignment - determine the test basis - commissioner and supplier - scope - aim - precondition - starting points - Determine relevant documentation; like system requirements, software requirements, software design and other documents that are used to derive test cases - identify documentation - defined in test plan - defined in test plan Sogeti Deutschland GmbH. Version

21 - define scope (area(s) of consideration): what will and what will not be tested - - defined in test plan - determine test strategy for this iteration - strategy determination - estimating - defined in test plan - set up organization - identify test deliverables - define infrastructure and tools - define test management - determine planning (aspects like activities, dependencies, milestones, start & end dates and needed resources) - determine required functions - allocate tasks, authorizations and responsibilities - describe organization - allocate personnel - determine training - determine communication structures - determine reporting lines - determine test products - set up norms and standards - define test environment - define test tools - define office environment - define infrastructure planning - define test process management (progress, quality, reporting) - define infrastructure management - define test product management - define defects procedure - defined in test plan - defined in test plan - defined in test plan - defined in test plan - define general planning - defined in test plan Sogeti Deutschland GmbH. Version

Advantages and Disadvantages of. Independent Tests. Advantages. Disadvantages

Advantages and Disadvantages of. Independent Tests. Advantages. Disadvantages 8.0 Test Management Outline 8.1 Test organisation 8.2 Test planning and estimation 8.3 Test program monitoring and control 8.4 Configuration management 8.5 Risk and testing 8.6 Summary Independent Testing

More information

ISTQB Sample Question Paper Dump #11

ISTQB Sample Question Paper Dump #11 ISTQB Sample Question Paper Dump #11 1. Which of the following is true a. Testing is the same as quality assurance b. Testing is a part of quality assurance c. Testing is not a part of quality assurance

More information

Software System Integration. Chapter 8 Software testing 1

Software System Integration. Chapter 8 Software testing 1 Software System Integration Chapter 8 Software testing 1 Overview What is system integration? Integration process description Integration testing System Integration Checklist Chapter 8 Software testing

More information

AUTOMOTIVE SPICE v3.1 POCKET GUIDE

AUTOMOTIVE SPICE v3.1 POCKET GUIDE EXTENDED VDA SCOPE ASPICE v3.1 AUTOMOTIVE SPICE v3.1 POCKET GUIDE 4 5 6 7 8-9 10 11-13 14-15 16-19 20-43 44-49 50-51 52-69 70-93 94-103 104-105 106 Automotive SPICE at a glance Automotive SPICE application

More information

7. Model based software architecture

7. Model based software architecture UNIT - III Model based software architectures: A Management perspective and technical perspective. Work Flows of the process: Software process workflows, Iteration workflows. Check Points of The process

More information

Testing. CxOne Standard

Testing. CxOne Standard Testing CxOne Standard CxStand_Testing.doc November 3, 2002 Advancing the Art and Science of Commercial Software Engineering Contents 1 INTRODUCTION... 1 1.1 OVERVIEW... 1 1.2 GOALS... 1 1.3 BACKGROUND...

More information

SWE 211 Software Processes

SWE 211 Software Processes SWE 211 Software Processes These slides are designed and adapted from slides provided by Software Engineering 9 /e Addison Wesley 2011 by Ian Sommerville 1 Outlines Software process models Process activities

More information

Test Process Improvement using TMM(i)

Test Process Improvement using TMM(i) Test Process Improvement using TMM(i) Erik van Veenendaal, Richard Grooff and Rob Hendriks Improve Quality Services BV Introduction More and more organisation are trying to improve their software development

More information

BASICS OF SOFTWARE TESTING AND QUALITY ASSURANCE. Yvonne Enselman, CTAL

BASICS OF SOFTWARE TESTING AND QUALITY ASSURANCE. Yvonne Enselman, CTAL BASICS OF SOFTWARE TESTING AND QUALITY ASSURANCE Yvonne Enselman, CTAL Information alines with ISTQB Sylabus and Glossary THE TEST PYRAMID Why Testing is necessary What is Testing Seven Testing principles

More information

Seminar 06 Chapter 5 - Part 1

Seminar 06 Chapter 5 - Part 1 INF 3121 Software Testing Seminar 06 Chapter 5 - Part 1 1. Part 1: Closed-ended questions 2. Part 2: Exercises and open-ended questions 1 Part 1: Closed-ended questions 2 Question 1 Why is independent

More information

Work Plan and IV&V Methodology

Work Plan and IV&V Methodology Work Plan and IV&V Methodology Technology initiatives and programs should engage with an IV&V process at the project planning phase in order to receive an unbiased, impartial view into the project planning,

More information

INF 3121 Software Testing - Lecture 05. Test Management

INF 3121 Software Testing - Lecture 05. Test Management INF 3121 Software Testing - Lecture 05 Test Management 1. Test organization (20 min) (25 min) (15 min) (10 min) (10 min) (10 min) INF3121 / 23.02.2016 / Raluca Florea 1 1. Test organization (20 min) LO:

More information

ISO : Rustam Rakhimov (DMS Lab)

ISO : Rustam Rakhimov (DMS Lab) ISO 26262 : 2011 Rustam Rakhimov (DMS Lab) Introduction Adaptation of IEC 61508 to road vehicles Influenced by ISO 16949 Quality Management System The first comprehensive standard that addresses safety

More information

Summary of TL 9000 R4.0 Requirements Beyond ISO 9001:2000

Summary of TL 9000 R4.0 Requirements Beyond ISO 9001:2000 This summary identifies the additional TL 9000 Release 4.0 requirements beyond those stated in ISO 9001:2000. See the TL 9000 R4.0 Handbook for the actual TL 9000 R4.0 requirements. ISO 9001:2000 section

More information

Testing 2. Testing: Agenda. for Systems Validation. Testing for Systems Validation CONCEPT HEIDELBERG

Testing 2. Testing: Agenda. for Systems Validation. Testing for Systems Validation CONCEPT HEIDELBERG CONCEPT HEIDELBERG GMP Compliance for January 16-17, 2003 at Istanbul, Turkey Testing for Systems Validation Dr.-Ing. Guenter Generlich guenter@generlich.de Testing 1 Testing: Agenda Techniques Principles

More information

Lectures 2 & 3. Software Processes. Software Engineering, COMP201 Slide 1

Lectures 2 & 3. Software Processes. Software Engineering, COMP201 Slide 1 Lectures 2 & 3 Software Processes Software Engineering, COMP201 Slide 1 What is a Process? When we provide a service or create a product we always follow a sequence of steps to accomplish a set of tasks

More information

JDI Quality Assurance Guideline

JDI Quality Assurance Guideline JDI Quality Assurance Guideline For Supplier, 2017 Japan Display Inc. 7/1/2017 - Table of Contents - 1. Introduction... - 7-1.1. Purpose of this Guideline...- 8-1.2. Structure of this Guideline...- 8-1.3.

More information

Next Generation Design and Verification Today Requirements-driven Verification Methodology (for Standards Compliance)

Next Generation Design and Verification Today Requirements-driven Verification Methodology (for Standards Compliance) Next Generation Design and Verification Today Requirements-driven Verification Methodology (for Standards Compliance) Mike Bartley, TVS Agenda Motivation - Why Requirements Driven Verification? Introduction

More information

Test Maturity Assessment and Improvement Using TPI and Quality Blueprint. Performance driven. Quality assured.

Test Maturity Assessment and Improvement Using TPI and Quality Blueprint. Performance driven. Quality assured. Test Maturity Assessment and Improvement Using TPI and Quality Blueprint Performance driven. Quality assured. Testing the way we do it Benchmark, Blueprint, and Execute to Build a World-Class Test Organization

More information

Intermediate Certificate in Software Testing Syllabus. Version 1.4

Intermediate Certificate in Software Testing Syllabus. Version 1.4 Intermediate Certificate in Software Testing Syllabus February 2010 Background This document is the syllabus for the intermediate paper which leads to the practitioner level of qualification, as administered

More information

Introduction to Software Engineering

Introduction to Software Engineering Introduction to Software Engineering 2. Requirements Collection Mircea F. Lungu Based on a lecture by Oscar Nierstrasz. Roadmap > The Requirements Engineering Process > Functional and non-functional requirements

More information

Integration and Testing

Integration and Testing Integration and Testing 1 Today Software Quality Assurance Integration Test planning Types of testing Test metrics Test tools 2 Deliverables by Phase Possible Deliverables by Phase Concept Document Statement

More information

Balanced Scorecard IT Strategy and Project Management

Balanced Scorecard IT Strategy and Project Management Balanced Scorecard IT Strategy and Project Management Managing Strategy is is Managing Change Glen B. Alleman Director, Program Management Office Kaiser Hill Company, LLC Rocky Flats Environmental Technology

More information

Risk Based Testing. -Why we need RBT? -Types of risks -Managing risks -Methods of evaluation & risk analysis -Costs and benefits

Risk Based Testing. -Why we need RBT? -Types of risks -Managing risks -Methods of evaluation & risk analysis -Costs and benefits Risk Based Testing -Why we need RBT? -Types of risks -Managing risks -Methods of evaluation & risk analysis -Costs and benefits Ladislau Szilagyi www.euroqst.ro Definitions (ISTQB glossary) Risk = a factor

More information

Quality management systems

Quality management systems L E C T U R E 9 Quality management systems LECTURE 9 - OVERVIEW Quality management system based on ISO 9000 WHAT IS QMS (QUALITY MANAGEMENT SYSTEM) Goal: Meet customer needs Quality management system includes

More information

Now, I wish you lots of pleasure while reading this report. In case of questions or remarks please contact me at:

Now, I wish you lots of pleasure while reading this report. In case of questions or remarks please contact me at: Preface Somewhere towards the end of the second millennium the director of Vision Consort bv, Hans Brands, came up with the idea to do research in the field of embedded software architectures. He was particularly

More information

Quality Assurance Plan D9.1.1

Quality Assurance Plan D9.1.1 Quality Assurance Plan D9.1.1 Deliverable Number: D9.1.1 Contractual Date of Delivery: month 3 Actual Date of Delivery: 27/07/2001 Title of Deliverable: Quality Assurance Plan Work-Package contributing

More information

TPI NEXT. 10 February /14/2011. Agenda. Geert Vanhove. What is TPI NEXT? The new model. How to apply the new model. TPI NEXT Sogeti services

TPI NEXT. 10 February /14/2011. Agenda. Geert Vanhove. What is TPI NEXT? The new model. How to apply the new model. TPI NEXT Sogeti services TPI NEXT 10 February 2011 KVIV - Antwerp Geert Vanhove Agenda What is TPI NEXT? The new model How to apply the new model TPI NEXT Sogeti services Tool demo Q&A 1 Need for improvement Testing is generally

More information

Volume 8, No. 1, Jan-Feb 2017 International Journal of Advanced Research in Computer Science RESEARCH PAPER Available Online at

Volume 8, No. 1, Jan-Feb 2017 International Journal of Advanced Research in Computer Science RESEARCH PAPER Available Online at Volume 8, No. 1, Jan-Feb 2017 International Journal of Advanced Research in Computer Science RESEARCH PAPER Available Online at www.ijarcs.info A Study of Software Development Life Cycle Process Models

More information

Risk-Based Testing: Analysis and Strategy. Presented at Quality Assurance Institute QUEST Conference Chicago, Ill., 2009

Risk-Based Testing: Analysis and Strategy. Presented at Quality Assurance Institute QUEST Conference Chicago, Ill., 2009 Risk-Based Testing: Analysis and Strategy Presented at Quality Assurance Institute QUEST Conference Chicago, Ill., 2009 Clyneice Chaney, CMQ/OE, PMP April 21, 2009 Workshop Outline Part I Risk Management

More information

What are requirements? Basics of Requirement Engineering. Definition of a Stakeholder. Stated Vs. Real Requirements. Stated Vs.

What are requirements? Basics of Requirement Engineering. Definition of a Stakeholder. Stated Vs. Real Requirements. Stated Vs. What are requirements? Basics of Requirement Engineering Muzaffar Iqbal Farooqi A requirement is a necessary attribute in a system, a statement that identifies a capability, characteristic, or quality

More information

Compliance driven Integrated circuit development based on ISO26262

Compliance driven Integrated circuit development based on ISO26262 Compliance driven Integrated circuit development based on ISO26262 Haridas Vilakathara Manikantan panchapakesan NXP Semiconductors, Bangalore Accellera Systems Initiative 1 Outline Functional safety basic

More information

Software Sustainment of Mission-Critical Systems: Wringing Value out of Legacy Assets. IEEE STC March 29 April 3, 2014

Software Sustainment of Mission-Critical Systems: Wringing Value out of Legacy Assets. IEEE STC March 29 April 3, 2014 Software Sustainment of Mission-Critical Systems: Wringing Value out of Legacy Assets IEEE STC March 29 April 3, 2014 0 Wringing Value out of Legacy Code Legacy systems tempt both acquisition and development

More information

National Aeronautics and Space Administration Washington, DC 20546

National Aeronautics and Space Administration Washington, DC 20546 Technical Standards Division Publication NASA-STD-2100-91 NASA Software Documentation Standard Software Engineering Program NASA-STD-2100-91 -91 Approved: July 29, 1991 National Aeronautics and Space Administration

More information

Component-based Development Process and Component Lifecycle

Component-based Development Process and Component Lifecycle -based Process and Lifecycle Ivica Crnkovic 1, Michel Chaudron 2, Stig Larsson 3 1 Mälardalen University, Department of Computer Science and Electronics, Sweden 2 Eindhoven University of Technology, Dept.

More information

WORK PLAN AND IV&V METHODOLOGY Information Technology - Independent Verification and Validation RFP No IVV-B

WORK PLAN AND IV&V METHODOLOGY Information Technology - Independent Verification and Validation RFP No IVV-B 1. Work Plan & IV&V Methodology 1.1 Compass Solutions IV&V Approach The Compass Solutions Independent Verification and Validation approach is based on the Enterprise Performance Life Cycle (EPLC) framework

More information

Pertemuan 2. Software Engineering: The Process

Pertemuan 2. Software Engineering: The Process Pertemuan 2 Software Engineering: The Process Collect Your Project Topic What is Software Engineering? Software engineering is the establishment and sound engineering principles in order to obtain economically

More information

A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0 Skillport

A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0 Skillport A Guide to the Business Analysis Body of Knowledge (BABOK Guide), Version 2.0 by The International Institute of Business Analysis (IIBA) International Institute of Business Analysis. (c) 2009. Copying

More information

Development of AUTOSAR Software Components with Model-Based Design

Development of AUTOSAR Software Components with Model-Based Design Development of AUTOSAR Software Components with Model-Based Design Guido Sandmann Automotive Marketing Manager, EMEA The MathWorks Joachim Schlosser Senior Team Leader Application Engineering The MathWorks

More information

Guidelines for Testing Maturity

Guidelines for Testing Maturity Guidelines for Testing Maturity Erik van Veenendaal of Improve Quality Services BV in the Netherlands has both involved in test process improvement projects at a large number of industrial organizations.

More information

Project Plan. CxOne Guide

Project Plan. CxOne Guide Project Plan CxOne Guide CxGuide_ProjectPlan.doc November 5, 2002 Advancing the Art and Science of Commercial Software Engineering Contents 1 INTRODUCTION... 1 1.1 DELIVERABLE PURPOSE... 1 1.2 LIFECYCLE...

More information

7. What is planning? It is an act of formulating a program for a definite course of action. Planning is to decide what is to be done.

7. What is planning? It is an act of formulating a program for a definite course of action. Planning is to decide what is to be done. UNIT I FUNDAMENTALS 2 MARKS QUESTIONS & ANSWERS 1. What is software project management? Software project management is the art and science of planning and leading software projects. It is sub discipline

More information

Your Checklist Guide for Effortless Crane Hire

Your Checklist Guide for Effortless Crane Hire Your Checklist Guide for Effortless Crane Hire (Plus Frequently Asked Questions) There are 6 key Processes that can make your Crane Hire experience effortless if we work together to manage them efficiently:

More information

Requirements Analysis and Design Definition. Chapter Study Group Learning Materials

Requirements Analysis and Design Definition. Chapter Study Group Learning Materials Requirements Analysis and Design Definition Chapter Study Group Learning Materials 2015, International Institute of Business Analysis (IIBA ). Permission is granted to IIBA Chapters to use and modify this

More information

On the management of nonfunctional requirements

On the management of nonfunctional requirements - modulo B On the management of nonfunctional requirements Dr Tullio Vardanega European Space Research and Technology Centre and University of Padua TU Delft, 12 November 2001 Outline of the talk What

More information

ISTQB CTFL BH QuestionsAnswers with Explanation

ISTQB CTFL BH QuestionsAnswers with Explanation ISTQB CTFL BH0-10 - QuestionsAnswers with Explanation For Software Testing Articles Visit @ http://softwaretestinghelp.com Join the Best Software Testing Training Course @ http://softwaretestinghelp.org

More information

PMBOK Guide Fifth Edition Pre Release Version October 10, 2012

PMBOK Guide Fifth Edition Pre Release Version October 10, 2012 5.3.1 Define Scope: Inputs PMBOK Guide Fifth Edition 5.3.1.1 Scope Management Plan Described in Section 5.1.3.1.The scope management plan is a component of the project management plan that establishes

More information

Erol Simsek, isystem. Qualification of a Software Tool According to ISO /6

Erol Simsek, isystem. Qualification of a Software Tool According to ISO /6 Qualification of a Software Development Tool According to ISO26262 Tool Qualification for the New Automotive Standard from a Tool Manufacturer s Perspective Erol Simsek, isystem Summary Chapter 8-11 of

More information

Application of an Agile Development Process for EN50128/railway conformant

Application of an Agile Development Process for EN50128/railway conformant Application of an Agile Development Process for EN50128/railway conformant Software T. Myklebust SINTEF ICT, Trondheim, Norway T. Stålhane NTNU, Trondheim, Norway N. Lyngby SINTEF ICT, Trondheim, Norway

More information

Fundamentals of Requirements Engineering

Fundamentals of Requirements Engineering - interfaces system seen as black box inputs functions quantified characteristics outputs restrictions, prerequisites boundaries, exceptions standards, regulations Frogs vei 41 P.O. Box 235, NO-3603 Kongsberg

More information

PMP Exam Preparation Course Project Scope Management

PMP Exam Preparation Course Project Scope Management Project Scope Management 1 Product Scope Product scope The features and functions that are to be included in your products or service or result of the project. Completion is measured against the product

More information

UPGRADE CONSIDERATIONS Appian Platform

UPGRADE CONSIDERATIONS Appian Platform UPGRADE CONSIDERATIONS Appian Platform ArchiTECH Solutions LLC 7700 Leesburg Pike #204 www.architechsolutions.com 703-972-9155 atsdelivery@architechsolutions.com TABLE OF CONTENTS Introduction... 3 Upgrade

More information

Project Summary. Acceptanstest av säkerhetskritisk plattformsprogramvara

Project Summary. Acceptanstest av säkerhetskritisk plattformsprogramvara Project Summary Acceptanstest av säkerhetskritisk plattformsprogramvara 2 AcSäPt Acceptanstest av säkerhetskritisk plattformsprogramvara The Project In this report we summarise the results of the FFI-project

More information

Subject : Computer Science. Paper : Software Quality Management. Module : Quality Management Activities Module No: CS/SQM/15

Subject : Computer Science. Paper : Software Quality Management. Module : Quality Management Activities Module No: CS/SQM/15 e-pg Pathshala Subject : Computer Science Paper : Software Quality Management Module : Quality Management Activities Module No: CS/SQM/15 Quadrant 1 : e-text QUALITY MANAGEMENT ACTIVITIES Software quality

More information

Functional Safety: ISO26262

Functional Safety: ISO26262 Functional Safety: ISO26262 Seminar Paper Embedded systems group Aniket Kolhapurkar, University of Kaiserslautern, Germany kolhapur@rhrk.uni kl.de September 8, 2015 1 Abstract Functions in car, such as

More information

Object-Oriented and Classical Software Engineering

Object-Oriented and Classical Software Engineering Slide 3.1 Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2007 Stephen R. Schach srs@vuse.vanderbilt.edu CHAPTER 3 Slide 3.2 THE SOFTWARE PROCESS Overview Slide 3.3

More information

3 PART THREE: WORK PLAN AND IV&V METHODOLOGY (SECTION 5.3.3)

3 PART THREE: WORK PLAN AND IV&V METHODOLOGY (SECTION 5.3.3) 3 PART THREE: WORK PLAN AND IV&V METHODOLOGY (SECTION 5.3.3) Emagine IT s approach to Independent Verification and Validation (IV&V) has been shaped over the years by hands-on experience and contributions

More information

Introduction to software testing and quality process

Introduction to software testing and quality process Introduction to software testing and quality process Automated testing and verification J.P. Galeotti - Alessandra Gorla Engineering processes Engineering disciplines pair construction activities activities

More information

This tutorial also elaborates on other related methodologies like Agile, RAD and Prototyping.

This tutorial also elaborates on other related methodologies like Agile, RAD and Prototyping. i About the Tutorial SDLC stands for Software Development Life Cycle. SDLC is a process that consists of a series of planned activities to develop or alter the Software Products. This tutorial will give

More information

Introduction to Software Engineering

Introduction to Software Engineering UNIT I SOFTWARE PROCESS Introduction S/W Engineering Paradigm life cycle models (water fall, incremental, spiral, WINWIN spiral, evolutionary, prototyping, objects oriented) -system engineering computer

More information

Copyright Software Engineering Competence Center

Copyright Software Engineering Competence Center Copyright Software Engineering Competence Center 2012 1 Copyright Software Engineering Competence Center 2012 5 These are mapped categories to the waste categories of manufacturing. An excellent overview

More information

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2

BCS THE CHARTERED INSTITUTE FOR IT. BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT SOFTWARE ENGINEERING 2 Friday 30 th September 2016 - Morning Answer any THREE questions

More information

Cost of Changing the Activities in SDLC. Minimum of Cost at this level. code debuging unit test integration. Activity

Cost of Changing the Activities in SDLC. Minimum of Cost at this level. code debuging unit test integration. Activity Software Development Life Cycle (SDLC) This is a work flow for creating a new software/application. Usually, any company that is in the software business follows the same route and structure. In this document

More information

Agile Test Plan How to Construct an Agile Test Plan

Agile Test Plan How to Construct an Agile Test Plan Agile Test Plan How to Construct an Agile Test Plan XBOSoft White Paper How to Construct an Agile Test Plan www.xbosoft.com 2 Agile is changing not only the way we develop software but the way we work

More information

Digital Industries Apprenticeship: Occupational Brief. Software Tester. March 2016

Digital Industries Apprenticeship: Occupational Brief. Software Tester. March 2016 Digital Industries Apprenticeship: Occupational Brief Software Tester March 2016 1 Digital Industries Apprenticeships: Occupational Brief Level 4 Software Tester Apprenticeship Minimum Standards and Grading

More information

Functional Safety with ISO Principles and Practice Dr. Christof Ebert, Dr. Arnulf Braatz Vector Consulting Services

Functional Safety with ISO Principles and Practice Dr. Christof Ebert, Dr. Arnulf Braatz Vector Consulting Services Functional Safety with ISO 26262 Principles and Practice Dr. Christof Ebert, Dr. Arnulf Braatz Vector Consulting Services Content Challenges with Implementing Functional Safety Basic Concepts Vector Experiences

More information

7.11b: Quality in Project Management: A Comparison of PRINCE2 Against PMBOK

7.11b: Quality in Project Management: A Comparison of PRINCE2 Against PMBOK by Peter Whitelaw, Rational Management Pty Ltd, Melbourne Introduction This comparison takes each part of the PMBOK and provides comments on what match there is with elements of the PRINCE2 method. It's

More information

TECHNICAL REVIEWS AND AUDITS

TECHNICAL REVIEWS AND AUDITS Chapter 11 Technical Reviews and Audits CHAPTER 11 TECHNICAL REVIEWS AND AUDITS 11.1 PROGRESS MEASUREMENT The Systems Engineer measures design progress and maturity by assessing its development at key

More information

Product Inspection. Compliance Expertise Performance Uptime. Product Inspection Services Maximizing Productivity

Product Inspection. Compliance Expertise Performance Uptime. Product Inspection Services Maximizing Productivity Product Inspection Compliance Expertise Performance Uptime Product Inspection Services Maximizing Productivity Product Inspection Service Consulting and Business Support Aligning Our Expertise with Your

More information

Object-Oriented and Classical Software Engineering THE SOFTWARE PROCESS 9/17/2017. CHAPTER 3 Slide 3.2. Stephen R. Schach. Overview Slide 3.

Object-Oriented and Classical Software Engineering THE SOFTWARE PROCESS 9/17/2017. CHAPTER 3 Slide 3.2. Stephen R. Schach. Overview Slide 3. Slide 3.1 CHAPTER 3 Slide 3.2 Object-Oriented and Classical Software Engineering THE SOFTWARE PROCESS Eighth Edition, WCB/McGraw-Hill, 2011 Stephen R. Schach Overview Slide 3.3 Overview (contd) Slide 3.4

More information

Errata 1 st Printing. Errata 2 nd Printing

Errata 1 st Printing. Errata 2 nd Printing Errata 1 st Printing NOTE: The following errata only pertain to the first printing of the PMBOK Guide Fifth Edition. In order to verify the print run of your book (or PDF), refer to the bottom of the copyright

More information

9. Verification, Validation, Testing

9. Verification, Validation, Testing 9. Verification, Validation, Testing (a) Basic Notions (b) Dynamic testing. (c) Static analysis. (d) Modelling. (e) Environmental Simulation. (f) Test Strategies. (g) Tool support. (h) Independent Verification

More information

Software System Integration. Chapter 8 Software testing 1

Software System Integration. Chapter 8 Software testing 1 Software System Integration Chapter 8 Software testing 1 Overview What is system integration? Integration process description Integration testing System Integration Checklist Chapter 8 Software testing

More information

TUNNEL TECHNICAL INSTALLATION TESTING ASSURES DEMONSTRABLE TUNNEL SAFETY

TUNNEL TECHNICAL INSTALLATION TESTING ASSURES DEMONSTRABLE TUNNEL SAFETY - 101 - TUNNEL TECHNICAL INSTALLATION TESTING ASSURES DEMONSTRABLE TUNNEL SAFETY Boersen P.AM., Sogeti Nederland B.V., Netherlands ABSTRACT A tunnel technical installation of a road tunnel is mainly a

More information

Software Engineering

Software Engineering Software Engineering Lecture 02: Processes Peter Thiemann University of Freiburg, Germany SS 2013 Peter Thiemann (Univ. Freiburg) Software Engineering SWT 1 / 41 Terms Software Component SW System Organized

More information

Challenges of Managing a Testing Project: (A White Paper)

Challenges of Managing a Testing Project: (A White Paper) Challenges of Managing a Testing Project: () Page 1 of 20 Vinod Kumar Suvarna Introduction Testing is expected to consume 30 50 % of the Project Effort, Still properly managing testing project is not considered

More information

Identifying Types of Extra-Functional Requirements in the Context of Business Process Support Systems

Identifying Types of Extra-Functional Requirements in the Context of Business Process Support Systems Identifying Types of Extra-Functional Requirements in the Context of Business Process Support Systems Elke Hochmüller 1, Michael Dobrovnik 2 1 Carinthia Tech Institute, Department of Telematics / Network

More information

This resource is associated with the following paper: Assessing the maturity of software testing services using CMMI-SVC: an industrial case study

This resource is associated with the following paper: Assessing the maturity of software testing services using CMMI-SVC: an industrial case study RESOURCE: MATURITY LEVELS OF THE CUSTOMIZED CMMI-SVC FOR TESTING SERVICES AND THEIR PROCESS AREAS This resource is associated with the following paper: Assessing the maturity of software testing services

More information

Measurement Tailoring Workshops

Measurement Tailoring Workshops Measurement Tailoring Workshops Introduction The Director of Information Systems for Command, Control, Communications, and Computers (DISC4) policy memorandum of 19 September 1996, reference (a), eliminated

More information

Product Documentation SAP Business ByDesign February Business Configuration

Product Documentation SAP Business ByDesign February Business Configuration Product Documentation PUBLIC Business Configuration Table Of Contents 1 Business Configuration.... 4 2 Business Background... 5 2.1 Configuring Your SAP Solution... 5 2.2 Watermark... 7 2.3 Scoping...

More information

Chapter 2: The Project Management and Information Technology Context

Chapter 2: The Project Management and Information Technology Context Chapter 2: The Project Management and Information Technology Context TRUE/FALSE 1. Many of the theories and concepts of project management are difficult to understand. F PTS: 1 REF: 44 2. If project managers

More information

Software Development Life Cycle:

Software Development Life Cycle: Software Development Life Cycle: The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software

More information

Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1

Software Processes. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Software Processes Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Objectives To introduce software process models To describe three generic process models and when they may be

More information

Number: DI-IPSC-81427B Approval Date:

Number: DI-IPSC-81427B Approval Date: DATA ITEM DESCRIPTION Title: Software Development Plan (SDP) Number: DI-IPSC-81427B Approval Date: 20170313 AMSC Number: N9775 Limitation: N/A DTIC Applicable: No GIDEP Applicable: No Preparing Activity:

More information

Fiat Group Automobiles Policy for Software Quality Improvement

Fiat Group Automobiles Policy for Software Quality Improvement Fiat Group Automobiles Policy for Software Quality Improvement 2010-01-2329 Published 10/19/2010 Edoardo Sivera Fiat Group Automobiles (FGA) Copyright 2010 SAE International ABSTRACT Automotive systems

More information

Key Attributes and Responsibilities of a Test Manager

Key Attributes and Responsibilities of a Test Manager Key Attributes and Responsibilities of a Test Manager Chris Comey SIGIST December 2015 The Test Managers World Standard Test Management Activities Contextual Test Management Activities Test strategy &

More information

TAMING COMPLEXITY ON MAJOR RAIL PROJECTS WITH A COLLABORATIVE SYSTEMS ENGINEERING APPROACH

TAMING COMPLEXITY ON MAJOR RAIL PROJECTS WITH A COLLABORATIVE SYSTEMS ENGINEERING APPROACH TAMING COMPLEXITY ON MAJOR RAIL PROJECTS WITH A COLLABORATIVE SYSTEMS ENGINEERING APPROACH Chris Rolison CEO, Comply Serve Limited The Collaborative Systems Engineering Approach Collaboration A system

More information

Solutions Manual. Object-Oriented Software Engineering. An Agile Unified Methodology. David Kung

Solutions Manual. Object-Oriented Software Engineering. An Agile Unified Methodology. David Kung 2 David Kung Object-Oriented Software Engineering An Agile Unified Methodology Solutions Manual 3 Message to Instructors July 10, 2013 The solutions provided in this manual may not be complete, or 100%

More information

Information Systems Development

Information Systems Development Information Systems Development Based on Chapter 3 of Whitten, Bentley, and Dittman: Systems Analysis and Design for the Global Enterprise (7th Ed). McGraw Hill. 2007 Wei-Tsong Wang 1 IIM, NCKU 3 Objectives

More information

Passit4Sure.OG Questions. TOGAF 9 Combined Part 1 and Part 2

Passit4Sure.OG Questions. TOGAF 9 Combined Part 1 and Part 2 Passit4Sure.OG0-093.221Questions Number: OG0-093 Passing Score: 800 Time Limit: 120 min File Version: 7.1 TOGAF 9 Combined Part 1 and Part 2 One of the great thing about pass4sure is that is saves our

More information

CHALLENGES (BARRIERS) IN ADOPTING THE ELECTRONIC COMMERCE SYSTEM IN LIC OF INDIA

CHALLENGES (BARRIERS) IN ADOPTING THE ELECTRONIC COMMERCE SYSTEM IN LIC OF INDIA CHAPTER-6 CHALLENGES (BARRIERS) IN ADOPTING THE ELECTRONIC COMMERCE SYSTEM IN LIC OF INDIA 6.1 Introduction : e-insurance is the application of Internet and related technologies to the production and distribution

More information

REQUIREMENT DRIVEN TESTING. Test Strategy for. Project name. Prepared by <author name> [Pick the date]

REQUIREMENT DRIVEN TESTING. Test Strategy for. Project name. Prepared by <author name> [Pick the date] REQUIREMENT DRIVEN TESTING Test Strategy for Project name Prepared by [Pick the date] [Type the abstract of the document here. The abstract is typically a short summary of the contents of

More information

developer.* The Independent Magazine for Software Professionals Automating Software Development Processes by Tim Kitchens

developer.* The Independent Magazine for Software Professionals Automating Software Development Processes by Tim Kitchens developer.* The Independent Magazine for Software Professionals Automating Software Development Processes by Tim Kitchens Automating repetitive procedures can provide real value to software development

More information

Business Process Oriented Requirements Engineering Process

Business Process Oriented Requirements Engineering Process Process Oriented Requirements Engineering Process Tomoyuki Arao, Eiji Goto, Tomoko Nagata Nomura Research Institute, Ltd. tarao@alumni.cmu.edu, e-gotou@nri.co.jp, t-nagata@nri.co.jp Abstract Although requirements

More information

Research on software systems dependability at the OECD Halden Reactor Project

Research on software systems dependability at the OECD Halden Reactor Project Research on software systems dependability at the OECD Halden Reactor Project SIVERTSEN Terje 1, and ØWRE Fridtjov 2 1. Institute for Energy Technology, OECD Halden Reactor Project, Post Box 173, NO-1751

More information

GAIA. GAIA Software Product Assurance Requirements for Subcontractors. Name and Function Date Signature 15/09/05 15/09/05 15/09/05 15/09/05 15/09/05

GAIA. GAIA Software Product Assurance Requirements for Subcontractors. Name and Function Date Signature 15/09/05 15/09/05 15/09/05 15/09/05 15/09/05 Title Page : i Software Product Assurance Requirements for Subcontractors Name and Function Date Signature Prepared by D.MUNCH Prime Contractor SPA Manager 15/09/05 Verified by D.PERKINS E-SVM PA Manager

More information

NCOVER. ROI Analysis for. Using NCover. NCover P.O. Box 9298 Greenville, SC T F

NCOVER. ROI Analysis for. Using NCover. NCover P.O. Box 9298 Greenville, SC T F NCOVER ROI Analysis for Test Coverage Using NCover NCover P.O. Box 9298 Greenville, SC 29601 T 864.990.3717 F 864.341.8312 conversation@ncover.com www.ncover.com Table of Contents Executive Summary 2 Cost

More information

SOA Governance is For Life, Not Just a Strategy

SOA Governance is For Life, Not Just a Strategy SOA Governance is For Life, Not Just a Strategy Mark Simpson Consultancy Director, Griffiths Waite Your Speaker Mark Simpson Consultancy Director Griffiths Waite > 18 years Oracle development and architecture

More information

Software Testing Life Cycle

Software Testing Life Cycle Software Testing Life Cycle STLC (Software Testing Life Cycle) is an integral component of SDLC (Software Development Life Cycle). Testing has become a distinct phenomenon during and after the development

More information

Systems Engineering Concept

Systems Engineering Concept Systems Engineering Concept WHITE PAPER February 2017 The Systems Engineering Concept provides practical hands-on methods and tools, that enable companies to meet today s global business challenges through

More information