Test Objects and Test Data
Test Objects and Test Data
click here to read this article from the beginning …
The above test case should check how of the user’s phone is edited. However, the first three steps do not refer to editing the phone number in active directory. These are auxiliary steps to create a user – we create a test object, an object that we will use in the tests. It is advisable to include these steps in a separate ‘Setup’ section, and describe more briefly the following:
Setup:
Create a new user.
Step 1. Open the list of users.
Step 2. Select the user in the list by clicking on his login.
Step 3. Click the ‘Edit’ button.
Step 4. Enter the phone number in the ‘Home phone’ field.
Step 5. Click ‘OK’ button.
Expected result: the home phone was saved in ActiveDirectory.
The Setup section, like the Expected Result, can also be turned into a link to page of the corresponding instruction. Thus, we will save ourselves the trouble of duplicating information in different tests and at the same time improve the readability and maintenance of the tests if something changes in the system. In general, the process of writing and maintaining test documentation has much in common with the procedure of writing and maintaining software products. At that you must avoid duplicating and pasting code but write a new one.
All readers of our articles get the chance to keep in touch with best software testing companies and, as result, arrive at best solutions and have better control over processes to ensure higher productivity of existing development teams and releases!
In many cases, the same test case should be run with different test data. For example, if the program should be able to display a BMP, JPG and GIF files, it is logical to write one test case and specify in a single section that it must be executed with three different file formats. Similarly with programming – we add the name of the format to the procedure parameter. This is called a data-driven test case.
The test documentation should be written in such a way that it can be maintainable when the product undergoes changes!
We can say that a good test documentation provide a high-level description of actions, which has links to a step-by-step description. Such documentation is useful for experienced (familiar with the product) testers, and inexperienced ones or outsourcers. Experienced testers do not need to spend time reading step-by-step instructions (as a rule, they already know them), and inexperienced people can always read them.
If the task is to write the test documentation in the shortest time, you have to choose between a step-by-step and a high-level style (without references) of writing the documentation. Typically, you should choose high-level writing style, because, first, it allows you to communicate correct technical information faster, and secondly, in a document written in high-level language it will be easier to create a link to step-by-step description in the future than to refactor step-by-step instructions.
