There are a lot of things to consider when creating automated tests:
a) environment; is it integrated and so what else will it affect.
b) data; how do you want to ensure the data is correct, is there an api or database you can use to create it before running the tests? Or even a docker instance with the data already created.
c) maintenance; how to keep maintenance of tests at a minimum. A good Data creation strategy will help with that and depending on your tool, e.g. selenium, you may need to create a good wait system. The newer javascript frameworks take care of this problem for you. But also what are your selectors, can they still locate the element if it moves within the domain object model? What about using ai to find elements?
d) clean up; do you need to erase all the data or drop the database at the end of testing? Or do you spin up a clean environment every time your tests run?
d) and on and on e.g. what and how do we report, how many tests do we want to run in parallel etc.
However, the aim of this article is not concerned with the above, as I would expect a good automated tester to consider those.
The article’s focus is on: when do I consider you can begin to think of yourself as venturing into senior territory.
The answer is when you begin to take an overall view; i.e. who else is using your framework and how does it fit into your organisation’s attempt to create a product without serious bugs. Once this occurs, the following things will begin to be thought about:
a) is it easy for another tester to understand how the framework works so they can easily add to it?
A major step is when you understand this comes above having the most concise code.
b) are your assert error messages providing useful information? Ideally your developers will have tests automatically executed on a commit, so can they understand why something failed?
c) are your git commit messages useful to other people who will use your framework? Commit messages are useful to see what fix(es) you made in a certain situation, so this can be repeated if a similar problem occurs.
d) do your non-technical team members need to understand the tests? Does a business analyst need to see you have a test in a certain area? Does it need to be in gherkin or pseudo english?
This will come down to a teams particular requirements.
e) is the reporting transparent and up to date?
If you have a dashboard and it is reporting fails are they looked at immediately so everybody else knows there is a real problem (rather than a problem with the framework)?
There are a lot of things to consider when creating an automated tests:
a) environment; is it integrated and so what else will it affect.
b) data; how do you want to ensure the data is correct, is there an api or database you can use to create it before running the tests? Or even a docker instance with the data already created.
c) maintenance; how to keep maintenance of tests at a minimum. A good Data creation strategy will help with that and depending on your tool, e.g. selenium, you may need to create a good wait system. The newer javascript frameworks take care of this problem for you. But also what are your selectors, can they still locate the element if it moves within the domain object model? What about using ai to find elements?
d) clean up; do you need to erase all the data or drop the database at the end of testing? Or do you spin up a clean environment every time your tests run?
d) and on and on e.g. what and how do we report, how many tests mdo we want to run in parallel etc
However, the aim of this article is not concerned with the above, as I would expect a good automated tester to consider those.
The article’s focus is on: when do I consider you can begin to think of yourself of venturing into senior territory.
The answer is when you begin to take an overall view; i.e. who else is using your framework and how does it fit into your organisation’s attempt to create a product without serious bugs. Once this occurs, the following things will begin to be thought about:
a) is it easy for another tester to understand how the framework works so they can easily add to it?
When you understand this comes above having the most concise code, then this is a major step.
b) are your assert error messages providing useful information? Ideally your developers will have tests automatically executed on a commit, so can they understand why something failed?
c) are your git commit messages useful to other people who will use your framework? Commit messages are useful to see what fix(es) you made in a certain situation, so this can be repeated if a similar problem occurs.
d) do your non-technical team members need to understand the tests? Does a business analyst need to see you have a test in a certain area? Does it need to be in gherkin or pseudo english?
This will come down to a teams particular requirements.
e) is the reporting transparent and up to date?
If you have a dashboard and it is reporting fails, are they looked at immediately so everybody else knows there is a real problem (rather than a problem with the framework)?
