What does the correct planning of the test team look like in the run-up to a project?
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?
- 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.
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