End-to-End test cases
Jan 05

End-to-End test cases

In business-critical projects, the acceptance testers are usually people, who know the business processes well. Knowing how to test, on the other hand, can vary greatly. There are people who are experienced, but also people who are testing for the first time. This can be challenging when informing about the testing as well as with documenting the testing. Especially when testing whole processes, ergo End-to-End (E2E).

Optimal test case for testing business processes?

I used to see many test cases created according to the vendor’s instructions with detailed testing steps. Whatever kind of a minefield the process was, testers finished the test case by following the steps.

These detailed test cases have a couple of problems:

  • Writing them takes a lot of work and the system used should be fairly finished.
  • Upkeeping the test cases takes a lot of time.
  • The test case only guides testers to test only the technical functionalities, not to see if the solution is supporting the business.

Today these heavy test documentations are changing into something lighter. For example, they can just be listings of things that need testing. I use the lighter methods in my own testing, but the light test documentation requires good skills from the testers. They need to be able to study the solutions from different points of view, with quality results.

Optimal test case - end-to-end

In E2E test cases, the tester should be told:

  • What functions to execute and what parameters to use.
  • Who the next tester is.
  • What functions and events have been done in the previous phases

Structure I like to use in E2E test cases:

Test case front page information helps with:

  • In planning testing, they help with choosing the right test cases.
  • Scheduling guides for executing the right tests at the right time.
  • Groupings and statuses as data for reporting.
  • When starting testing, the tester gets a better picture of the test as a whole.
  • Assigned to- shows who’s testing next.
  • When validating testing, the extent of it is easier to see.

An example:

Laptop example - end-to-end test cases
Test document laptop - end-to-end test cases

Test document / steps

Here’s an example of an E2E test document I wrote.

A few notes about the test document:

  • The headings group the testing. One whole group under one heading.
  • Function -column tells what system/transaction to use when testing. This information is useful when validating which functions have been tested.
  • Description -column tells which function should be executed.
  • Tester/role -column tells the tester’s role.
  • Expected Result -column tells the function’s parameters or expected results.
  • Check -lines are where I tell the tester to check process important points that otherwise might go.

Test document Check -lines have two functions:

  • It’s easier to spot the defects that show up. It’s very difficult to spot what’s missing. For example, if the subtotal is not correct in the print out, people usually notice it. It’s much more difficult to notice, if the subtotal is missing altogether. Also, all events in which people have to use another view to check, might go unchecked.
  • Things that need checking based on risk analysis.

Behind all these examples there’s a case, where the client’s personnel were testing. The testers were business professionals, not software testing professionals. These test documents in the examples were something these people could write themselves, and while doing that ensure that the solution supported the business as well.

Jyrki Autio

CEO of Projecttop He’s often hired to save projects that are far behind schedule, are going over budget, or aren’t meeting quality standards. He also commonly trains people in specialist and consulting companies that sell project management or software development services.