1

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!!

5
  • 3
    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, 2021 at 9:59
  • 1
    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, 2021 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, 2021 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, 2021 at 10:28
  • "...a software product already quite advanced in terms of functionality and in use by a solid client base..." Many of your questions are difficult to answer meaningfully without some specifics. What sort of product, built on what sort of platform, and who are the clients? There's a huge range of possibilities here: online shopping platform for vendors & buyers, banking transaction software running on secured on-prem servers, game app running on mobile devices, embedded software running in industrial equipment cabinets.... What you can/should do first depends on what you're testing.
    – JDM
    Apr 4, 2022 at 17:36

4 Answers 4

1

There are a few different options for how to proceed with implementing testing from scratch, depending on the resources and priorities of your organization. Here are a few suggestions:

Hiring a QA automation Lead: This could be a good option if you have the budget to hire someone with experience in building and implementing automation frameworks. This person could lead the effort to establish a comprehensive automation testing strategy and oversee the implementation of automated tests.

Hiring QA engineers: Another option is to hire QA engineers with experience in both manual and automation testing. This would allow you to get both manual and automated testing off the ground simultaneously and build a more comprehensive testing approach.

Starting with manual testing: If resources are limited, you may want to start by building up manual test coverage for the main priority user flows. This will give you a better understanding of the product and its functionality, and you can then use that knowledge to inform your automation strategy later on.

Identifying automation test cases: It is also important to identify automation test cases from the get-go, as this will help you to build a more robust test suite and ensure that the most important functionality is covered by automated tests.

Two activities in parallel: To manage the two parallel activities of keeping up with new functionality implementation and building up coverage for existing functionalities, it could be helpful to prioritize the testing efforts based on the risk and impact of the new features and functionalities.

It's also important to establish clear communication and collaboration between QA and development teams to ensure that testing is integrated into the development process and that the QA team is aware of new features and changes as they are being developed.

In general, it's important to take a phased approach to build a testing strategy and make sure to have a clear understanding of what you want to achieve and what resources you have available to you.

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
4
  • 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, 2021 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, 2021 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, 2021 at 13:50
  • @PDHide in theory you might be right but not all products are born equal, the effort to automate some cases or products could be simply not economical with terrible ROI
    – Rsf
    Apr 4, 2022 at 9:12
0

What is the best way to proceed?

The Best way to proceed is to understand the business requirements and discuss with the management team.

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

If the application is stable and there are enough scenarios to automate then only there is a benefit of QA Automation Lead. It is better to take time and think if there is a need of QA Automation Lead.

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

It is always a good idea to hire engineers who are capable of doing both manual and automation because as per the need QA Lead can switch the engineer between the manual and automation task. Every software testing company prefer to hire hybrid engineers

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

It depends on the process that is followed in the team. Creating test cases for the developed features is good idea to cover each and every area of the application. If agile is followed then creating test cases when feature development is in progress and executing those test cases when feature is deployed on QA instance will help in finding the bugs in early stage. Moreover, side by side

Should I identify Automation test cases from the get go?

Yes, if we have few test cases automated for smoke, sanity and regression then it will save time in regression phase. It will decrease the manual effort and increase the efficiency.

0

First you need to put SOPs/Testing scope in place. Then you will get what needs to be tested..Is Only UI Testing required or APIs or Database.Then once this is established you need to find the write tools and people with that tool skillsets and hire accordingly.

Coming to further questions:

Hiring a QA automation Lead to build FW and start implementing tests? -No. QA automation lead will just increase your spend. You need to first have manual Testing team for few months so as to get grip on understanding of project. Prepare a small regression suite to just get any ui issues or high risk functionalities then expand as going on. Also Go on Include any bugs or enhance a module with major bugs found in UAT or prod.

Hiring QA engineers who are capable of doing manual and automation testing to get both things off the ground and moving? -This can be done but again will increase initial spend up.

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

Should I identify Automation test cases from the get go? -Regression is first thing that needs to be automated.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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