Weāre continuing our work to create a curriculum focused on automation that is created with feedback from the testing community. Weāve already run a series of activities that have helped us identify a list of key tasks that helped us create this Job Profile.
Weāre now in the process of going through each task and analysing them to identify the core steps we take to achieve them. For this post weāre considering the task:
Create Automated Tests
Weāve run a series of community activities including social questions and our curriculum review sessions to identify the steps we need to take to successfully achieve this task and have listed them below:
Discussion with Stakeholders, Product Owners, Development about the scope and purpose
Determine whether the test in question should be automated or not
Determine what layer the automated test should be on
List what state, actions and assertions the check will carry out
Codify the creation of state
Codify the actions the automated test will take
Codify the oracle in the automated test (assertion)
Run the automated test against the product to debug issues
Test the automated test by switching the assertion to fail on purpose
Store the automated test using version control
Have team members run a code review on the automated test
Run automated test as part of a build process
What we would like to know is what do you think of these steps? Have we missed anything? Is there anything in this list that doesnāt make sense?
What are your thoughts on these steps? How do you go about building your automated tests?
I would phrase it āDevelop Automated Testsā.
Automation is development, a specific type, similar to any feature developed by developers. Including all the thinking, design and architecture stuff.
Iām sorry I was unable to make the session - work got in the way.
Some questionsā¦
Will it assume the person developing the automated test is doing so from a blank slate?
Is the order of the points, as theyāre presented, meaningful?
ā Assuming yes, unless āDiscussion with Stakeholders, Product Ownersā¦ā is related to working from a blank slate, then I would recommend it being a secondary point for āintroducing automated testing to your team/orgā otherwise that part of the process is overkill in my experience
Does this include what are typically called ādeveloper testsā or āunit/integration testsā?
Are there particular patterns that are going to be taught?
ā If so, then Iād want to merge
** Codify the actions the automated test will take
** Codify the oracle in the automated test (assertion)
Does āCodify the creation of stateā include stubbing/mocking?
āIf so, Iād recommend another section on āmanaging āfakeā state to reduce assumptionsā
Will it assume the person developing the automated test is doing so from a blank slate?
No. Once we dive into learning outcomes, weāll aim to cover a number of learner profiles, and context.
Is the order of the points, as theyāre presented, meaningful?
ā Assuming yes, unless āDiscussion with Stakeholders, Product Ownersā¦ā is related to working from a blank slate, then I would recommend it being a secondary point for āintroducing automated testing to your team/orgā otherwise that part of the process is overkill in my experience
That would have been covered in the earlier responsibility of strategy. If you open the job profile link youāll see the other responsibilities.
Does this include what are typically called ādeveloper testsā or āunit/integration testsā?
Yeah, the steps are high level enough they would apply to make layers. So when we create content and learning outcomes, weād include content on multiple layers/examples. But most of these steps apply no matter the test layer.
Are there particular patterns that are going to be taught?
Unknown yet. But again its high level. Every test has a set of actions. Click this, call this API, create this object, call this method. These are all actions.
Identifying a good oracles and then implementing it is a completely different set of skills.
Does āCodify the creation of stateā include stubbing/mocking?
The high level skill is knowing you need to think, manage and create state.
If I were creating content, I would absolutely have a section on mocking/stubs and Iād include how you maintain them. This would be translated via the learning outcomes which is the next step.
all of the above. Basically a tool where you donāt āwrite codeā.
I associate āDevelopā with code. Iām not saying it canāt be changed, just trying to fully understand your concern and reasonings.
I donāt see development only being related to code.
It is a spectrum from āeasyā to āhardā and you can develop with and without code at both ends of the spectrum.
Many āeasyā development is somethings called āscriptingā. But even creating scripts can become very demanding.
Not only the development of an application is development.
Most important is to me the mindset, not so much the concrete tool and tech.
A developers mindset, as of being a creator, is different from being a tester, looking for problems in a system.
This is QF-Test, a tool for UI automation.
You literally click an equivalent of code together.
Sure, it is not typing code as in an IDE, but you have the same constructs.
To create this you need a mindset of a developer.
