Practical Steps Devs Can Take to Make Test Automation Easier For Testers
There are a variety of practical steps developers can take to help developers and increase a team’s overall velocity. Let’s review some velocity-increasing ideas!
- Include the tester in feature development meetings
- Assign testers early in the development cycle
- Include testing in your estimation
- Have developers code for easy testing
There are a variety of simple, low cost ways that developers can make test automation easier. When the dev / tester collaboration is strong, simple things can create massive time savings and value.
Making Testing Easier
Give DOM elements unique ID’s!
Adding stable ID’s is simple, but avoids a scripting nightmare with CSS or Xpath that needs to “guess” or depend on page structure when finding an element
Assign class names, even when you don’t have CSS to target an item!
By expressing class names with semantic meaning, it makes tests more logical and understandable.
Add a data- attribute can provide a helpful way of targeting an item!
If a tester is having pains targeting an element, sometimes a data-attribute that doesn’t affect any else can give a simple way to target the element.
For API’s, provide the Open API spec to the tester beforehand
This often lets a tester get a running start before the API route has even been coded.
Load Testing / Performance Testing
Keep the tester in the loop for back-end changes that might be invisible, but have a performance impact.
Knowing when to test is sometimes as important as knowing what to test. For example, did you change the frequency a JS timer is using to poll the back end? Did you add websockets to a page? Add a new footer that loads in a separate request? All of these items can have a load impact, and if the line of communication is open and the tester knows these changes happened, tests can be updated appropriately.
Share knowledge about the caching scheme.
There are two main benefits to sharing knowledge about the caching scheme:
- When measuring baseline page performance, first time response for a cached item might be “very slow” whereas repeat access to a cached item might be “very fast.” Knowing where these differences will be seen helps the tester plan how to verify the SLA is met.
- When designing a load test, it is important that the cache gets exercised in a realistic manner. By knowing how the cache operates, the tester can make a data-driven test that mimics real world load and performance more accurately.
Communicate what should be tested.
For example, if the orders page is now loading the status of every order, that extra server load might merit a new load test.
Communicate what shouldn’t need testing.
If the load effect of a change is minimal, like styling updates, maybe a new test won’t be needed.
