Part 8/11: Optimal Structure for End-to-End Test Cases

Blog post series about testing development projects, part 8/11

Articles about planning software testing and managing it.

Point of views:

  • Business critical development projects, where IT plays a strong role.
  • One or more outside vendors.
  • Client’s business personnel as testers. They are business professionals, not software testing professionals.
  • Goals for testing:
  1. Make sure that the implemented solution supports the needs of the business.
  2. Make sure the implementation doesn’t endanger the business.

Acceptance testing carried out by the business

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 and documenting the testing. Especially when testing whole processes, ergo.End-to-End (E2E).

Two things worth noting:

  1. Testing is not training, even if it is educational.
  2. Test document is not a manual, the testers should know how to use the system.

Optimal test case for testing business processes?

I used to see a lot of test cases created according to the vendor’s instructions with detailed testing steps. Whatever minefield the process was, testers finished the test case 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 is guiding to test the technical functionalities, not if the solution is supporting the business.

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

E2E Test case to ensure that the solution fits the business

When testing whole processes, there are many people executing the test.

For example: Sales sells – Warehouse delivers – Billing invoices – Accounting checks the books

In E2E test cases, the tester should be told:

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

Structure I like to use in E2E test cases:

Test case front page information

  • In planning testing, they help with choosing the right test cases.
  • Scheduling guides to 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

Test document steps

Here’s an example of a 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 what functions have been tested.
  • Description -column tells what function should be executed.
  • Tester/role -column tells the tester’s role, who is testing.
  • 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 get unnoticed.

Test document Check-lines

Test document Check -lines have two functions

  1. It’s easier to spot the defects that are showing. 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 people have to use another monitor to check, might go unchecked.
  2. 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.

Recent articles

ProjectTOP - Platform for managing development

Platform for project management and all development work for businesses and the public sector.