There is multiple different reasons for this. I will try and explain a few.
- If the tester is unfamiliar with the system it ensures they are performing the steps correctly
By giving the tester expected results at each step it allows the tester to easily be moved from one application to another. This makes cross training a lot easier. It also helps with allowing the tester to know that the results they see are the results that they were expecting to see at that step. For example, if you are testing an API that you are unfamiliar with it would be difficult to determine if the response returned from a set up step was the response expected.
- End to End verification of all functions
By having the expected results in each individual step it assists with end to end verification of all functions within the system and makes it easier to determine if all of the system's class and functions were hit when testing. This helps to ensure that testing was thoroughly performed especially during the planning and test writing phases.
By having expected results and often times, actual results, it helps to remind the tester that they may need to input data to verify that what was returned is being put into the test tracking software. This assists when it comes to defects released into production that had already been thoroughly tested during the testing cycle and somehow popped out in production.
Often times these test cases are linked to defects. The defects can be viewed by Product owners who don't know the steps they need to perform well enough to duplicate the defect or even to developers who might work on an external system that is causing the defect in yours. By giving the verification steps and letting people see exactly what they should expect and what the tester saw you are laying the path that is needed to expedite defect resolutions and ultimately ensuring a better quality system overall.
This is hinted to in the first benefit but by having this it greatly assists in giving the details needed to be able to thoroughly test it if something was to happen, like a tester being hit by a bus. You and your bosses never know what could happen and by putting extra detail into your planning you, and they, are protected from a worst case scenario as much as possible.
It's a great practice for several reasons, it's a bad practice because it takes a few extra minutes. Trust me, spend the extra time during planning and save everyone's time in the long run.