13,420
edits
Changes
no edit summary
You can spend an infinite amount of time running tests and stil not prove anything definitively, so you have to do your best to make sure the tests you run are representative of the requirements - that after a successful run of all the tests the service is almost certainly working correctly.
=== Identifying Test Case Failures ===
Test cases (in a test suite, in a system that keeps track of them) are not intended to only show that the system is working. It's equally On the other hand, it is valuable to see view a history of problems or failures that at some point have occurred in the past there was a problem. In that case For those situations, there may be a bug tracking number or some other means of tracking down what caused the problem in the past and how it was fixed. So recording failed test results is just as important as recording passesThis can help provide quick identification of problems to lead to quick resolutions in case those similar situation occur in the future.
== Create Test Cases for Your task VM1 Machine ==
When I check your lab - I normally ask you to run some commands, and I'll ask you some questions, and that is a sort of made-up-on-the-fly test suite for your lab. Let's formalize that for one section of one lab in a set of test cases.
