What does the correct planning of the test team look like in the run-up to a project?

Question

In my new project I have to put together a new test team. The PO would like to know from me in advance how I will carry out the planning in this regard. The initial situation is as follows:

• No test structure available
• No test concept - no test plan
• No test structure - Hardware
• Unclear which test frameworks are available
• It is unclear what level of education the testers have. Will work remotely.

In the current planning I would like to use a higher number of testers at the beginning to define a basic set of test cases (after an analysis) and write them accordingly. Later on, I'd use a base of testers, which I'd end up with and replenish before the go-live.

Of course it has to be clarified in advance which test framework will be used.

So I would be interested to know which setup is planned for testers from the beginning of a project to the go-live?

What would make sense and what is not advisable?

---

UPDATE

• It is a webproject based on Magento Cloud. But at the same time it still has connections for sales.
• Currently 8 developers, no tester and 2x PO are working on the project.
• The total size of the company is 20. It is a startup which was founded in 2018.
• There is no test structure, no test tools, no suitable workflow, no test days, no API gateway.
• It will be a mix, especially at the beginning of course I have to assume that we will not be able to automate all test cases in the near future. But it will definitely be highly automated in the course of development.

Answer 1

For an agile project:

Focus on testing as a very iterative on-going, highly integrated process.

High number of testers at the start may be more reflective of a more traditional approach. Remember that the goal is higher quality, not number of tests

Be careful in having 'initial testers' and later a base of testers that you'd replenish. This sounds like testing is a plug and play operation and ignores the human components. Would developers be treated the same way? This might all be ok if everyone moves around to service different projects (a common way of working), the problem would be if it is only QA folks moving around. This will frequently increase second-class citizenship problems.

Note: "have to assume that we will not be able to automate all test cases in the near future. But it will definitely be highly automated in the course of development." Think carefully about what you are saying here. I have never "found time" later. You have to do it (mostly) right from the start and constantly. Otherwise you have technical debt right at the outset. Which will continue. Which is the case for 90% of companies in my experience.

What I would give feedback on so that the project has quality is:

• The need to create test data through new or existing APIs
• The need to mock and stub services used in Unit testing
• The need to have a continuous integration system for fast feedback
• The need for application and automation developers to sit together
• What will be the correct mix of manual and automated - this is a discussion to have

Answer 2

In our previous project we had the same issue. Since we are running agile methods I will try to explain our lessons which we made.

What we did:

• Exploratory testing methods. Means that we do testing while learning things that influenced our testing procuedure. Within this methods we used also the tool Tricentis (or former called QASymphony). With each testing step which we learned we added and expanded the test cases. Because this tool is capturing the steps and creating automatically test steps. This was very helpful for us and save amount of time. Before that we were using HP ALM, which required concrete test steps and is in our opinion not suitable for agile testing methods.
• We didn´t started with test automation since the environment was changing fast e.g. the locators. For example: We had a marketing web page with cars and the logos were changing in the sequence so that the "passed" test cases were actually false. For the beginning we made the lesson that a automated testing of the frontends applications was not useful
• We involved the Product Owner with testing - it was mandatory that the Product Owner "accept" the exit criteria of a user story. So this was good because with each testing step from exploratory testing we demonstrated our skills to the Product Owner. Since we got the test steps "captured" via tricentis it was easy to show the Product Owner what we did and he completed the test steps and/or added the test steps. And even the Product Owner started testing with us. The feedback from the Product Owner was very helpful to create further test cases.
• We invited people (e.g. students) for exploring the testing product. This saves a lot of money and we found out some more requirement for the product. This was very helpful at the beginning. Also for the Product Owner and we founded out that we missed the way of the "thinking" how a customer would interact and we considered the thoughts of the customer in our testing procedure.
• Regarding the testers: We also had at the beginning "unexperienced" testers, so we created a WIKI (e.g. with Confluence / JIRA) and posted all relevant issues there as a communication bridge.
• Regarding the test concept: At the beginning we started with a Test Strategy, there you can define some basics which you know at the beginning. Afterwards you can broad the test strategy to a Test concept.

I know that this is not the normal way of testing e.g. based from ISTQB. So we tried it in another way maybe the link from James Bach helps you to create your test procedure in a more agile way. This is a blog e.g about some topics (exploratory testing / risk analysis..). Maybe it helps to have some inputs:

Satisfice James Bach