You know you want to create an automated testing framework. Perhaps you’ve even identified a tool, or are already working with a tool (Squish?).
Next step, automate.
Stop, not quite.
In order to get the most value of your time, or ROI on your framework, plan before creating any test cases.
First: Think, not too hard, what manual test do you have to perform each release, or point release, that you absolutely dread? That mind numbingly repetitive task that can’t be skipped, you just hate doing, and takes what seems like forever (or longer)…
OK, now in your application, how often does that repetitive set of manual tests undergo dramatic change?
Rarely? Good (if not, pick another, we’ll wait).
You’ve just identified the first portion of your software to automate.
Wait, we’re not done yet.
You know where you’re going to start, but how are you going to approach it? For example, do you verify each menu across the title bar of your application displays the expected result without issue?
What common action(s) do you take, no matter which menu & menu-item combination you test?
Great! Those are your first Test Suite Resource script functions.
Some related reading:
- Start simple.
- Don’t try to record everything all at once.
- Record in segments or snippets.
- Each test should have a single purpose or goal:
This test verifies dialog X appears as expected when button Z is pressed.
Now have fun with it. Getting started, while challenging at times, can be some of the most exciting and creative design portions of building your automated test framework.