OBSCURE TESTS

From Test Automation Patterns
Revision as of 16:04, 4 April 2018 by Cathal (talk | contribs) (Created page with "<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.........................................................................................")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
.................................................................................................................Main Page / Back to Design Issues / Back to Test Automation Issues

Issue summary

Automated tests are very complex and difficult to understand

Category

Design

Examples

  1. Manual testcases have been automated as is, that is they depict long scenarios that build on each other
  2. Automated scripts or data are not modular, are not documented and are stored with cryptical names, so that they practically cannot be reused
  3. Automation scripts are written in the proprietary language of the current tool and testers cannot read and much less run them
  4. Keywords have been implemented, but never maintained, so that nobody really knows what they do
  5. The automated test cases try to test too much all at the same time. This makes the tests not only slower, but also more fragile because they can fail in parts that actually have nothing to do with the original test


Questions

Who is doing the automation? A "lone hero"?
Who is writing the automation test cases?
Are there standards? If yes, are they used?

Resolving Patterns

Most recommended:


Other useful patterns:

  • DESIGN FOR REUSE: using this pattern forces the team to develop readable and maintainable testware
  • INDEPENDENT TEST CASES: apply this pattern to get rid of issues like Example 1.
  • KEEP IT SIMPLE: this pattern is always recommendable!
  • KILL THE ZOMBIES: this pattern helps you clean up your scripts
  • LEARN FROM MISTAKES: apply this pattern in order to transform your bad experiences in learning experiences
  • MAINTAIN THE TESTWARE: this pattern is necessary as soon as you want to use your automation for more then a quick fix
  • OBJECT MAP: This pattern helps you develop scripts that use readable names

.................................................................................................................Main Page / Back to Design Issues / Back to Test Automation Issues