OpenUP/OpenUP_baseline_EN/exported_HTML/openup_basic/guidances/guidelines/maintaining_automated_test_suite.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>\openup_basic\guidances\guidelines\maintaining_automated_test_suite.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: maintaining_automated_test_suite.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_0kF5kMlgEdmt3adZL5Dmdw CRC: 1468414705 -->Maintaining Automated Test Suite<!-- END:presentationName,_0kF5kMlgEdmt3adZL5Dmdw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_0kF5kMlgEdmt3adZL5Dmdw CRC: 2041861399 -->This guideline explains ways to maintain automated test suites - collection of tests performed together for breadth and depth coverage.<!-- END:briefDescription,_0kF5kMlgEdmt3adZL5Dmdw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,_8ngBgMPdEdmbOvqy4O0adg CRC: 2032769287 --><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><!-- END:mainDescription,_8ngBgMPdEdmbOvqy4O0adg -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>\openup_basic\guidances\guidelines\maintaining_automated_test_suite.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: maintaining_automated_test_suite.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_0kF5kMlgEdmt3adZL5Dmdw CRC: 1468414705 -->Maintaining Automated Test Suite<!-- END:presentationName,_0kF5kMlgEdmt3adZL5Dmdw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_0kF5kMlgEdmt3adZL5Dmdw CRC: 2041861399 -->This guideline explains ways to maintain automated test suites - collection of tests performed together for breadth and depth coverage.<!-- END:briefDescription,_0kF5kMlgEdmt3adZL5Dmdw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,_8ngBgMPdEdmbOvqy4O0adg CRC: 2032769287 --><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. Maintaining test suites can take many different forms. To facilitate your testing, you may want
	to introduce some level of automation of your test suites. 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 suites
	</h4>
	<p>
	Automating your testing without planning increases the chances that testing will be ineffective
	and inefficient. Some level of planning should take place whether implicit or explicit. An essential
	part of any test plan is the definition of a strategy for test automation. Use your plan to articulate to the
	development team how you plan to maintain your test assets. In many cases, this is never done. The rest of
	the development team may be unaware of how you intend to maintain your tests. 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. 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. 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. This eases the maintenance
	burden by ensuring the integrity of your test suites. 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. This also applies to the software in your test suites. Test cases and their
	associated test scripts, whether recorded or programmed, should be maintained. 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, how you plan to disposition the test suite
	corrective maintenance (e.g., syntactical errors in your scripts), preventative maintenance (e.g., where possible
	to write generalized test scripts), and adaptive maintenance (e.g., how you can use your test tooling to re-assign
	test assets within one suite to another suite or suites). 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. It's quite another thing to actually determine whether a test suite needs to be
	revamped 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. 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.  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 of test suites more efficient 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. As requirements to the system change, the
	application will change as well. To maintain your test suites, you should continually check whether test
	assets are valid. If possible, validity checks should be performed after each new release of the software,
	preferably more frequently. Keeping your test suites relevant is a full-time job. Assume that changes in the
	software will lead to some degree of invalid tests within your test suites. Once these test assets have been
	identified as invalid, get rid of them. This will make the maintenance burden much more tolerable. Some
	automated test tooling environments make this task easier by providing ways to package outdated or invalid
	tests. 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.  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><!-- END:mainDescription,_8ngBgMPdEdmbOvqy4O0adg -->
	</body>
	</html>