At my company we recently had two projects that took different approaches to level of detail in testing.

Project 1 took the detailed approach for both instructions and expected results. Things like:

• Click the OK button
• Select widget X. Drag it into pane Y. (In this case, there were multiple ways of adding the widget to the pane, but the offshore testers almost always wrote it the same way.)
• The dialog closes. (Usually the dialog close functionality was not the actual subject of the test, and later things would have failed if the dialog hadn't closed.)

I was on this project, but I didn't like this approach. We were constantly receiving dry run feedback on tests about "missing instruction to click OK", and other little things that didn't relate to what was being tested, but caused confusion since they didn't match the level of detail of the rest of the testing. It was often difficult to discern what was actually being tested since there were so many details. And if even a little detail of the design was changed? Lots of rework.

Project 2 took a more high-level approach, but with a twist. The tests themselves were very high level. Things like:

• Add widget X to list Y.
• Create a new widget.
• Configure widget X to have wings and breathe fire.

The twist was that there was a separate document that gave detailed instructions for many of these high-level operations. Individual tests could focus on the particular feature being tested, and testers could refer to the other document if they didn't know how to perform an operation. This made it easier to read through a test and understand what it intended to test, and also made updates much easier since design details were in fewer places.

Of course, if a test was actually testing creating widgets, the instructions would be more detailed and include expected results along the way. But most of the time having some widgets available was just setup for testing something else later in the protocol, so it didn't add value to confirm creating a widget worked correctly every single time a test needed to create one.

TL;DR: My group has had success with writing tests that only specify high-level operations, while maintaining a single, separate document with more detailed instructions for many of those high-level operations.

At my company we recently had two projects that took different approaches to level of detail in testing.

Project 1 took the detailed approach for both instructions and expected results. Things like:

• Click the OK button
• Select widget X. Drag it into pane Y. (In this case, there were multiple ways of adding the widget to the pane, but the offshore testers almost always wrote it the same way.)
• The dialog closes. (Usually the dialog close functionality was not the actual subject of the test, and later things would have failed if the dialog hadn't closed.)

I was on this project, but I didn't like this approach. We were constantly receiving dry run feedback on tests about "missing instruction to click OK", and other little things that didn't relate to what was being tested, but caused confusion since they didn't match the level of detail of the rest of the testing. It was often difficult to discern what was actually being tested since there were so many details. And if even a little detail of the design was changed? Lots of rework.

Project 2 took a more high-level approach, but with a twist. The tests themselves were very high level. Things like:

• Add widget X to list Y.
• Create a new widget.
• Configure widget X to have wings and breathe fire.

The twist was that there was a separate document that gave detailed instructions for many of these high-level operations. Individual tests could focus on the particular feature being tested, and testers could refer to the other document if they didn't know how to perform an operation. This made it easier to read through a test and understand what it intended to test, and also made updates much easier since design details were in fewer places.

Of course, if a test was actually testing creating widgets, the instructions would be more detailed and include expected results along the way. But most of the time having some widgets available was just setup for testing something else later in the protocol, so it didn't add value to confirm creating a widget worked correctly every single time a test needed to create one.