Distributed Engineered Test Efficiency Improvement

(1)

Distributed Engineered

Test Efficiency

Improvement

Boosting Test Automation with a Managed Testing Service Approach

SQS – the world’s leading specialist in software quality

Authors: Heinrich Grefe, Commercial Director Bert Kleinikel, Junior Delivery Manager Christian Marx, Head of Test Centre Görlitz SQS Software Quality Systems AG Germany

Published: August 2013

(2)

HEINRICH GREFE

Commercial Director [email protected]

Heinrich Grefe studied economy and media computer science. He works at SQS Software Quality Systems AG as a Commercial Director. He is an accredited Principal Assessor and Appraiser in the environ-ment of SPICE and CMMI, and a Quality Assurance Manageenviron-ment Professional. Since January 2003 Heinrich Grefe has had complete responsibility for selected customer accounts and is responsible from the stage of acquisition to the provision of, and acceptance of, services. He joined SQS in 2000.

BERT KlEINIKEl

Junior Delivery Manager [email protected]

Bert Kleinikel has been with SQS since 2008. In this time he has worked on various client projects in the telecommunications, insurance, networking service provider/social networking and civil service sectors. His role involved test preparation and design, and controlling and coordination of small teams at the Görlitz Test Centre. In January 2012 Bert Kleinikel took up the position of Junior Delivery Manager. In this function he supports delivery/project management onsite and is responsible for delivery/project management offsite.

CHRISTIAN MARx

Head of Test Centre Görlitz [email protected]

Christian Marx studied mathematics and started working in consultancy in 1989. Thus he has a long experience mainly in software enginee-ring, project management, quality- and test management. Due to his manifold project assignments he has special expertise in different business domains, especially in the public sector and industrial manu-facturing (automotive and steel production). He joined SQS in 2007 and since October 2011 he has been Head of Test Centre Görlitz, Germany.

(3)

For over 30 years now, SQS AG has been a re-cognised partner for software testing and quality management to its clients. As of 2012, the number of successful projects was in the 5,000s and this number is steadily growing. The IT market as a whole has seen major changes in terms of service orientation and outsourcing in recent years. Accor-dingly, the testing market has been evolving, and testing services have emerged in SQS’ portfolio in order to meet the clients’ need to transfer more re-sponsibility for testing tasks to SQS so that clients can focus on their core businesses.

In particular, SQS offers ‘Managed Testing Services’ to leverage mutual benefits in terms of pricing, scalability and efficiency of testing. In a managed service setting, SQS takes over full responsibility for testing tasks from its clients and typically delivers results on the basis of a transactional pricing model at competitive rates. Consequently, as a service provider of Managed Testing Services SQS can leverage further advantages – e.g. effective and ef-ficient resource and capability management, or the optimisation and automation of testing to increase efficiency and reduce the duration of test cycles. The service provider’s benefits can be shared with its clients and provide them with a stable, reliable testing service based on a clearly defined pricing model that can be deployed flexibly.

Clearly, Managed Testing Services may not be suit-able in each and every context, and they do come with prerequisites – but experience shows that many of the popular concerns can be mitigated and Managed Testing Services can be applied in a host of different environments with great success. The transformation of time & material testing projects into transaction-based Managed Testing Services is one of the most essential steps towards Managed Testing Services and requires a clearly defined scope. The present whitepaper reports on a Managed Tes- ting Services project that was started in order to increase test efficiency with uncompromised test coverage for a client who formerly worked on a time & material model. It shows how improvement projects can be implemented as Managed Testing Services and achieve tremendous results with regard to time to market for business software releases while kee-ping the highest level of quality and coverage of the test assets, and consequently boosting efficiency in testing.

(5)

2.1. Managed Testing Services

According to SQS and the market (Simon & Simon, 2012), Managed Testing Services are typically de-fined as follows:

Managed Testing Services (MTS) are mana-ged services for testing-related tasks across one or more projects delivering one or more applications and systems, spanning the life cycle of software and system development and system operation. The resources for testing (staff, testing infrastructure, system under test) are managed by and under the respon-sibility of the service provider, to support the customer’s business processes. Based on transaction- or business value-based prices, the service provider ensures scalability of the MTS and takes care of the resource manage-ment according to the utilisation scheme required to support the tasks.

Definition 1: Managed Testing Services (MTS)

On the provider’s side, delivery of the testing activities can be managed with full flexibility and thus leverage the commercial advantages of e.g. resource pooling and task relocation across different regions, which ensures competitive pricing and the highest possible scalability for the clients at the same time. The established standard process for implementing the MTS decision is depicted in Figure 1.

The process typically starts with a Pre-Engagement phase to clarify the constraints and the set-up of the MTS project. Next, the MTS Framework Design is developed to build the platform for the target state of MTS Operation. While the first and the second steps of the process are described in detail in Simon & Simon (2012) and primarily deal with political decision-making and commercial negotia-tions, the scope of the present whitepaper provides a more detailed look into the MTS Operation phase (see Figure 2).

2. Introduction

Figure 1: Transformation process for MTS

2. MTS

Framework Design 3. MTS Operation 1. Pre-Engagement

(6)

2.2. Professional Testing and Process

Maturity

There are three different types of prerequisites that must be fulfilled before the benefits of MTS can successfully be leveraged on the client’s side: • Industrialised Process Chain: The organisation

and processes on the customer’s side must be mature enough to support the division of labour across organisational units and different locations. This typical state of industrialisation has at least four prerequisites:

1. Modularisation: The overall business process chain must be defined to an appropriate level and comprise activities, responsibilities, de-pendencies, and results.

2. Standardisation: Based on the modularisation, the process landscape as well as the inter-faces must utilise standards to guarantee a specific level of quality.

3. Automation: For each activity within each process step, the highest possible level of automation has to be considered. 4. Focus on Core Competencies: The

funda-mental decision about whether it makes sense to utilise MTS can only be taken after a conscious management assessment of the core competencies of the business. • MTS Volume: The degree to which MTS deliver

commercial value depends on the size of the testing effort and the number of applications subject to MTS. Typically, the benefits of MTS are realised in three- to five-year engagements. • Openness for Change: Setting up MTS in an

organisation implies the shift of labour from internal (or body leasing or outtasking) to exter-nal resources having their own responsibilities. Ideally, the customer already has experience in the field of supplier management and can build upon this experience to collaborate with the service provider.

Figure 2: MTS Operation takes MTS from idea to implementation 3. MTS Operation Continuous Improvement Readiness Assurance per Application Knowledge Transfer & Collaborative Delivery Service

(7)

The project we are reporting about here had already successfully mastered the prerequisites. The customer operated with a business model driven by business processes, and was ready for MTS in terms of his industrialisation level. In fact, the customer had already outsourced most of his testing activities

to SQS, and the collaboration was well established. The project size and complexity was significant, therefore the volume of MTS-delivered testing tasks per release of the business software had enough room for commercial benefits.

Conservative estimations anticipate that by 2015 about 20 % to 25 % of all testing activities provided by test service specialists will be realised as MTS. For independent test organisations, this amounts to an overall business size of up to € 121 million of revenue for MTS (i.e. 25 % of the total market size as listed in Figure 3).

In addition to independent test organisations, es-tablished full-service providers will try to move into the market of MTS. However, the more mature a client’s organisation is (characterised by greater process awareness and insight into its core business competencies as opposed to tasks to be outsour-ced), the more important he will consider attributes like provider exchangeability and dependency reduction, in order to avoid provider lock-ins as well as output-based pricing. These considerations

strengthen explicit testing awareness on the client’s side and will naturally lead to the application of MTS provided by test service specialists. Further evidence of the benefits of independent testing providers (Wikipedia contributors, 2011) has been quantified in recent empirical research (Simon & Simon, 2013).

From the point of view of SQS, as of 2014 the pro-portion of MTS in the market will be in the range of 40 %.

As depicted in Figure 4, revenue in MTS is expected to grow from 10 % of overall revenue in 2011 to over 40 % of overall revenue in 2014, to a total of € 120 million.

(8)

Figure 3: Overall revenue of independent test organisations (NelsonHall Report, 2010)

Figure 4: Revenues of the market leader in MTS Total revenue in €m MTS revenue in €m 150 50 200 300 100 250 2014 2011 2012 2013 44 78 220 180 18 260 300 120 SQS

Tescom DNV-IT Tesnet Plan IT _Thinksoft Imbus FHG/IESE Amsphere MTP Acial ps-testware Quality House Maverick QA Infotech RTTS

Genilogix Squerist Experior Immune Assurity

KJR 163 40 28 20 16 14 13 13 12 11 10 9 9 8 7 7 7 6 6 5 5 5 160 m€ 80 0 40 120

(9)

4.1. Starting Position

The customer is a major insurance company with subsidiaries all over Germany. It is leading in its domain, and its business processes depend on efficient and reliable IT applications. Therefore, the customer operates and develops a tailored business-critical Java application involving several business departments. The customer’s core com-petencies had clearly been identified outside the IT – and consequently, outsourced testing tasks have been delivered by SQS since 2002.

The business application is a core insurance application consisting of four different modules matching four different business departments in the value chain of the customer. Each business department is responsible for exactly one of the modules, as depicted in Figure 5.

For testing purposes, a homogeneous approach to the definition of testware had been applied, and the use of test tools was harmonised by means of SQS-TEST/Professional®_{for test case and test}

data definition. For a small number of test cases, SQS-TEST/Professional®_{also served as a tool for}

the management of test automation scripts. The execution of the automated test scripts was imple-mented by a specialised tool for running business process tests at the GUI level.

A typical test cycle took ten weeks per release to execute the test cases required for regression testing and the testing of new or changed functionality. In total, the testware comprised approximately 3,000 business process test cases. Up until 2009, the customer and SQS had successfully collaborated on a time & material model, and most testing tasks had been delivered onsite at the customer’s premises.

4. Optimisation of Testing –

Test Automation as MTS

Business Department A Business Department C Business Department B Business Department D

Core Insurance Application

Figure 5: Structure of the project’s IT applications and business organisation Module B Module A

Module C

(10)

4.2. Challenge and Solution

In the course of 2009, the project parameters for the evolution of the customer’s core insurance application changed, and the pressure to reduce software release cycles without compromising functional quality significantly challenged the over-all release planning and development and testing processes.

For the quality assurance part of the customer’s re-lease plan, SQS considered various options of how to optimise the test assets to meet the challenges, and identified test automation as the means of choice. This measure was aimed at the following: • Reducing test execution times by means of

auto-mated execution of regression tests

• Maintaining or improving the level of coverage of business processes by test cases (i.e. improving test coverage) by reusing the existing testware as the basis for automation

• Consequently, identifying deficiencies faster and shortening feedback loops for communicating software errors to development units

• Thereby reducing testing costs and induced-error costs

In the light of the anticipated lifespan and numerous future releases of the core insurance application, it was technically and commercially desirable to de-velop robust and sustainable automated test cases so as to limit maintenance effort for future software changes. The original test suite of the business application consisted of approximately 3,000 test cases to be executed per software release. Accor-ding to an initial estimate, out of these 3,000 test cases about 2,300 qualified for a regression test suite to be executed repeatedly, and as such were in the focus of test automation.

4.3. Reasons for the Improvement

Project

Due to the overall release schedule, it was decided to implement the test automation effort in parallel to the further development and testing of the core insurance application. Further, in order to achieve the ROI with regard to the test automation cost and realise the benefits of automation for software releases as soon as possible, the timeframe of the Test Automation Project was limited to five months. SQS proposed to the customer to run the test auto-mation as a managed service project for a number of reasons:

• The transformation process towards MTS (as described in Section 2.1) was considered ready regarding the Pre-Engagement and the MTS Framework Design phase, due to the previous long-term engagements of the customer and SQS.

• From the perspective of the MTS Operation process (see Figure 2), the readiness of the application was given and the knowledge trans-fer had already taken place, with a continuous improvement procedure being well established. • Because of the amount of work involved and the

extremely tight deadline for the automation of all tests, execution of the project onsite seemed unwise. On the other hand, SQS’ Test Centres were in an excellent position to fulfil resource demands within a short timeframe.

• The customer’s business organisation was distributed across Germany, and so were its IT interfaces. Consequently, the change towards a distributed testing approach with SQS’ Test Centre delivering the major part of work was an easy step to take.

(11)

• The project’s scope was clearly focused on, and restricted to, the business process automation. From the very beginning, it was possible to pro-vide solid estimates for the efforts since SQS had a solid testware at hand as a basis for auto-mation and was well familiar with the processes and particularities of the customer’s application. • The total price for the service was above € 1

million, and as such significant in size. • From a commercial point of view, the project

was set up MTS-based on average prices to automate test activities per test case, if the test cases could be delivered as promised according to schedule. In case SQS did not deliver accor-ding to schedule, penalty fees were agreed per missing test case.

The total duration of the MTS Test Automation Project was 14 months, with the transformation of manual test cases to automated test cases taking the first five months in four intermediate milestones, specifying the number of automated test cases per milestone.

In line with the business goals, the project goals focused on the following:

• Reducing overall test execution times per release

• Increasing test coverage per test cycle and per release without compromising on effectiveness of testing

• Identifying issues in business process testing faster

• Reducing test cost per test execution • Reducing impact cost for errors

The entire project was delivered from SQS’ Test Centres with bridgeheads at the customer’s premises in two cities.

4.4. Set-Up of the MTS Test

Automation Project

As a critical success factor for the project, the focus lay on business process automation and high-level test cases rather than low-level technical automation of individual test steps. The full test suite for the customer consisted of about 3,000 test cases. Of those, a total of 2,300 business process test cases had been identified as having the potential to be auto-mated, and thus were in scope of the automation effort.

4.4.1. Project Phases

The Test Automation Project was planned in five phases to achieve the overall goals (see Figure 6): 1. Revise and Refactor: In this initial phase, the

test cases had to be analysed for up-to-dateness with respect to business specifications to ensure a solid basis for automation. In cases where gaps between test case and business specification were identified, the gaps were closed in liaison with the business experts of the client. This col-laborative task was carried out by SQS’ onsite teams. At the same time, it was assured that the test cases fully complied with standard structures to facilitate later automation.

2. Establish Standard Structures: After refactoring and aligning them with business specifications, the test cases were then reworked to follow standard naming conventions in a second phase. Next, for the modularisation of test cases, the test steps were adopted and building blocks for test cases were created. Finally, the test cases were linked with the necessary test data.

(12)

Figure 6: Project phases for MTS Test Automation Establish Standard Structures Revise and Refactor Automate Execute and Fine-Tune Deliver Release Tests

3. Automate: The third phase tackled the automa-tion of business process test cases itself by the test automation teams located in the Test Centres. The teams established the preconditions for the test cases and restructured test cases to sepa-rate GUI components from business logic steps for ease of maintenance in future releases. The test cases were evaluated and the automated execution was set up per test case.

4. Execute and Fine-Tune: In the fourth phase of the transformation, the tests were executed under tight control and quantification of test execution efforts and timeframes. This included the preparation per automated test case, its automated execution, as well as the effort re-quired for the analysis of the test results. In this phase, the overall success of the transformation was evaluated. Finally, through the experience gained, a precise estimate on the maintenance effort for the automated test cases could be derived.

5. Deliver Release Tests: The final phase represen-ted the return to the steady state of MTS and aimed at delivering two iterations of test execu-tions of the automated test cases, with benefits for two designated business software releases.

4.4.2. Project Organisation

The project organisation’s set-up was driven by the business organisation’s structure of the customer and its corresponding core insurance application structure. From SQS’ perspective, the organisational set-up of the client was mirrored in both test auto-mation and test execution. For the initial refacto-ring efforts, a small onsite team was deployed in a bridgehead role, taking care of the interface to the customer’s business experts. The onsite refactoring team was backed up by a larger offsite refactoring team in the Test Centre which provided sufficient manpower to carry out the refactoring tasks. In line with the size of the business software modules (and the corresponding initial testware), four teams of test automation staff were set up in the Test Centre. The organisation chart is depicted in Figure 7: the team set-up of the improvement project is aligned to the client’s business organisation, and the average head count of the team sizes reflects the complexity of the tasks with regard to the individual business modules.

In order to facilitate interaction between onsite and offsite staff and to provide an adequate escalation mechanism for resolving automation issues, com-munication channels were established between the offsite teams and designated responsibles onsite. The communication chart is depicted in Figure 8.

(13)

Figure 7: Organisation chart: Team set-up of the improvement project

Project Management (PM lead)

Team lead Alpha Module A TPA Test Centre 12 Refactoring Team Onsite 6 Team lead Bravo Module B TPA Test Centre 2 Refactoring Team Test Centre 10 Team lead Charly Module C TPA Test Centre 10 Team lead Delta Module D TPA Test Centre 4 Team lead Refactoring

Figure 8: Set-up of communication lines for the teams for improved project delivery (onsite-offsite split) Team lead Alpha Module A TPA Team GR Team lead Bravo Module B TPA Team GR Team lead Charly Module C TPA Team GR Team lead Delta Module D TPA Team GR Test Manager Alpha Module A Onsite Team Test Manager Bravo Module B Onsite Team Test Manager Charly Module C Onsite Team Test Manager Delta Module D Onsite Team

Project Management (Offsite) PM lead

Test Management (Onsite) TM lead

(14)

To capture the required business knowledge and to gain access to business input relevant for testing, SQS utilised the bridgeheads at the client’s site. For refactoring and test automation tasks, technical test experts were deployed in SQS’ Test Centre in Görlitz. In the course of the project, even the resources in the German Test Centre approached maximum uti-lisation, and action had to be taken in order to keep the promised delivery schedule. In this situation, the idea of MTS showed its strength since it was possible to augment the staff of one Test Centre (in Görlitz) with staff from another: as the legal and regulatory context of the Test Automation Project allowed for the transfer of individual tasks to other legal regions, SQS made use of additional resources in its Test Centre in Cairo, Egypt, to account for peak workload and keep the timelines. This increase of staff was not transparent to the customer and did not have commercial side effects – other than informing peers of the transfer for formal reasons, no changes in the process were necessary nor was there any change in the level of quality.

4.5. Managing the Transformation

Project

The management and implementation of the distributed Test Automation Project started with a challenging time horizon. Within less than five months, a vast amount of test cases had to be reviewed, reworked, and automated. Consequently, SQS’ project management team followed an en-gineering approach towards project management and applied different strategies to handle and manage the tasks.

Some of these strategies were the following: • Rolling wave planning with detailed planning

for the current week and the next, and only a high-level plan for the following weeks • Per-head planning of resource availability • Daily status reporting per sub-team, and

con-solidation onto a project dashboard

• Daily status meetings to recap project progress and manage project risks

• Generating forecasts for subsequent activities As the minimum level of documentation required for managing the project, the documents shown in Figure 9 were produced and maintained.

(15)

Figure 9: Minimum set of project management documents required for successful management Initiating Closing Planning Executing, Monitoring & Controlling Master Test Plan Invoice Project Charter lessons learned Acceptance Adapted Budget & Cost Adapted

Scope ScheduleAdapted Adapted HR Plan Work Breakdown Structure Budget & Cost Baseline Scope

Baseline Schedule Baseline PlanHR

Performance Report Documents

from Pre-Initiating

(16)

Figure 10: Performance status dashboard of refactoring and automation for Module A

Refactoring Module A Status

Automation Module A Status

0 0 50 50 100 100 150 150 200 200 CW 01 (04/01/10 – 08/01/10) CW 01 (04/01/10 – 08/01/10) CW 05 (01/02/10 – 05/02/10) CW 05 (01/02/10 – 05/02/10) CW 02 (11/01/10 – 15/01/10) CW 02 (11/01/10 – 15/01/10) CW 06 (08/02/10 – 12/02/10) CW 06 (08/02/10 – 12/02/10) CW 03 (18/01/10 – 22/01/10) CW 03 (18.01.10 – 22/01/10) CW 07 (15/02/10 – 19/02/10) CW 07 (15/02/10 – 19/02/10) CW 04 (25/01/10 – 29/01/10) CW 04 (25/01/10 – 29/01/10) CW 08 (22/02/10 – 26/02/10) CW 08 (22.02.10 – 26.02.10)

Refactoring Module A plan Refactoring Module A revised plan

Refactoring Module A forecast Refactoring Module A achieved

Automation Module A plan Automation Module A revised plan

Automation Module A forecast Automation Module A achieved

(17)

An example of performance reporting of the refac-toring phase of Module A is depicted in Figure 10. Thanks to daily progress reporting, the overall reporting and management was aggregated into a management view that allowed for fast mitigation action in case there was a deviation from plan.

4.6. Achievements and lessons

learned

The goals set out at the beginning of the project were fully achieved. In particular, the achievements are the following:

• Test automation of 2,300 test cases based on business processes was completed according to schedule (no penalty fees were incurred during the project).

• Efficiency improvement in terms of test cycle times of 50 % was reached without compromising the test coverage level of the business processes. The first benefits were generated when the first new releases of the software had to be tested even while the test automation was still on its way.

• Consequently, a faster identification of errors in business process tests is now a reality. • Due to shorter test cycle times, the overall

release process is more efficient.

In retrospect, the lessons learned from the imple-mentation of the project regarding methodology are as follows:

• The transformation of manual test cases to automated test cases requires solid and well-structured test assets.

• The maintenance of automated test cases is facilitated by the structured approach. The clear separation of GUI components from business logic additionally increases the reuse of the automated test cases, and if changes occur, test automation can be adapted quickly as only the GUI parts need to be adapted.

• The multi-release testing capabilities of SQS-TEST®_{/Professional contribute to easily}

main-tainable regression test suites and enable the application of already automated test cases while the automation project is still underway. • The existing test specification (i.e. the basis for

the initial steps in the transformation) must be mature and of excellent quality – low quality of test assets poses a high risk for test automation projects as a managed service.

• The availability of test environments is crucial. A solid, enterprise-level test environment manage-ment is on the critical path of MTS and should receive the highest level of attention. In SQS’ Test Centres, test environments are provided on enterprise level, and can be scaled up or down quickly – however, this process must be thoroughly tested and customised to the transformation project’s specific needs.

• Ramping up specific business knowledge to an adequate level within the test automation teams posed a particular challenge. It turned out, how-ever, that for test automation only little business knowledge was required to refactor and structure existing test cases. The technical skills were far more important when dealing with test automa-tion issues – the few business-related quesautoma-tions were sorted out by the onsite teams, and the client never had to interface with the test auto-mation experts directly.

(18)

From the managerial perspective, the engineering approach to project management showed its value. The most important factors are:

• Tight project controlling: the challenging con-straints of the improvement project – such as fixed deadlines and penalty payments for non-delivery – provided a strong argument in favour of rigorous controlling of the project so that effective and fact-based management could be realised.

• Splitting the teams into different groups in line with the client’s organisation resulted in a competitive set-up and inspired the Test Centre teams to deliver an extraordinary quality and pace. • Following the project engineering approach, daily

status meetings were not used for surveillance but rather as a forum for demonstrating progress and fixing issues early.

• The organisational set-up of the project with many staff in the Test Centre and bridgeheads onsite with the client contributed to clean and lean communication channels. Responsible contact persons were always known, and interfaces to onsite teams were clearly defined.

In summary, the conclusion is that distributed test automation is possible! At least, that is, with a reasonable bridgehead onsite and clear interfaces to the customer. SQS’ teams were easily ramped up or down via resource pools in Test Centres at different locations without the customer noticing a difference. Internally, it is important to have the right mix in the teams – getting one senior team member (or team lead) on board who is used to collaborating across long distances, is a must. As in all projects – things change over time. How-ever, as the payment model is very precise, strict change management procedures will be required if tasks are extended or if the scope of the managed service shifts. For example, business process changes induced by the review steps at the beginning of the transformation will entail efforts to adopt business process test cases accordingly. Since the project was paid on a per-test-case basis, there was little room for tolerance, and changes had to be tracked rigorously to bring transparency into the additional efforts.

(19)

5. Conclusion and Outlook

Delivering standard testing tasks as managed ser-vices is an established delivery model for mature organisations. In this whitepaper, we reported on a more challenging task: implementing a test optimisation project as MTS by means of test auto-mation. If the prerequisites are met, test automation can be delivered as MTS with great success – in MTS as discussed above, test cycle times were re- duced by 50 % without compromising test coverage, at the same time reducing overall cost for future regressions.

The payment model for MTS – even in the case of test automation – can simply be transaction-based. In our case, the test cases were the key driver for cost in the transformation and execution of the service.

NelsonHall Report. Independent Testing Providers vs. System Integrators. Cologne: SQS AG, April 2010 Simon, F., & Simon, D. Managed Testing Services. In: Thought Leadership 2012. Cologne: SQS AG, 2012 Simon, F., & Simon, D. QS im Wandel: Test-Unabhängigkeit. In: OBJEKTspektrum, 2013. To appear. Wikipedia contributors. Independent Test Organization. [Cited: 27/07/2011]

http://en.wikipedia.org/wiki/Independent_test_organization

Distributed Engineered Test Efficiency Improvement