This is the story of how the development and QA teams work together and deliver a world-class product.
Dev and QA, sitting in a tree, K-I-S-S-I-N-G…
I know I went back to early childhood for that saying, but the reality is that’s really how it should be done. They should be all up in each others busine… nah, just kidding, it’s not quite that extreme. It is however a good way to look at it.
Establishing a good rapport with your development team is very crucial to any project or endeavor, however this is not always an easy task. Each team member will have their own style and personality, and this will lead to teams that each have a unique dynamic. Ferreting out these unique personalities is one of the most important things you can do during the early stages of any project. Once you have a good handle on who all you have on your teams, the real fun begins.
One of the biggest challenges that I have faced in trying to put this plan into place in my current position has been the fact that a large part of my team is based in a different state (3 time zones away) than our developers, and it makes it difficult for people to keep each other in mind. Trying to tie a team together into a peer programming type of model is difficult when only 2/3 of the team is in the room for 3 out of 4 weeks a month. The old “Out of sight, out of mind” saying definitely applies here.
So how do we combat this very vexing scenario? One of the things that I have tried to put into place, is a good deal of documentation, as well as a healthy dose of open communication around deliverables. For documentation, we use a couple of different tools.
- All of our requirements and visual designs are documented in Confluence, and it is considered our “system-of-record” in regards to how the app should behave.
- For all of our “acceptance criteria”, we use an incredible app call TestRail. For all intents and purposes, the acceptance criteria are nothing more than self-enclosed test plans for each feature that we are delivering, and TestRail manages this for us perfectly.
- The ever-present JIRA is the tool we use to manage our actual work product.
Between these three applications, we can pretty easily document what work needs to be done, what work has been done, and what work has been tested and is ready for production. This provides a very clear indicator to all parties what needs to happen, who is responsible for each piece, and allows us to ensure that we have a very solid application being delivered.
At the heart of all of this, the most important thing is communication. Without very clear, and constant, communication, it does not matter what systems you have in place, or how good your people are, ultimately, the fate of your project will be in jeopardy.
PS. Yes, we can all get along…we just have to talk!