In the fast paced world of business intelligence, there are many tools available to the user manage one’s data and make the moves necessary to stay ahead of his or her competitors. It’s safe to say that these tools did not materialize out of the ether, and they certainly were not created by some cyborg master program. They were all created by people with years of programming experience. However, a part of the development process that doesn’t often receive enough praise is the Quality Assurance portion. Sure, we all want our programs to be functionally superior and user friendly, but how does one actually test the functionality of a product the right way? That was the impetus for today’s piece.
First of all, let’s define “Test Script.” A Test Script is, at its most basic, a set of instructions that, when completed, will show whether the functionality of a product is doing what it is supposed to.
To start off, build a test to make sure that the program works before the changes are being made, then change it to test the objects that will be added or amended. This part can be done on a sheet of paper or white board.
Once you’ve got the basic idea of what needs to be done, it’s time to create a Test Case. The test case needs to be extrapolated into a more detailed plan that can either be on paper again, or entered into some sort of testing/development dashboard, like TFS through Microsoft Visual Studio. The case should be simple enough that most anyone can follow it, but thorough enough to accurately test the program.
To get started in TFS, connect to the iteration that the case will belong to. You will either be working with a backlog item or a bug, so select the object you want to test, and link a new work item (test case) to it. You can now either click “Open for editing,” which will open the case in Visual Studio’s testing harness so you can write detailed steps, or simply write your script in the test case summary field. Depending on the complexity of the object you’re testing, either option will work.
It’s important to document the status correctly of each test and backlog item so that when your support department gets an angry call from a customer or a general question from management, the status of the bug or backlog item will be easily available.
Now that you have your test case, go into your testing environment and follow your steps. If the test works, and the product functions as designed, go ahead and close your test case and set the backlog item (assuming there aren’t any other outstanding components) to complete. This will show all concerned that the feature is done and you can move on to the next item!