The Globe and Mail isn't that different from other digital organizations when it comes to team dynamics. We have an editorial team that is dedicated to the web and an implementation team that develops, tests and launches the products that you see on the various sites under the Globe and Mail banner. And not to mention, the mild-mannered design team that makes everything looks pretty.
We'd like you take a trip with us for a behind-the-scenes look at The Globe and Mail development and testing teams. Each day brings new challenges and new opportunities to innovate and improve on the sites that have become an integral part of our lives and hopefully yours as well.
The teams work well with each other for the most part. There are, however, mornings when the unspoken rule of "don't-talk-to-me-until-I've-had-my-coffee" is broken which leads to some very unpleasant things for the unfortunate offender, especially when he - a tester in this case - says something like, "Hey, this page doesn't look good in IE6" to the developer. The calmest of Zen masters will flip out at that.
We usually promote features and fixes to the site once a week. Some days we release a lot of new things (a new site navigation for instance) which involves every department; while others are behind-the-scene fixes that make our system administrators happy. Regardless of what is being released, there's a strict process that we follow.
Step 1: An idea
There are some very creative people in the team here and they come up with some great ideas for the site. Consider this scenario: an editorial team member comes to a developer and says, "Wouldn't it be nice if…" - at this time, alarm bells start to go off in the developer's head - "… if we could automate XYZ on the site so I don't have to manually change everything?"
Step 2: The details
This is a great idea. It will save a lot of time and reduce the chance of human error. Designers, editorial team and developers work out the details about the look and feel, usability and workflow. These details are then filed and sent down to the developers via pneumatic tubes (well, a ticketing system really).
Step 3: The grind
At this point the developers start to hammer away at the task. After a few days in the panic room, they emerge victorious with a solution that is even better than what was requested. It is beautiful, a work of art even. It's the best piece of code ever written and then, it makes its way into the hands of the quality assurance team.
Step 4: Testing
This is one of the more chaotic parts of the process. The quality assurance team bridges the gaps between the initial request and the final product and tries to make it all work before the deadline. I would spare readers more details of what really goes on at this point but rest assured it's not entirely unlike this:
Go on, have a listen. We'll wait.
Step 5: The release
At long last, it's the release day. Everyone is happy that we made it relatively unscathed and the feature will finally make it to the site and all will be well. High fives are usually frowned upon but on rare occasions, an exception is made. Harsh words that were spoken are forgotten. Someone starts to sing " This was a triumph. I am making a note here, huge success…" And yes, there is cake.
Step 6: Realization
The feature is now live on the site, for all to see. We check whether it's working how it's supposed to. Someone runs through all the major features on the entire site and gives it a thumbs-up. After the cake runs out, the team starts to pack up and call it a night -- a job well done indeed. Just as the lights are about to be turned off, the aforementioned tester decides to see how the page looks in IE6…
The story above is almost, but not quite, true. During most feature/fix releases everything goes smooth as butter. Quality is of utmost importance to us. If there's a piece of code that doesn't meet the necessary standards, it comes out and stays out until it is brought up to par.
We have some very cool things to share in the near future. We would love to see your feedback - good or bad. The best way to make things better is to listen to what works and what doesn't. We might not be able to reply to all comments, but we promise to read them all.