Finding an appropriate automation model, which uses a microservices structure and adequately met our needs, was something of a Darwinian process.
Examining some of our mistakes may help you avoid them:
Define terminology as it applies to your product
- One of the fundamental mistakes we made was assuming that everyone shared the same definition of QA terminology. Being a QA Engineer, you are used to hearing developers discuss highly technical subjects and having only a limited understanding of the discussion. Developers probably aren’t used to being that position, so they’re also probably reluctant to admit they have little more than an abstract understanding. This will cause problems if they have input on the testing process.
- Don’t wait to be asked. Take the initiative and define the terminology and get consensus on what the terminology means. It doesn’t matter if it’s meaningless to the outside world. What matters is that everyone within your team speaks the same language and has the same understanding - not just the same abstract understanding, but the same actual idea of how an idea is applied.
Your customer is also now development, not just the end user
We relied too heavily on acceptance criteria. In the manual test definition of Feature Complete (FC), FC was achieved when dev had implemented a feature. One relies mainly on acceptance criteria if they exist, test notes to determine impact (& instinct). In the automated definition of FC, FC is achieved when a feature has been implemented and it’s accompanying unit tests and acceptance tests have also been implemented. Testing starts a stage earlier in the lifecycle. Development and Test stages are no longer separate. Therefore Test prep meetings will be of great benefit and you should have one for every Feature.
Meet with developers to refine acceptance criteria, to determine the type of test required, test data required and impact
Try to establish clearly what development want and what you think they should want
Don’t assume you have the same goal or method in mind. As an automated tester, you are likely to be the least experienced developer on a team. You are also probably informed by your manual testing background (probably the most experienced tester). This will influence your approach to automation - most likely you will begin with a different set of objectives than a developer would and consequently a different model to achieve it. This will cause confusion.
Bear in mind that Developers may also be trying to learn how to think like a tester. Try to get some prototypes or applied models in place. Do not rely on abstract understanding or blog posts. You need something tangible. Then discuss based on that example. This will help to eliminate the confusion.
If architectural changes are required, ask for working prototypes to guide you if possible
Do not go too long without input from Development, especially in the early stages of a project
If developers are busy working through their own workload, they may only briefly look at a pull request. If consensus has been achieved and a suitable model has been chosen, this won’t be a major issue On the other hand, in the earlier stages of a project, it’s more likely that everyone is still trying to determine the right model.
Therefore, at least in the early stages of a project, do not assume that because you did a pull request, your code/model suits everyone. The sooner you get input, the less work you will have to refactor. It’s better to take a proactive approach.
Big Changes should only occur based on consensus
If you make big changes based on individual suggestions, eventually you will not be able to cope with the level of refactoring, not to mind developing new code.
This will leave you confused and leave you with very brittle tests
Consensus is a must: Pull Requests are not the place to decide on architectural changes.
A code review doesn’t guarantee you will find the right model, but it’s vastly more sustainable than trying to achieve the same thing through individual conversations and pull requests. Do not make significant changes based on individual discussions (or pull requests). Get consensus first.
Find a styleguide (or make one).
Aut viam inveniam aut faciam
Study Test Driven Development
Try to get developers involved in testing
- A developer educated in the tool you use to write tests will have much more helpful and far more relevant suggestions & will be able to help you improve your coding skills far more efficiently.
Take Extreme Ownership
Be ready to learn - you were probably a master of manual testing but you’re a student again
Keep an open mind - there is not necessarily a direct process translation from manual to automated test.
If you cannot seem to find the right model or achieve consensus: Consider that your approach may just be wrong or examine where you have failed to communicate & try again
Don’t lose sight of the goal
- Just because you are automating stuff now - doesn’t mean you’re too good for a bit of manual testing. At the minimum, do a manual test pass before accepting a new feature for validation
- With so many more factors to think about compared to manual testing, it can be easy to forget, that ultimately, it all comes back to this:
Image sourced from http://helicaltech.com/