I'm responsible for introducing QA to two teams in the same company (let's call them A and B). None of them had any systematic QA before.
A and B
- develop two different products
- use different programming languages
- use different project frameworks (scrum vs waterfall)
- are on very different stages of the product development process (prototype vs has been used by customers for many years)
- use different bug tracking tools (TFS vs fogbugz)
My question is: Does it make sense trying to introduce the same tools and processes to both teams (which would probably make things easier for me in the end). Or should I accept that I need two different approaches for both teams (which would make the changes for the developers smaller/fewer, but mean that I had to juggle with tools etc. between the two teams).
UPDATE March 30 2017
Since I got many interesting responses, I want to give you an update on the progress during the last months.
Until december, I worked only with one of the teams and I'm rather happy with the development we achieved:
- We established a working process between UX designers, developers, support, product owners and QA.
- QA is done mostly by the QA people.
- QA people have a saying in the release management
- We are in the proccess of introducing automated tests, even automated GUI tests
- QA people is not just me anymore, but me plus one college student who works on exploratory testing and one college student who works on automated tests.
- We have a general consensus on the importance of QA people.
In december, I started working in the other team as well. Here, the team is larger, the product more complex and more buggy. Consequently, the progress is not as quick as I hoped. So far,
- Old, big, buggy features have been tested thoroughly for the first time (despite being used by clients for years...)
- New, big features are being tested thorougly (It makes me sad that I even have to mention that as "progress")
- New patches and features are being tested more thoroughly than before, which results in many patches and features not making it into their planned release
- A rough process between product management, developers and QA has been established, but I'm definitely not happy with it yet.
- I'm not the only QA person here anymore, but have two college students who help me with manual tests.
Concerning the initial question about the integration of approaches and tools for the to teams, I'm a bit disappointed to have to say that there is basically no overlap between the processes of the two teams. I'm even more disappointed to say that I don't see this happening in the next months either. It's basically a problem of having not enough time to change the existing processes. There is more than enough work for a full time QA person in each of the teams and I have to do both jobs. Since it has been made pretty clear to me that we will not hire an additional QA person, I concentrate on baby steps in both teams. For the first product, this means:
- Getting a decent code coverage with automated tests
- Establishing a process on how to deal with the results of the automated tests
- Pushing for a better release management (namely more involvement of the product owners)
- Working on the process between support and QA, since the product has left the prototype phase and is being used by many of our clients
For the second product, my next steps are:
- Automating the process of building a new testable version (right now it inolves a lot of copy+insert and waiting)
- Introducing a tool to handle release tests instead of an excel sheet
- Pushing for prioritizing bugs higher
- Pushing for specifications and bugs to be documented in a way that people who haven't worked with the product for 5+ years can test the features and patches, too
As you can see, I'm still busy with introducing basic QA processes. Maybe in a couple of months, I can work more on the integration of the QA of the two products. The current situation (I even have designated days to work on each of the products and work in different offices to be closer to each team) is not satisfactory. If you have any more opinions and suggestions, I'm always happy to read them.