| <?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.3/uma.ecore" epf:version="1.0.0" xmi:id="_8ngBgMPdEdmbOvqy4O0adg" name="maintaining_automated_test_suite,_0kF5kMlgEdmt3adZL5Dmdw" guid="_8ngBgMPdEdmbOvqy4O0adg" changeDate="2006-09-26T11:31:15.615-0700"> |
| <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> |