Wednesday, December 26, 2012

Fascinating Ways to Build Test Cases



12-26-2012

It is fascinating to learn different ways we can create test cases to meet different challenges.  The techniques are a true compliment to the amazing analytical abilities of a tester.  What this means is it gives testers more ingenious methods to provide input into the test automation process.  So let’s explore some ideas on how we can more creatively create tests!

Test Cases by Pre-Developed Test Data


The question was asked, “How can we create all the required tests with this magnitude of test data in the time frame that we have?”  Or, “How can we create tests with data that can exercise all the required applications and their functionality?”  These are very good questions especially coming from the financial industry.  Valid questions can be addressed by:

  • The test automation developer develops keyword method(s) designed to extract test data based on given rules from a test data repository.
  • The tester, using the keyword method(s), provides the data extraction rules required to retrieve a subset of data.  An example would be the type of pension, funds and age of the retiree.
  • The tester can then utilize the retrieved test data set for the remainder of a given test case or test set that will test the required sub-infrastructure of systems and functions given the type of pension record it is processing.
  • Feature specific keyword methods are called based on the test data requirements.
This example was used with an infrastructure of about forty systems designed for pension management.  The testers required the automation developers to use over a million test data records that were lifted from a live production database used to verify upgraded systems worked as expected.  This method allowed both the tester and the test automation developer to:
  • Collaborate to streamline the operation into reusable test cases and keyword methods designed to test all test data records.
  • Develop the test framework to perform actions and verify against the correct subset of systems based on the given data.
This clever implementation not only allowed us to process all records in the given test data database but was flexible to resist changes in the test data database as well as work with different test environments that had their own set of test data.   I guess the downside was developing intelligent test cases and keyword methods to select the correct applications, exercise the correct functionality and to verify correctly. 

Test Cases by Transactions


This was a clever technique I actually learned during a job interview.  A stock trading company used this technique to automate their regression tests.  It seems they used manual exploratory testing techniques which generated transactions from the client applications.  These transactions were then captured and converted into reusable scripts for regression tests.  To my understanding they did not test at the GUI level and they did not have automated functional type tests.

Although I found the idea intriguing, I was quite inquisitive about if they were capturing clear and concise tests that could be manually understood for say reviewing failed tests.  I thought, what happens if the tester did not validate something correctly?  What process did they have in place for verifying the captured tests?  Was it time-consuming to perform this verification?  I don’t have the answers but I thought it was an ingenious way to building test automation.

Test Cases by Modeling

 

I find the idea of test case modeling quite fascinating and one of the latest techniques I have been experimenting with.  One can design tests by using mind mapping or test case modeling.  This technique definitely fits into the agile world and can support a variety of test types performing both manual and automated testing.   A tester can model or graph a test case instead of the traditional word document equivalent of scripting out a test case.  Some of the benefits to modeling test cases are:

  • A diagram can represent one to many test permutations.
  • A model can be as simple or as complex as the tester requires.
  • This is perhaps a great solution for testing infrastructures of complex applications.
  • Depending on the tool used for modeling, one can leverage the properties of the shapes to insert data characteristics such as test data, test case and step description, links, etc.
  • Can link models to a test automation framework.
  • Can use a tool like GraphWalker to generate the test case permutations.
  • The model can reveal permutations not revealed by traditional test case generation.
  • And perhaps many more benefits.
As a tester from the traditional era, some challenges I can see using this technique are:
  •  For some, modeling may not be a native skill (I am the worst at modeling ideas).
  • Supporting complex data characteristics like those found in financial applications.
  • For flexible test automation frameworks that do not include hard coded dependencies like URLs, data or verification characteristics, learning how to maintain it with the use test case models.
  • Incorporating the use of modeled test cases within a test management system if one is in use.
  • And perhaps you can think of view contradictions to this technique.

Regardless of the pros and cons, one has to admit it is a clever way to develop tests while exploring a system and to help optimize the time we have for testing and test development especially with agile methods.  

Test Cases by Configuration Keys


If you are programming your test cases, this is a nice technique for morphing the tests to suit altered behavior imposed by configurations, clients, platforms etc.  I guess when you look at it as a scripted version of the modeling technique.  As part of the data passed to the function, it can be used to exercise the correct path based on the current test run parameters. 

Conclusion


So as you can see, test case creation can go beyond writing step by step instructions and verifications.  The technique you choose, even ones not mentioned here, truly depends on how you need to meet your unique testing challenges.

Happy Automation!

No comments:

Post a Comment