- This topic has 3 replies, 3 voices, and was last updated 7 years, 1 month ago by
.
-
Posts
-
We have a new situation coming up in the near future at the company where I work. We have two softwares solving the same problem but for different types of situations. These two softwares are now about to be combined into one software. Two teams will code and create, but we need to set up a good testing process.
There will be two grups working, lets call them Team A and Team B. They will code on their individual parts and parts that will be used by both. They will do some kind of testing of their own components, and some parts will have to be tested in special labs equipped to handle some physical and mechanical parts of the systems. Some testing will be possible to simulate and make some testing possible for people outside these labs.
So I wonder: Does anyone have experience with projects like these and can offer some pointers or inspiration? Lessons learned will also be appreciated.
Great question, and thank you for giving a bit more to answer on.
Regarding pointers, inspiration, and lessons learned – I would have to say that strong planning and open communication between teams will be crucial for not doubling the testing. Flexibility in approach will help keep frustration down.
This would involve looking at all the special labs and the locations they are in, so that the team that has access to those labs will test the components that need the labs. The planning is not only on the QA side, but also on the development side. These should be coordinated as much as possible and have a free flow of information. I would recommend testing locally if possible (usually this is more efficient as you don’t have multiple people involved for setup), but if it is a quick setup-and-let-the-other-side-connect-in then the efficiency is not as much an issue. I have seen distance connections that took up valuable time from the team members in the lab, I have seen where it was an easy setup and worked just fine as well (you will have to judge this on your own project with the technology you have).
The other item that I found worked well, was if both/all teams were using the same tool/repository for various tasks. Test case writing, issue submission, and knowledge base articles.
The main thing I have found is find a way to communicate across the distance. Find multiple ways of communication, phone, instant messages (hipchat,slack, etc.), or F2F (Skype, gotomeeting, etc.). The more overlap in time, the better the real time communication can occur. Keep both teams in sync. If you are using agile, sync the sprints and have a combined demo.
Communicate what is being worked on and tested (look ahead if possible). Question what comes up during that communication. Some question ideas: Are there any overlapping items? Are there any areas that could affect the other areas that have already been coded by the other team? How will that affect regression testing? How will that affect the code? Will it need to be re-tested (hopefully not)? Can you look ahead and see what areas of one team will affect the areas of the other? If so, plan ahead.
The flexibility that I spoke of earlier is in approach to something new. As both teams will tend to focus only on their own code and testing, they will need to be flexible in their thinking to think outside their team and look to see how it will affect the other team. This should increase the communication and cooperation of the two teams working with each other. Also, they will be able to see where specific knowledge is held in the two teams, which can help with knowledge sharing and bringing the two teams to work closer together over the distance.
I’m sure you have seen a common theme. Communication and planning.
I hope this helped and things go smoothly in the merging of the teams for a single project. These are just a few things I have seen that help with distributed teams in my current and past work environments.
@jtweatherby really valuable and to the point reply.
- You must be logged in to reply to this topic.