Learn How to Structure of Automation Test Case Free And Fast in 2020

Structure of Automation Test case

A perfectly structured automation test case should consist of four parts. They are:

• Setup or precondition
• main test
• Cleanup or post condition
• Optional code.

Precondition:

All test data ot steps needs to be there in application or needs to be performed so that current test run/execute smoothly.

Main test: In this area the main objective of test case is being executed.

Cleanup: Here we delete all the testdata that is being created in the main test section.In other word we try to restore the out of box condition of the application. Why this is required?? Any accidental data pollution can be rectified.

Optional Area:

All other user defined functions go here.

Class testcase1
{
precondition()
{
}
main()
{
functionx()
}
cleanup()
{
}
functionx()
{
}
}

Why we should do like this?

• Well, while developing or refactoring we must understand our test goal.Each testcase should address only one requirement. Multiple requirement coverage in a single automation test may lead to confusion. It will hamper the traceability matrix as well.
• By implementing the 3/4 folds we can reduce junk code creation. More encapsulation with less junk.
• By implementing such structure we are making testcase independent. There is no dependency such that testcaseX needs to be executed in order run current testcase.So pulling of any testcase and re execution is possible.
• Also, we must check if we are generating redundant code /duplicate code.The more we will reduce the duplicate code more our test will become mature.A premature optimization is the main problem area of the organization.
• Too big component or function would reduce the flexibility of reuse. So always create smaller components or functions and assemble them in last.
• Too small components looses it significance . Mostly we overlook them. Those created but non utilized component or functions will become zombie. It is always better to use a higher level components out of lower level components.
• The naming convention has to be as per business requirements. then it is easy to write,find and reuse. Freeform of coding loose these advantages .
• Each low level components has to have a definite purpose.
• Long term survival depends on the standard approach that aids the architecture.
• Each small function or component should have a verification point.
• Use of wait syntax is mandatory but can be updated with do until loop.
• When something is getting changed in the application, we need to upgrade the low level components/functions. Maintenance become easy.

  Best Test Structure::Hermetic Test Pattern

  In the above section, I have shown how we can improve the test structure and make a better one.Too many tests will make feedback loop delayed and too less tests may not have enough coverage.Sometimes too many tests are added to a single E2E(End to End) script.This kind of test design will make it spaghetti. The goal is to design a significant approach that will lower down the feedback loop.
  Now lets looks at the question below:

  • What is the biggest benefit or goal ?
  • What is the cost ?
  • How is the team?
  • What training team needs?
  • What is holding automation back?

  We have to prioritise the issues and resolve one by one. Now in this post I am trying to venture the pattern on which the structure is made. The test structure is made on Hermetic Test Pattern. As per the Hermetic test pattern each test should be completely Independent and should not depend on other test.

  So,It should be atomic in nature and self sufficient.As per the maintenance concern,each test case should be maintained concern,each testcase should be maintained separately and if any dependency outside of the test found(may be a 3rd party library,3rd party service) test engineer should cut the linkage with the service.

  The best way to start is to look into smaller objectives but add test slowly to make it mature.

  Advantages: Each testcases are atomic in nature so no dependency on anything. Test takes clean start as precondition creates all test data No polluted data inflow our outflow. We can execute the test in different order on need based. We can create more molecularity which increase code re usability. As each testcase is atomic,parallel execution is still possible.The deep advantages are:

  1. Increase confidence in software quality.
  2. Earlier time to produce the software to the market means more revenue.
  3. Reduce the cost in testing.
  4. Consistent repeatable testing
  5. Run tests unattended.
  6. Find more regression bugs
  7. Run tests more often
  8. Better quality software
  9. Coverage is high
  10. Find more bugs
  11. Test on different systems.
   

  Disadvantages: Duplication of code increases if not created modular type. Design testdata for each testcase Execution time increases. High resource utilisation.