Header Ads

What Should Be The Structure of Automation Test Cases

A perfectly structured automation testcase 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.


Powered by Blogger.