Test Design Considerations
Introducing Test Design
We’ve provided in this chapter information that will be useful to both those new to test automation and for the experienced QA professional. Here we describe the most common types of automated tests. We also describe ‘design patterns’ commonly used in test automation for improving the maintenance and extensibily of your automation suite. The more experienced reader will find these interesting if not already using these techniques.
Types of Tests
What parts of your application should you test? That depends on aspects of your project: user expectations, time allowed for the project, priorities set by the project manager and so on. Once the project boundaries are defined though, you, the tester, will certainly make many decisions on what to test.
We’ve created a few terms here for the purpose of categorizing the types of test you may perform on your web application. These terms are by no means standard, although the concepts we present here are typical for web-application testing.
Testing Static Content
The simplest type of test, a content test, is a simple test for the existence of a static, non-changing, UI element. For instance
Testing Links
A frequent source of errors for web-sites is broken links or missing pages behind links. Testing involves clicking each link and verifying the expected page. If static links are infrequently changed then manual testing may be sufficient. However if your web designers frequently alter links, or if files are occasionally relocated, link tests should be automated.
Function Tests
These would be tests of a specific function within your application, requiring some type of user input, and returning some type of results. Often a function test will involve multiple pages with a form-based input page containing a collection of input fields, Submit and Cancel operations, and one or more response pages. User input can be via text-input fields, check boxes, drop-down lists, or any other browser-supported input.
Function tests are often the most complex tests you’ll automate, but are usually the most important. Typical tests can be for login, registration to the site, user account operations, account settings changes, complex data retrieval operations, among others. Function tests typically mirror the user-scenarios used to specify the features and design or your application.
Testing Dynamic Elements
Often a web page element has a unique identifier used to uniquely locate that element within the page. Usually these are implemented using the html tag’s ‘id’ attribute or its ‘name’ attribute. These names can be a static, i.e unchanging, string constant. They can also be dynamically generated values that vary each instance of the page. For example, some web servers might name a displayed document doc3861 one instance of a page, and ‘doc6148’ on a different instance of the page depending on what ‘document’ the user was retrieving. A test script verifying that a document exists may not have a consistent identifier to use for locating that document. Often, dynamic elements with varying identifiers are on some type of result page based on a user action. This though certainly depends on the function of the web application.
Here’s an example.
This shows an HTML tag for a check box. Its ID (addForm:_ID74:_ID75:0:_ID79:0:checkBox) is a dynamically generated value. The next time the same page is opened it will likely be a different value.
Ajax Tests
Ajax is a technology which supports dynamically changing user interface elements which can dynamically change without the browser having to reload the page, such as animation, RSS feeds, and real-time data updates among others. There’s a countless ways Ajax can be used to update elements on a web page. But, the easy way to think of this is that in Ajax-driven applications, data can retrieved from the application server and then displayed on the page without reloading the entire page. Only a portion of the page, or strictly the element itself is reloaded.
Introducing Test Design
We’ve provided in this chapter information that will be useful to both those new to test automation and for the experienced QA professional. Here we describe the most common types of automated tests. We also describe ‘design patterns’ commonly used in test automation for improving the maintenance and extensibily of your automation suite. The more experienced reader will find these interesting if not already using these techniques.
Types of Tests
What parts of your application should you test? That depends on aspects of your project: user expectations, time allowed for the project, priorities set by the project manager and so on. Once the project boundaries are defined though, you, the tester, will certainly make many decisions on what to test.
We’ve created a few terms here for the purpose of categorizing the types of test you may perform on your web application. These terms are by no means standard, although the concepts we present here are typical for web-application testing.
Testing Static Content
The simplest type of test, a content test, is a simple test for the existence of a static, non-changing, UI element. For instance
- Does each page have its expected page title? This can be used to verify your test found an expected page after following a link.
- Does the application’s home page contain an image expected to be at the top of the page?
- Does each page of the website contain a footer area with links to the company contact page, privacy policy, and trademarks information?
- Does each page begin with heading text using the <h1> tag? And, does each page have the correct text within that header?
Testing Links
A frequent source of errors for web-sites is broken links or missing pages behind links. Testing involves clicking each link and verifying the expected page. If static links are infrequently changed then manual testing may be sufficient. However if your web designers frequently alter links, or if files are occasionally relocated, link tests should be automated.
Function Tests
These would be tests of a specific function within your application, requiring some type of user input, and returning some type of results. Often a function test will involve multiple pages with a form-based input page containing a collection of input fields, Submit and Cancel operations, and one or more response pages. User input can be via text-input fields, check boxes, drop-down lists, or any other browser-supported input.
Function tests are often the most complex tests you’ll automate, but are usually the most important. Typical tests can be for login, registration to the site, user account operations, account settings changes, complex data retrieval operations, among others. Function tests typically mirror the user-scenarios used to specify the features and design or your application.
Testing Dynamic Elements
Often a web page element has a unique identifier used to uniquely locate that element within the page. Usually these are implemented using the html tag’s ‘id’ attribute or its ‘name’ attribute. These names can be a static, i.e unchanging, string constant. They can also be dynamically generated values that vary each instance of the page. For example, some web servers might name a displayed document doc3861 one instance of a page, and ‘doc6148’ on a different instance of the page depending on what ‘document’ the user was retrieving. A test script verifying that a document exists may not have a consistent identifier to use for locating that document. Often, dynamic elements with varying identifiers are on some type of result page based on a user action. This though certainly depends on the function of the web application.
Here’s an example.
This shows an HTML tag for a check box. Its ID (addForm:_ID74:_ID75:0:_ID79:0:checkBox) is a dynamically generated value. The next time the same page is opened it will likely be a different value.
Ajax Tests
Ajax is a technology which supports dynamically changing user interface elements which can dynamically change without the browser having to reload the page, such as animation, RSS feeds, and real-time data updates among others. There’s a countless ways Ajax can be used to update elements on a web page. But, the easy way to think of this is that in Ajax-driven applications, data can retrieved from the application server and then displayed on the page without reloading the entire page. Only a portion of the page, or strictly the element itself is reloaded.
No comments:
Post a Comment