| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_8ngBgMPdEdmbOvqy4O0adg" name="maintaining_automated_test_suite,_0kF5kMlgEdmt3adZL5Dmdw" guid="_8ngBgMPdEdmbOvqy4O0adg" changeDate="2006-09-26T11:31:15.000-0700" version="7.2.0"> |
| <mainDescription><h3>
 |
| Introduction
 |
| </h3>
 |
| <p>
 |
| At some point in your test effort, you may find it necessary to manage your test effort by creating test suites for
 |
| your test assets.&nbsp;Maintaining test suites can take many different forms. To facilitate your testing, you may want
 |
| to introduce some&nbsp;level of&nbsp;automation of your test suites.&nbsp;The fact that you've automated your test
 |
| suites does not necessarily make your testing easier however. It may actually increase the maintenance burden of your
 |
| suites.
 |
| </p>
 |
| <p>
 |
| This guideline introduces you to useful heuristics on how to facilitate the maintenance of your automated test suites.
 |
| </p>
 |
| <h4>
 |
| Plan your test&nbsp;suites
 |
| </h4>
 |
| <p>
 |
| Automating your testing without planning increases&nbsp;the chances that testing will be ineffective
 |
| and&nbsp;inefficient.&nbsp;Some level of planning should take place whether implicit or explicit.&nbsp;An essential
 |
| part of any test plan is the definition of a strategy for test automation.&nbsp;Use your plan to articulate to the
 |
| development team how you plan to maintain your test assets.&nbsp;In many cases, this is never done.&nbsp;The rest of
 |
| the development team may be unaware of how you intend to maintain your tests.&nbsp;It is also a good practice to get
 |
| the rest of the development team to understand that this maintenance can be a substantial part of the overall
 |
| development effort.&nbsp;Use your test tooling to capture this information and treat this plan just like you would
 |
| treat any other test asset in your test repository.
 |
| </p>
 |
| <h4>
 |
| Centrally locate your test assets
 |
| </h4>
 |
| <p>
 |
| To facilitate the maintenance of your automated test suites, locate your test assets in a repository that can be
 |
| accessed by the development team.&nbsp;Many test automation environments provide test management tools that make it
 |
| easier to organize and access your test assets by maintaining the test assets (test cases, test scripts, and test
 |
| suites) in a common repository.
 |
| </p>
 |
| <p>
 |
| In addition, some form of access control is enforced by the automation test tool.&nbsp;This eases the maintenance
 |
| burden by ensuring the integrity of your test suites.&nbsp;You may choose to grant stakeholders and managers read-only
 |
| access, whereas developers and testers at the practitioner level may have read/write access.
 |
| </p>
 |
| <h4>
 |
| Treat your test assets like any other software
 |
| </h4>
 |
| <p>
 |
| Software must be maintained.&nbsp;This also applies to the software in your test suites.&nbsp;Test cases and their
 |
| associated test scripts, whether recorded or programmed, should be maintained.&nbsp;And just as software has different
 |
| kinds of maintenance (e.g., corrective, preventative, or adaptive) so too do the assets in your automated test suites.
 |
| As you lifecycle your test suites, identify, if only informally,&nbsp;how&nbsp;you plan to disposition the test suite
 |
| corrective maintenance (e.g., syntactical errors in your scripts),&nbsp;preventative maintenance (e.g., where possible
 |
| to write generalized test scripts), and adaptive maintenance (e.g., how you&nbsp;can use your test tooling to re-assign
 |
| test&nbsp;assets within one suite to&nbsp;another suite or suites).&nbsp;This can be captured, as described in the
 |
| section <strong>Plan Your Test Suites</strong> above, in your test plan.
 |
| </p>
 |
| <h4>
 |
| Improve the testability of your test suites through collaboration with developers
 |
| </h4>
 |
| <p>
 |
| It's one thing to say that your test suites will need to be maintained due to changes in the application, changes in
 |
| the testing target, etc.&nbsp;It's quite another thing to actually determine whether a test suite needs to be
 |
| revamped&nbsp;and, if it does, what test assets within it need to be addressed.
 |
| </p>
 |
| <p>
 |
| One way to facilitate this is to use test suites as a way to communicate test decision to the developers.&nbsp;One way
 |
| to perform continuous perfective maintenance of test suites is to think of your test suites as assets that belong to
 |
| the development team rather than just the testers.&nbsp; You can perform a kind of perfective maintenance on test in
 |
| the following ways:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| use test suites to raise the level of abstraction
 |
| </li>
 |
| <li>
 |
| use test suites to provide focus for the developer
 |
| </li>
 |
| <li>
 |
| use test suites to articulate areas that the developers would like testers to focus on
 |
| </li>
 |
| <li>
 |
| make the construction and maintenance&nbsp;of test suites more efficient&nbsp;by understanding what area(s)
 |
| developers want to focus on
 |
| </li>
 |
| <li>
 |
| use test suites to clarify test targets with developers
 |
| </li>
 |
| </ul>
 |
| <h4>
 |
| Don't be afraid to clean up your suites
 |
| </h4>
 |
| <p>
 |
| Your test assets will evolve just as the application under test will.&nbsp;As requirements to the system change, the
 |
| application will change as well.&nbsp;To maintain your test suites, you should continually&nbsp;check whether test
 |
| assets are valid.&nbsp;If possible, validity checks should be performed after each new release of the software,
 |
| preferably more frequently.&nbsp;Keeping your test suites relevant is a full-time job.&nbsp;Assume that changes in the
 |
| software will lead to some degree of invalid tests within your test suites.&nbsp;Once these test assets have been
 |
| identified as invalid, get rid of them.&nbsp;This will make the maintenance burden much more tolerable.&nbsp;Some
 |
| automated test tooling environments make this task easier by providing ways to package outdated or invalid
 |
| tests.&nbsp;In some cases, you may not be absolutely sure whether you want to completely get rid of tests within your
 |
| test suite or even of getting rid of test suites altogether.&nbsp; To alleviate this burden, you can create packages
 |
| for obsolete tests or test suites and dispose of tests or test suites by putting them in packages labeled for this
 |
| purpose.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |