Different testing approaches for different teams?

Question

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.

Answer 1

As Bookeater says, you absolutely want to unify tools and processes between the teams. That said, I'm going to offer some extra advice because I've been in this situation (and to some extent I am still in this situation).

• Hasten slowly - Each team has built up a process and toolset that works for them. A newcomer telling them they have to change everything is not going to go over well.
• Start by gaining trust - Both teams need to see you as a valuable team member and trust that you know what you're doing. You won't get that by pushing change: you will get it by doing things like setting up integration between the two systems and explaining that you're doing this to make life easier.
• First steps - Your first process change should be setting up integration, and you do it so you don't have to work with two separate systems (you can position this as making sure you don't accidentally file anything in the wrong place leading to it being missed or delayed).
• Expect pushback - it took me well over a year as the first test specialist to "teach" my teams that they wanted me to be involved in all phases of development. I floated the idea, let it be rejected, then when items reached me for testing I asked all the awkward questions that would have saved everyone time and effort if they'd been caught during the design phase. To some extent I am still pushing for this, only now it's with an agile process and I'm pushing for more awareness/oversight of the big picture the agile process is working with.
• Expect a long adaptation time - I've been at my current workplace for 2.5 years. In that time two development teams have merged into a single team, the application lifecycle management process has gone from spreadsheets and SharePoint lists through TFS to Rally and is still evolving. There is still a development team that is entirely external to my team and assorted other development activities that involve people who don't interact with my team.
• Respect the team processes - The teams are using the processes they have now because those processes work for them. I'm going to guess that the team working with the established application is the Waterfall team - with a known, well-understood system a Waterfall SDLC can be very effective. You may need to work the two SDLCs for several years.

You're in this for a long haul - you're going to need a lot of patience and tact, as well as make a number of compromises. Good luck.

Answer 2

You are SO going to hate this answer. It is Yes and Yes.

There is some possibility to integrate between TFS and fogbugz. http://www.fogcreek.com/fogbugz/docs/70/topics/sourcecontrol/setup/TeamFoundation.html

Your goals should be:

1. Maximum tool level integration (to input info only once).
2. Define overlap between procedures and utilize this
3. Minimize differences (hard to do with such different approaches)
4. Acquire support and define a time-line to reduce your worst time consuming differences.

You should clearly communicate the investment the differences between the teams requires of the QA process and what lacks result wise as a consequence.

But in the end any streamlining is for management to decide. You can massage and adapt and create proposals to improve... but inertia is against you.

Answer 3

Firstly, I would like to start with the Bug Tracking tools. What about the old bugs logged? If you ask one of them to move to the same tool, their information (bug history)is lost. But, if the team that just started the product development is ready to move to fogbugz, then you can always request the team to do so. Learning any bug tracking tool is a matter of couple of hours. This way, you need to take care of only one tool.

Different protocols, different programming languages and different bug tracking tools do not cause any significant change in the process to be followed.

But, when it comes to frameworks, definitely, the same process cannot be applied to both. Scrum and waterfall processes is like technology and Dinosaurs respectively. Scrum falls under Agile and Agile QA processes are way different than the traditional waterfall. Both the products will have to be handled in the way they are being formed. Applying the process followed for waterfall on Agile is going to be a disaster and vice-versa. Unfortunately, on the processes part, you and in fact your entire QA team will have to think differently on both products. Personally, I feel it is a challenging opportunity for you.

There is a lot information on Agile QA processes to be implemented. You can refer https://www.scrumalliance.org/system/resource_files/.../AgileQA.pdf and http://www.slideshare.net/abagmar/agile-qa-process

Answer 4

You should use the same tool, as it will make your work easier, because in that case you will have to track only 1 tracker, but as far as processes are concerned, I doubt that you will not be able to follow the same process as your both project are based on different SDLC (Scrum and Waterfall, as mentioned by you). So if SDLC is different whole game play is different for both projects, because in one project you will have User Stories, Story point, Product Backlog, Scrum Master etc. that too with sprints, which will not be in case of Waterfall project. Thus following same approach and process will not benefit you.

Other than this your testing approach can be same for both the projects (depending upon the scope), as the approach will not depend over the programming language being used. It will depend upon the timeline, scope and future aspects of the projects e.g. if it is a long running project with lots of regression cycle then you should go for Automation else you can live with Manual.

So your testing approach and methods can be more or less same but process will be different.

Answer 5

Just a little thing to contribute.

I think that there are some questions to answer in order to decide:

Do you need integrated metrics or will you have separated metrics for each team? The impact on the decision is direct. I mean, if you will make a team learn and change the tool they are used to use, it has to add value to the organization because it will have a cost. Otherwise, you should get used to use two tools independently.

I'm basing my answer according with my experience, doing consultancy to different teams, where I have to adopt more than make them change, unless it has a very clear contribution to them.

Hope it helps! tell us please your conclusion about the topic :)

Answer 6

I feel very happy to answer this question as I faced same situation recently. I worked 3 year as QA engineer and then I got an opportunity to start "Process Implementation" in an organization, as they wanted to be Agile.

What I Did -

• I used TFS (previously they were using Mantis).
• I target only one team, (company has 9 product and their teams).
• I explained everything about Scrum (methodology) and TFS (tool). And motivated them to start working in Scrum.

After 2 sprints of 2 and 3 weeks I invited team leads and PM of rest of the team in sprint review meeting.

Now it has been only 2 months and I started SCRUM in 3 products. So I think we should focus team by team.