Sorry for the long title but its an awkward one to phrase.
Hopefully this will explain properly.
I was having a chat with a tech lead who wants the developers to be more aligned with the automation tester. The issue is that the developers are making front end changes that break the automated tests as they are not really aware of what it does and what functions are covered.
There is an easy fix - we do a demo so they can see how its put together and if a developer makes a code change, they will think to tell the tester.
But this doesnt really go as far as I think it should. How does the developer know if a field is covered within an automation test (we have a backlog that we are working through).
In my fantasy land, a developer would make a code change, the tester would be notified of the code that he or she needs to update in the automation pack and a new task is added with the details included.
The issue is, how can we create a mapping between a field and the automation test relating to that field in order to set something like that up? We are using Selenium with C#, and have created a POM framework. I cant help thinking that there must be other people who have cracked this one, so any working suggestions would be much appreciated.
Imagine for a moment, a dev makes a change to a internal module an that cvuases one of the CI tests to fail, who fixes the test? Wel, mostly a tester will raise a bug, then a dev will have to explain how to fix the test… or…
You could, get the developers to be responsible for more of the automated test writing? If your code change causes a test to fail, it’s not the testers job to fix the test, I mean it might be if you had that kind of structure, but it’s not helping the dev if their code cannot pass CI because now they are blocking their own progress if they are not allowed to merge their code. You are onto the right route using POM, Steve, but it’s not the entire picture. I would make it easy for devs to run any single UI test whenever they want to, and thus easy to fix it at the same time.
I would also have a conversation and see if it’s a good time to move your test code to sit in the same repo as the product code. That will definitely force the issue, even if it does not get test code into the same repo (that’s a much harder ask.)
I’m not really answering your question - I think you are after something like a “high level” templating tool, perhaps if your app uses an app framework to generate the UI (like if its a web app) and then exports somehow or makes available through internal UI layer hooks all of the controls, then a test can check for new controls at runtime and raise an alarm. One way to do this might be if the test framework can read all the string translations, or if it can query all the existing controls. Where I work we have an internal API, which we use, so it is possible to count all the controls… but if every POM page asserted the number of controls … then it might become nasty when a developer deletes a control that was pretty cosmetic anyway and it causes every single test case to barf.
Here’s some ideas:
• the developers in the automation product are monitoring the changes in the actual business product; there should be some code repository that can be accessed and read…
• the developers in the automation product work in the same team as the business product developers; everyone develops product code and automation code; shouldn’t be more different than unit/integration/or other similar automated checks;
• there’s no UI level automation checks; find a lower level to automate then and do some testing for the UI changes;
• the automation product developer does peer reviews and adapts the html for the business product(for easier element finding) and automation product;
• leave the automation product to fail on a test environment; you’d want to know that there are UI changes in the business product and which ones those are; so go get some information/learning - who changed, why, what’s the business need, how did they interpret the change, what actually changed, is there something that shouldn’t have changed…etc.
• have the business developers inform the automation developers that they plan to change X by Y date; keep contact with them to be aware of the progress and actual changes;
• delete automated checks code that gets flaky too often; if there’s too many UI changes, maybe it doesn’t make sense to automate any checks yet; keep it light;
• add the code in the same repository, and/or link the deployment jobs of business and automation products; the developers can’t deploy the business product until the automation product is adjusted;
• disable the job that runs regularly the automation product - in a production environment; and only execute it when changes made to the business product and automation product have been made and deployed in sync to a production environment; something like dependency versioning - an old version of automation will not run as it’s incompatible with a newer version of the business product;