While determining the quality of any test case, the expected result plays a vital role. In this article, we will discuss five common challenges you may face while writing the expected result. This will help you overcome some of the difficulty in test execution:
First of all, in theory from requirement specification, we derive the test objective and if the specification is perfect writing the expected result should not be a big deal. But in reality, is it like that? Let’s check one example. The requirement says after the “operation A” successfully completed a file should be generated. It sounds perfect! But how the tester would determine that the file is created successfully? Is it going to be listed in a log or can we open or edit the file? So you can see a simple well written expected result is not that simple while doing the actual test execution.
Second, you may face the situation where the requirement does not clearly tell you what would be the outcome of the test. In that case, you need to reply on the experienced tester, who is essentially a SME in that application domain and worked in similar kind of project. So from his past experience he knows what is most likely to be happened when a certain operation is done.
Third, also depending on the type of the testing you are performing, the expected result may become a challenge. For example, while testing some usability attributes such as “ease of use” of the product, you need to be very specific. If no documentation present on that, make sure you define your own by finding industry starndards from Internet and get it reviewed by the client or business analyst team.
Fourth, sometimes you cannot exactly put the expected outcome at the start of the testing. This is true for performance testing. Here the purpose of test can be to determine the expected response time of an application when 2000 users are online at the same time. So here expected result cannot be written upfront. After doing the first round of testing you found the actual response time is 5s. Then you can baseline that and going forward use it as an expected result for the same kind of testing.
Fifth, in one more similar situation, you are doing say the capacity testing of one application. In one hour say it can create 400 VLans, and you put it as the expected result. After the execution of the test, you found it actually did create 400 Vlan but the total response time of the system went significantly down. So does it mean the expected result is met, and test case can be passed. So again you need to determine multiple parameters in the expected result such as memory usage, CPU % etc. along with the original requirement to say it is fine.