Hello. My name is Fernando Kramer. I am with Perforce (formerly Seapine Software). And, on this video, I'd like to show you how to author test cases in Helix ALM.
Before we do that, let's review what constitutes a well-written test case. A well-written test case is clear and concise. It provides just enough details to be unambiguous. It also doesn't assume special knowledge. The goal is tester independent test cases. For small and experienced teams, this may not seem like it's needed. But, what happens when new members are added to the team?
It also has a specific goal. What is the point of the test case? What are you trying to prove or disprove? Are you asking a question that can be answered with a simple yes/no answer instead of an essay? Different types of test cases will have different goals. It also states its assumptions. Testing doesn't happen in a vacuum. Test case steps are only part of the instructions necessary to run a test. If you haven't set up your test environment correctly, you will have invalid test results.
A well-written test case also identifies its source. Which requirement does this test validate? Traceability goes both ways. This information may be required in some environments, which have to document compliance. It's also categorized. What type of test is this? Properly categorizing a test allows for better organization and metrics. It also has an estimate of testing time. An estimate not only helps us with planning, but provides a sanity check when it's time to run the test that the instructions are being interpreted correctly, and the test is going as expected. And lastly, it has a status. Is the author of this test finished? Is it okay to run the test now?
Now, let's talk about authoring test cases in Helix ALM. This is done using a DCM license, which gives you access to test case functionality. Here, I have a requirement document for an upcoming release open, and I have a functional requirement for a new button we will add to the application. I want to create a test case that will verify that the button does what this requirement indicates. I'm just going to right click on the requirement and choose Generate Test Cases. While I'm doing this, for a single requirement, keep in mind that you could do the same for multiple requirements, if you just have Multiple Requirements selected.
Here, we have the test case generated from Helix ALM, and as you can see, it already has some data on it. Helix ALM copied data from the requirement for me, so it eliminates the need for double-data entry. So, here, we can see that it already has a summary, and the product, and component are already filled in. If you go to the Links tab, we can see that it also has been linked to the requirement. This allows me to indicate the source for this test case. So, from here, we can open this requirement just in case there are any questions. This also gives me traceability between the requirement and the test case.
Let's go back to the Detail tab. And, here, I'm going to fill out the rest of the test case. And, first, I'll go ahead and add more detail to the summary to ensure that its goal is clearly stated. This is something we talked about at the beginning of the video. I'm going to give this test an estimate of how long I think this test will take to complete, and I'm also going to tag this test case, so everybody knows what type of test case this is.
Under Description field, I'm going to make sure I provide more details on the test. And, on Scope field, I'm going to indicate that this test is only for Windows. Under the Pre-Conditions field, I'll say that this application must install on a clean Windows 7 image. This is an example of what I talked about in the beginning of this video, and making sure the environment for this test is currently set up.
Now, we're ready for the steps. So, on the first step is to open the application, and I'll tab over to the next cell, and enter an expected result. The next step is to click on that button that we're testing, and I'd like to eliminate any guesses by the test running by I'll including a screenshot of the button. However, the application doesn't exist. If it did, I could just open it and use a screen capture tool. If I had a mock up from a developer, I could browse my computer for the file. In this case, I'm just going to go back to the requirement. It contains already a screen mock up, so I'm just going to copy it. So now, I'm just going to go back to the test case, and here, I will just paste the image. The last step is to verify that the correct window appears. Here, I'm going to add a note to this tab. Since this tab is what the test is all about, I want to ensure that the tester fails the test if anything other than what is stated happens. So, now, I'm ready to save the test case.
Now, let's talk about the workflow. If you are familiar with Helix ALM, you know that it has a configurable workflow. So, your workflow may look different than what I have here. For those of you that are not familiar with TestTrack's workflow, it has two main components; states and events. The states are the various statuses than an item goes through. And, events represent user actions and they update the status of items, performance time ends, add comments, and more. Here, you can see some buttons, and these buttons represent events that are available for this test case.
In this workflow, the test case cannot be executed unless it is reviewed and approved. So, I'm going to send it for review. I’ll have Carl Jones review the test case, so I’m assigning it to him. He also provides some basic instructions so I click OK. Notice that when I do, the status is updated to Ready for Review. So, now, next time that Carl logs in, he will see this test case assigned to him. He's likely to review to Detail tab, go through all the fields. Also, he's likely to go through the steps, make sure they make sense. And, on the Links tab, he will probably open the requirement and ensure that the test will properly verify what's stated in the requirement. Here, he can approve it for use or he can reject it by using the Needs Change event.
Let’s say that the test case looks fine, so if he'll do the Approve For Use event. He’ll indicate some notes as to why he's approving it. And then, he can click OK, and as you can see, the status is now set to In Use. This workflow is configured so that test runs can only be generated when a test case is in this state. And, for those of you not familiar with Helix ALM, test runs are instances of a test case that represents a single execution of the test case. So, this test case is now ready for execution.
If you have any more questions about Helix ALM, visit our website.