Best Practices

Creating Tests - Enterprise Level
  • Communicate Testing Approach - Objectives, Goals as well as Strategy
    • These can be formal or informal
    • Or define a budget in terms of time or resources or money
  • First create all or most Tests before wiring them to application elements
    • Test Cases can be built by business users as it focuses on the Business domain
    • Test Cases can be approved and prioritized
    • Test Cases are well documented and can reveal potential design problems or enhancements
    • Changes at this level are easy and fast
    • At a minimum, you can use these Test Cases for manual testing
  • Create Test Cases
  • Add Steps to each Test Case
  • Add Verification(s) to Steps
  • Create Test Plans based on Test Approach
    • A minimal Test Plan can contain the basic Test Cases that must pass before application can be released
    • A comprehensive Test Plan contains all Test Cases 
    • A feature Test Plan can focus on a specific feature
    • An OS specific Test Plan can contain Test Cases targeted to a specific OS
      • Similar for other environment variables e.g. database, browser
  • The above steps can also be done by building a spreadsheet and then importing it into EAF Tester
  • Wiring Test Cases to Application (Technical portion)
    • Begin after most if not all Test Cases are complete
    • For browser based applications, ensure each HTML element has a unique ID. It is not difficult and the cost is worth it in the long run. No question!
    • Create Control Elements 
    • Create Data values if required
    • Create Keywords connecting Control Elements and optionally Data
    • Edit Test Steps to replace placeholder with actual Keyword
    • Test the Test Case by creating a temporary Test Plan containing the Test Case by itself. Generate and Execute it. If any errors are found, delete executions then fix Test Case and repeat Generate and Execute steps.
  • Generate Test Plan after all Test Cases are built and tested
  • Execute Test Plan
  • Versioning
    • After a Test Plan is used, changes are not allowed to it
      • If multiple versions of the application are not supported AND you do not wish to retain Test Results, you can delete all Test Executions which will then allow changes to Test artifacts
    • As the application evolves and multiple versions are supported, certain Test Cases will change or new Test Cases may be required
      • Create a new version by copying / pasting the current version of Test
      • Make changes to affected Test Cases or create new Test Cases
        • Add / modify sub elements of Test Case
        • Add / modify Test Plan 
Usage - Developer 
If you are a developer using the tool for personal testing during development:
  • For browser based applications, ensure each HTML element has a unique ID. It is not difficult and the cost is worth it in the long run. No question!
  • Create a Test Harness to call your functions etc. 
    • A Test Harness is a simple UI that can interact with your functions, methods etc.
  • Create a Test Case
  • Create Test Steps
  • Create Verification Step(s)
  • Create Control Elements 
  • Create Data values if required
    • It is faster to create separate Data items than redefine them in Test Plan because your Test Case may change rapidly during development
  • Create Keywords connecting Control Elements and optionally Data
  • Edit Test Steps to replace placeholder with actual Keyword
  • Create a Plan and Add Test Case to it
  • Generate Plan
  • Execute Plan
  • To make changes to any part of the Test, first delete all Executions, make changes then regenerate Test Plan before executing it again