Working on a project
Last modified on Thu 18 Jan 2024

Working on a project

When working on a project with multiple people/teams, you should agree on a way of work and have it written down as soon as possible, preferably during your first days on the project.

This should contain info on the test automation process in SDLC (Software Development Life Cycle), such as:

Requesting IDs

Ideally, if test automation is being done on the project, you should have most of the locators ready. If not, it is important to discuss early on who will be responsible for:

It will usually be the responsibility of a TAE. In case there are multiple TAEs on the project, a dedicated person should be decided on to make the process faster.

A few things to consider when opening a new task:

When preparing the locators, you should consider a tool that is already being used for design. In case the design is being done in Figma, you could use that one. Not to mess up the design, you should create a separate document that will contain all the screens to which you want locators to be added. Simply copy and paste the screens and using tools like an arrow and a text field, mark the element that needs a locator. Then, when opening a task for the developers, insert the link that points to the screen with marked elements.

When working on locators, it would be wise to have a page with a few examples, a "standardization" of a sort. For example, you want all the buttons to be prefixed with "btn_" or suffixed with "_button". The same goes for all other elements like input fields, sliders, etc.

Maybe the developers on the project already have an agreed way of working, so you could continue with that. The idea is to have somewhat similar-looking locators throughout the app.


Who writes test cases?

Test cases are developed by person / team that is using them. If (manual) test cases are primarily used by the QA team, then writing and updating them is their responsibility.

You as a TAE can and should help out in test development and maintenance. If labels are used to mark the tests, it is your responsibility to make sure that test cases are correctly labeled.

TAE should not ask the QA team to adjust test cases so that they could be automated more easily. This could lead to QA focusing too much on writing the appropriate test for test automation, and not writing a good test that helps in testing.

Which tests to automate?

This depends on what you decide as a team, and which type of tests you are working on. If you are, for instance, working on UI test automation, you most likely will not be able to automate everything, for whatever reason.

In any case, make sure that your code is readable and that the tests are stable. It is not how many tests there are, but whether are they doing the work they are supposed to do.

Test reports

One of your tasks is to often check the reports generated by test automation.

If there are tests that ended in error or fail, make sure the issue is not in the framework or a mistake in the tests. If the issue is in the app, report it to the QA team for further investigation.


TAE should attend all the meetings that other team members are attending; daily standup, sprint planning, backlog refinement, sprint review, sprint retrospective, etc. If there are additional QA syncs, TAE should be present.

In some cases (if not most) you will work on regression tests and it might seem that attending meetings is a waste of time. However, think again. Your experience and insights will definitely be valuable to the team. Besides, hearing about what is being developed right now will help you prepare for the upcoming test automation work.