Moving From Manual to Automated Testing at a Small Company
If your company wants to implement test automation but isn't sure how to start, these steps will point you in the right direction.
Join the DZone community and get the full member experience.Join For Free
The obstacles of moving from manual to automated testing include
Too busy running manual tests
Put automation off until the "next release"
Company culture is not open to change
The company is not sure about the investment
Not enough knowledge or experience to implement
Not sure how or where to start
Now let's talk about the steps to go from manual to automated testing.
Step 1: Build a Good Test Case Foundation
Why create a good test case foundation? Good manual test cases are blueprints for what you will and will not be able to automate.
Explore automation framework options.
Aim for goodness, not perfection.
Test cases will evolve and change as you dig in deeper and learn more.
Pick a tool to store and organize your manual test case. This can be as simple as you need.
Common test case storage options:
Option 1: Documentation-only examples
Excel sheet (Microsoft, Google Docs)
Option 2: Software tool examples
Manual test case organization considerations:
- The option should include tracking which tests can/should be automated and what has been automated.
- Are you planning on storing test results and/or test plans with your manual test cases?
- Create a wish list (need to have versus nice to have)
You can start simple and then import your list into a more complex tool if needed. Here's an example test case management tool wish list example:
Step 2: Explore Automation Framework Options
By automation framework, I mean what your tests are coded in that will run the actual tests. For example, the framework is what will actually send the test to the Selenium Server.
If you don't know what frameworks are available, ask resources around you, like development team members, QA folks in professional organizations, QA/tech mailing lists or forums, Slack groups, Twitter experts, etc. Narrow down your list to about three options and create a matrix that compares each option. This could include building your own framework.
Framework options and examples include the following:
- If you are using Selenium, you have some great options: Java, Robot, Python, Ruby, Cucumber (and many more). These can be hosted or self-managed.
- Many Selenium hosting providers give you "wizards" that will help you set up framework environments that will work with the solution.
Step 3: Explore Infrastructure Options
Ask yourself, what hardware is needed?
Servers: physical, self-managed virtual machines, cloud-hosted
How will the hardware be installed? Maintained?
What software is needed?
Buy versus Build versus Hosted
Versioning strategy for the manual and automated test cases
Will the automated test cases exist in the same repository as the project code?
Step 4: Make the First Choice
After you have proven to yourself that your approach will work, it's time to get the team to buy in on your solution.
What is the quickest way to get to Proof of Concept (POC)?
Develop a good plan and get moving
The plan should include a real date for a PoC
Many times you can take advantage of trial membership for some testing products and tools (if you need the trial extended, just reach out to the company and ask).
Have at least one backup plan in case the first choice does not work out.
Step 5: Start Simple
What is the simplest way to implement your framework approach using your actual product? As a Selenium example, can you use Selenium IDE scripts to confirm assumptions about product testability?
Step 6: Confirm That Your Choice Works
Go beyond the simple checks you have performed. Confirm that your choice will work in your specific environment. Many software providers will allow you to sign up for trial accounts so you can take a closer look. There is no harm in asking for an extension on a trial account if you needed more time for analysis.
Step 7: PoC for Team Buy-in
- The Proof of Concept (PoC) is a chance to share your results, recommendations, and excitement with the larger team.
- It's best to show a live demo if possible.
- Have dates and requirements for implementation.
- It's helpful to have metrics or other supporting details to exemplify why the team should go for test automation.
Step 8: Implementation
My automation implementation:
- Git: a QA repository containing test cases, test queues, and Vagrant/AWS configurations.
- Jenkins: takes the QA Git repository and deploys it on a Linux system based on the config settings.
- Linux system: launches the Vagrant/AWS system and executes Robot scripts.
- Testing bot: Robot scripts are executed against the Selenium server(s) and the internal Vagrant/AWS system.
- Slack: posts test results from the Linux system to the team. This is broken up between pass and failed test results with emojis.
Published at DZone with permission of Jefferey Dunn. See the original article here.
Opinions expressed by DZone contributors are their own.