Have you ever wondered about how many test cases you have written in your career? Can you imagine the number of test cases written by everyone in this field? There must be a way to leverage that knowledge. How do you reuse test cases and the knowledge that has created them? In this article, Paul Sixt tells you how to do just that!
This was a problem unlike others that I had faced. We were going to test an entire family of products, from the low end all the way to the Cadillac model. This was exciting, getting to learn the product family, have insight into each member, and be able to write test cases for each member of the family. Ok, this doesn't sound fun anymore. Trying to contain our excitement at this thought, we decided to invest some time trying to figure out the difference between each family member and how the different members were alike and different. What we found out was each generation was the same feature set as the previous plus new or expand features. Thus the product was an accumulation of features. The same feature once introduced could be tested with the same test cases for all following members.
A database seemed the most reasonable solution for our problems. We chose Visual Basic and Access due to experience, they were easy to obtain, and affordable. Now that we had decided on the tool set, we needed to work on the design. We started on the database, seemed to make sense since that would ultimately drive the GUI. The problem was how to create the database without duplicating the data. We needed a simple yet flexible database.
The hard part is trying to keep the test cases without referring to any particular member and yet still be clear enough to cover the action and expected result. The real beauty is we reduced the effort of writing test cases to writing the test cases for the most complex member only. With most projects where you share test cases, an enormous amount of time is spent making the same correction for every member, you never get them all. We eliminated that issue, a single manual correction was made and it was reflected everywhere it was used. No guesswork! We also worked on adding new members so it could be completed with little effort. Again, once the initial member and test cases were entered, we were able to add new members and define what their features were. We had the test cases completed within an hour.
The relationship that is built in the Scenario table is what drives the system. We defined each member by a set of features. This is represented in the Table labeled Scenario. If you'll notice, we also used unique identifiers to build the relationship instead of the textual name. This is because the names were constantly being modified. With this system, a single change on the members name and it will be updated everywhere without much effort.
Each feature is defined by the set of test case that are related to them. This is represented in the Test Cases table. We also added a unique ID for each test case. This was to cover a previous database design. Although currently not being used, we could imagine enough different scenarios and future enhancements that could take advantage of it so it stayed. The actual test case reports are based on the relationship between members to features and then features to test cases. This allows us to print the test cases by member or by feature.
The First Hurdle and Feature Creep
One of the curves we encountered was editing test cases because the feature changed or was removed. So we built some new interfaces to be able to manage the editing of the different aspects. Editing the member name or feature name was simple. A single straightforward interface to handle those was quickly