0

The question is: "How to implement testing from scratch? How to structure things?"

I have taken the position of Head of QA in a start-up company. The situation is that they have a software product already quite advanced in terms of functionality and in use by a solid client base but they have never had a QA team onboard. Testing was up until now being done on a ad-hoc basis by either the Devs or Product team with additional BETA testing done by clients. The Dev team is composed of 10 people for the moment, split into 3 different scrums (stability & perf. / 'SW product 1' / SW 'product 2') working on 2 week sprints.

There are no manual test cases and no automation today.

My further questions are:

  1. What is the best way to proceed? Hiring a QA automation Lead to build FW and start implementing tests? Hiring QA engineers who are capable of doing manual and automation testing to get both things off the ground and moving?
  2. Should I start with building up manual test coverage for the main priority user flows and build out from there and automate after?
  3. Should I identify Automation test cases from the get go?

I see two activities in parallel:

  • keeping up with new functionality implementation
  • building up coverage for existing functionalities

Any ideas here guys? Available to answer any counter questions.

Thank you!!

4
  • Surely these are the sort of things you'd expect a Head of QA to be answering, based on their expertise and through developing an understanding of the specific context of the company they've just joined, not asking random people on the internet?
    – jonrsharpe
    Jul 8 at 9:59
  • Testing is fundamentally risk driven activity in a given context. I don't see the word 'risk' here in whole discussion which should be the primary driving factor behind all these activities to build a road map and vision. Jul 10 at 11:44
  • @jonrsharpe I know that a lot of this depends on the context of the company, this is simply advise sharing to compliment the ideas I already have. There is not a one way fits all approach of course.
    – veryqaguy
    Jul 13 at 10:27
  • @VishalAggarwal agreed, risk does factor in my decisions but I have not yet started there yet so I have a lot to learn still.
    – veryqaguy
    Jul 13 at 10:28
0

What is the best way to proceed?

The best way to proceed is to talk to your management and understand future development requirements, budget, business priorities, deadlines etc

Hiring a QA automation Lead to build FW and start implementing tests?

This is recommended only if your responsibilities and the new QA Leads responsibility doesn't overlap. But for startups without knowing the team size there is nothing much to comment on this. You should be able to see the future responsibility of the Lead and the future number of scrum teams that will come up in the organization. Ask yourself the question , what will LEad do after the framework is developed

Hiring QA engineers who are capable of doing manual and automation testing to get both things off the ground and moving?

The main thing here is to priorities the tasks and decide the development to QA ratio. Its applicable to have atleast 1 Test Automation QA engineer per team in your current situation and automate as much use cases as possible and avoid the need of manual teams.

But to keep up with the current development pace have a separate manual Test team with a ratio of 1 manual QA to 2 Teams who work in rotation between teams in manually testing in sprint features. This ensures that the Manual QA are used effectively and are not over or under used (The ratio will change according to project size)

Should I start with building up manual test coverage for the main priority user flows and build out from there and automate after?

In the agile world, manual test cases are waste of time and effort, try to define executable specifications like using gherkin, keyword-driven or have test cases defined as acceptance criteria for user stories

Should I identify Automation test cases from the get go?

Having end to end test automation allows you to avoid need for manual test team in the regression phase , you can use them for adhoc, exploratory and usability testing . THis increases the overall testing efficiency than executing the same manual test cases

So in summary

  1. Talk to the team and understand the priorities
  2. Understand the budget
  3. Have a long vision of the organization
  4. Understand whether automating already implemented features is required. (It is required but see does it worth it )
  5. If it is required , decide who will do in sprint testing
  6. Do proper capacity planning to make sure , you don't overload new QA engineers by forcing them to do manual testing , automation , cicd, development and every single thing
  7. BUdget, plan and respect
3
  • 2
    Could you please elaborate further into details onto "In the agile world, manual test cases are waste of time and effort" statement?
    – Prome
    Jul 8 at 8:24
  • @Prome "Working software over comprehensive documentation" . It doesn't make sense to have huge detailed manual test case like steps in ALM . Imagine having 500 manual test cases , try to investigate how could it be automated and take the repetitive task off the human actor
    – PDHide
    Jul 8 at 13:47
  • manual testing is important , manual test case is not . Have just high level use cases that can be used for automation or can be used as product specification .
    – PDHide
    Jul 8 at 13:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.