Test automation is seen as the way to make testers more efficient and productive for doing their job. It’s also known that you can expand your test coverage greatly by automating nearly all permutations of a given scenario. For large project teams and large releases, automating your testing is the only way project schedules can be met.
Test automation solutions come with a misperception though. A number of solutions require you to have a programming and development background or skillset. But this is not a skillset most manual testers possess nor want to. Often there is a divide between the manual testers and automated testers as these are now two different jobs.
So what kind of bridge can be built across this gap of the two different roles? How can the automated testers get more useful information from the manual testers? How can the manual testers be more productive with what they can contribute to the automation effort? It starts with understanding the automation structure and framework.
Whether they are writing the actual test automation test case or not, manual testers can be productive immediately by understanding a few key points: What are the key categories that a manual tester can be effective instantly with test automation?
This and the following blog posts will focus each on one of the three main categories of work for test automation. These are Preparation, Execution, and Analysis. Within each of these three categories, there are three key points in each that cover the full category, which will be explored in depth.
- Introduction
- Categories for test automation
- Planning test automation activities into your test process
- Creating data sheets or SQL statement for data-driving your automation
- Editing existing manual test cases for automation
- To be continued…
Introduction
This blog post has been developed with the premise that there may be elements of test automation existing in your environment. Test automation largely has been considered to be a development activity without a clear understanding of where a manual tester can contribute.
This manual tester may have technical skills, but not a development or programming skillset. But as you’ll see within this blog post, there are many ways where a manual tester can add value to the test automation process.
For example, there are challenges from the test automation engineer’s perspective to get better requirements or test documents from the functional tester and there are challenges from the functional tester to have the automated test case meet the same criteria as a manual test case.
Some other key assumptions is that the majority of test analysts are still performing a manual testing role. However, they would participate in the automation effort without being fully dedicated to the test automation team, as outlined in the points below.
Categories for test automation
Below you will find an outline for the three different categories for manual testers to break into test automation: Preparation, Execution and Analysis. Within each of these categories there are specific sections where manual testers can provide immediate contributions. This blog post will cover the first mentioned category, “Preparation”. There will be additional blog posts covering the other two categories in the near future.
Planning test automation activities into your test process
QA organizations have defined testing processes, primarily without the incorporation of test automation. Methodologies stem from an Agile, Waterfall or other SDLC methodologies. Largely, this serves the need for the manual testers. In most cases, there is not an integration of the test automation activities into the manual process. To illustrate how these activities could be mapped, a simple V-Model is used. However, the incorporation of this planning shouldn’t differentiate between an Agile or Waterfall SDLC methodology.
Project Initiation ? Test Strategy
It’s recommended that QA release leads own the inclusion of test automation activities within each of their releases. It’s unrealistic to think that test automation activities can occur for longer periods of time without impact to project schedules. If you list out the test automation activities for creating or executing automation test cases within the Release / Master Test Plan or Test Strategy document, your Project Manager / Product Owner will have visibility on planned automation in the given release.
Analysis ? Test Scenarios
As manual test analysts are drafting their test scenarios or test objectives during the analysis phase of their project, they should divide the scenarios between manual and automated. Project stakeholders will know their objectives and can plan for good coverage on each.
Design ? Test Cases
Typically, manual test cases are not written for certain error-handling conditions that automation requires. Considering this in test case preparation will enable the manual test cases for automation.
Develop ? Test Scripts
Record your automation test cases with the same principles as you would write your manual test cases. Ensure that you are recording slow enough to recognize all objects you are interacting with.
Testing ? Test Results
Unlike manual test case execution, automated test execution may require replaying the test several times and making tweaks and modifications to make the test run as expected.
Deploy ? Test Summary
Similar to the Test Scenarios document, list out what was executed with automated test cases vs. manual test cases. This information is listed in the Test Summary document prior to deployment.
Creating data sheets or SQL statements for data-driving your automation
In many cases, the test automation associate is not the subject matter expert (SME) in the application under test (AUT). The functional test automation analyst knows the UI, as well as the underlying database tables and fields. It would be in the best interest from all team members to utilize the knowledge the functional test analyst has for using dynamic data within the automated tests.
It’s also important for the functional test analyst to know a typical process that a test automation analyst would follow. Knowing this helps provide a common understanding of how the test automation test case is formed and when the dynamic data elements are needed. This is a three-step process:
Create a variable on what you want to data-drive
There are values where the automation test case will either select or input data to the respective field. This data is static or hard-coded unless driven from a source. The test automation associate creates a variable instead of using the original value so static data can be substituted for dynamic data.
Link to your data source where the data resides
Test data should reside in a central, secure location and the test automation analysts can link data from various formats: Relational Databases (RDBMS), Excel spreadsheets or CSV files. The functional analyst should select what’s easiest for them, but try to use the same data source for all of their data-driven tests. This could reside on different data sheets or tables, but the connector that the test automation associate uses will be the same.
Map your data source columns to the defined variables
Once the variables have been defined for the fields and the data source, connecting the data source fields to the variable fields should be straight-forward and essential. This must be done to have the correct mapping on data elements.
Editing existing manual test cases for automation
Most QA organizations have hundreds, if not thousands of manual test cases they would like to be automated. But chances are many of these have not been written in a format suitable for automation. The functional test analyst should not worry about editing the overall test case as there are just two areas that should be focused on for editing: Test Steps and Test Data. Test Results are not important at this stage.
Test Steps
The test steps are the items that map directly to either the recorded steps, or to the created steps from the test automation analyst usually through code. Every step must be accounted for; no implication that the automation will know what step to do next. Also, the wording used in a typical manual test case is not needed for the automation test cases. If a keyword-driven automation framework is used, limiting the wording is preferred.
For example, a manual test case may have a step phrased like this:
- Click on the City field and input the following state: ‘Florida’
The automation test case could have the same functional step, phrased as the following:
- Action – Event – Object or Repository Item
- Mouse – Click – CityEditBox
- KeySequence (Input) – Florida
Test Data
As mentioned in the section above, data-driving the test is a best practice. Just as hard-coding data within development code is to be avoided unless absolutely mandatory, hard-coding data in tests should follow the same practice. Of course there are times that having static data elements may be beneficial to the test, but overall, this would be better to have an external data source for maintenance. In this instance, the responsibility is shared between team members. The test automation analyst is responsible for maintaining the harness and the functional test analyst is responsible for maintaining the data.
Test Results
The reason why this is not listed as a step required for edits and maintenance is that you can rely on the test automation solution to provide all of the test results automatically for you from the execution run. Not only will this be a more reliable source of information, but also will provide much more meaningful data. It’s a best practice to separate your results from your planning information. Usually you will have red-flagged or a failed test result if a test step or validation does not match, green-flagged if everything proceeded as expected.
To be continued
This was the first part of “How Manual Testers Can Break into Test Automation” covering the test automation category “preparation”. Blog posts covering the other two categories will follow soon, so stay tuned if you are interested.
