Qfyilyi

We've been prototyping an application and it is more or less at the MVP stage and the customer, seeing the minimum desired functionality, is taking things seriously and want further development.

At this point in time, we have a part-time tester with experience in test automation who is eager to apply his skills into practice and try a test automation framework he's been wanting to try for a long time.

At the same time, this is a very early time to invest in test automation as the application changes very frequently both on the backend and frontend sides.

For the moment, we are asking the QA engineer to go through customer business requirements and to validate the existing functionality against them as well as familiarize himself with the roadmap.

What other things could we ask him to do? What would be the best use of QA engineer's time while the project is in an early stage?

I don't think building test automation in an early stage will be a good idea, particularly UI automation as things will not be stable and UI will be prone to frequent changes.

I would suggest the QA engineer to perform requirements validation testing at this stage .It will ensure that the requirements
written in software requirements specification (SRS) must be complete
and consistent and are according to the customer’s needs. This process
will ensure the validity of user requirements by eliminating
ambiguities and inconsistencies from SRS and this could be the biggest
payoff at this stage.

For automation,I would suggest to go for API layer only if it really makes sense in the project's context.The reason I am suggesting API layer as @Alecxe also mentioned it is the more stable part of the stack. And on this layer we can do pretty much manual API tests as well with handy tools like Postman.

.

I agree that it may be too early for much automation. But there is still a lot QA can bring to the project to help it be successful at this stage.

If it were me on the project, along with learning everything I could about the requirements, I would be looking at what the customer(s) really do & what their workflow is, what our competitors might offer and anything we've developed previously that might be of use (good or bad) on this project.

I would try to get invited to any/all meetings on design & development so I could understand not only the product requirements, but how the coders are developing & writing the product. Take note where there are heated discussions, confusion or areas of concern - those are areas you might need to give extra attention later.

Be curious & ask questions. Ask about tests you might run, or the labels for fields, or what the customer expects response time to be - ask about everything. This confirms everyone sees things the same way (easier to catch it now, than later). I've been amazed how many times a 'harmless' confirmation question has evolved into a full 20 minute conversation that fixed a major issue on paper instead of when it came to test.

I work in an agile shop - so I would begin to draft up some epics, and if possible some of the first stories. They may need flushed out later, but start getting the ideas down. And begin looking at your requirements - do you have a specific format required for test plans, regulatory documents you'll need to fill out with testing, etc. If you don't know what those are now would be a good time to gather that information.

If you see something new to you, now might be the time to give yourself a crash course in it. (I once did an introductory course on medical coding based on the project I was on... not needed, but very useful when we got further in.) While things are slow for QA is the time to squeeze that in.

Being your QA person is only half time on the project all this may not be possible, but even tackling a few of these things will be good for the overall project.

Although all observations are valid, from a project point of view, I am missing the motivational and learning point of view.
Starting some automation now can also be part of the learning of that engineer, and the team. He will be motivated as he can do something he wants to do. Yes, the product will change. But he can also grow along with the development of the product. Starting the automation in the "future" might even be too late to catch up at that stage. Or very difficult because no one thought about the needs of the testing ("been there, done that"). Complexity grows so will the automation challenge. So from my perspective: start early. Together and alongside the development of the product. Learn and adapt. Refactoring is a given. For all types of coders.

Having said that: the quality assistance member can already help with reviewing unit tests. Help with tools that assist the team. Build mocks. Apart from what already is mentioned.

And returning to the person view: a coding tester is not very different from that other type of coder: they run if you burry them in paperwork... just my 2cnt.