Good day, beautiful and smart people!

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?

If the product is at the MVP stage and your QA is just getting started, there's a problem. As a BA I saw this time and time again with dev vs QA where the dev team only got the BA to do testing when they felt the product was "ready to deliver to QA" which is a notion all developers should aim to dispel.

Most developers went to university and took some programming classes. When they submit assignments, they are graded on how well they meet certain criteria, most of which is whether they pass the professors tests. This is an incredibly damaging practice because it teaches developers to be afraid of publicly failing a test.

Instead, QA should be testing long before these features are "ready." If you have a 10 working day sprint cycle, the things you work on on day 1 should be sent to QA on day 2. Don't send it to QA on day 6 with all your other things, have them give feedback on 6 different features, and have you spend day 7 and 8 fixing it all for a final test on day 9 and a release on day 10.

So if you're at the MVP stage, your QA person should already be intimately familiar with the product because they should have been doing testing on it every day since you could log in to the app. If you haven't, now is the time to get them started on it full time. If the person has tests that can be automated, do so. Don't be afraid to test something because it might change later. In fact, that's a good thing. A lot of times, if the test is structured well, it will still pass even after the change. And if it doesn't, that's fine. You are unlikely to scrap the whole test because of some changes. And if you do, well you need tests around the parts of your app the change the most because that's where the highest likelihood of bugs is going to be.

Long story short, this engineer should be having a healthy mix of manual and automated testing on a full time basis (especially if you have 3 or more developers working full time on the product.) They should focus on the things that are changing right now, as that is most likely to have bugs in it. They should be testing it before it is complete so early feedback can be sent.

What would be the best use of QA engineer's time while the project is in an early stage?

Ask the right questions to the right people...

to uncover & challenge all implicit assumptions in the requirements.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.

I have seen time after time , in projects even in later stages, fundamental assumptions are either not fully correct/ or at least never fully understood/challenged as a team.

Many joining the party late , either does not bother or have the confidence/courage to analyse & challenge the fundamental assumptions in requirements in a systematic manner.

I think that's what precisely distinguishes a QA engineer from a test engineer.

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.

It sounds like you're on the right lines already but, in addition to going through the requirements and getting familiarised with the roadmap, it's definitely worth getting him to exploratory test the MVP and get a feel of the product as early as possible.

Also, static testing the requirement document would be beneficial as it allows for early feedback and your guy could shape the backend requirements to make his automation easier to implement -- I've worked in places where the automation team would get to name the page elements, rather than the developers or business analysts.

Failing that, creating some tests for the highest priority journeys (usually the 'happy paths') would showcase what the automation is capable of... and would likely impress the customer!

I think it's a good time to ask questions about how you're defining quality for the app (ie, how quick it needs to be, how accessible it needs to be, supported browsers) I've also found that test automation can take a little time to get up and running. There's lots of drivers to be installed and/or docker/virtual machine type containers to get up and running, plus decisions on tools to use, security features, hooking it up to the build server, etc, and teaching anybody who wants to contribute or review results.

Have that ready to rock, even if it's just a login test, can be very helpful in the effort to 'automate with the sprint' that so many people are trying to achieve these days.

note: I assume you are CTO or similar role or the "boss" for QA stuff

In order to build a proper QA stage, you should take care of the whole process:

• 
  requirements: formalize them, update them, take track on every release, as use case or user story. It's a work of the product owner/manager, but any help is welcome!


• 
  define tests: test for every requirement: every requirement should have an acceptance test, write in plain text. Find a way to specify them, track them, organize them and keep them updated in a "test wiki/document" is a huge work. I've found useful define not only user story/use case, but "user journey", to connect use cases together in a meaningful way


• 
  tools: find right tool/framework/system to test, QA engineer should be (with CTO approval, of course!) in charge here. Be critic on tool choice, be free to experiment with other tools is crucial for QA engineer to be accountable here


• 
  tests: do actual test every issue/ticket/development will be covered by an automated test (unit/integration/end user) with a proportion of 70% / 20% / 10% of his work. In my experience track every test on a specific use case / user story is crucial, to track problems and organize them
  
  
  
  
  • 
    unit test: code must be tested on edge cases (null, worst scenario) always, everywhere
  
  
  • 
    integration test: like other said, test apis with tool like postman, run them before every release, collect insight, fix bugs on integration level is main responsability for QA. Be sure to cover all critical paths here
  
  
  • 
    end user test: focus on most critical stuff here. Automate when it's possible, otherwise do it manually. An example? For an e-commerce: register, login, search stuff, buy => main loop should be always covered
  
  
  
  


• 
  document & retrospective: track releases, tests done / accepted / failure to bring insight on next steps where team can do better, so planning features/epics should be more easy. For example: we had a lot of problems in this area, should we invest more on redesign/re-think it ?

Background: developer&QA 10 years, product owner 1 year