Collaborations Between Your Testing and Other Popular Tools

Do you test your software? That probably seems like a trick question. Everybody does at least some kind of testing, if nothing other than running the application to make sure it does the thing they just added code for it to do. But not all testing efforts are created equal.

There's the sort of haphazard testing that I just described, and then there are mature, coordinated testing efforts that you see from organizations responsible for high quality software. These efforts generally involve QA professionals, test automation, test case management, and a general overarching game plan. Software is complicated, and ensuring that it behaves properly is perhaps even more complicated.

To really be effective, organizations have to be disciplined in picking and prioritizing what to test. Think about what this actually means, when you get down to brass tacks. They have to break their software into thousands and thousands of discrete pieces, figure out how to test those pieces, and then prioritize and delegate those efforts across a team of people. Testing involves an immense amount of collaboration and organization.

Bottom line: managing your testing is largely a matter of managing communication.

Having worked in many software groups over the years, I've seen how managing this communication can go sub-optimally, if not badly. Consider it a matter of software silos.

As a software developer, I would keep Outlook open at all times, and live in my integrated development environment (IDE). To a lesser extent, I would sometimes consult the tool used for tracking requirements (whether that was a full blown piece of software, a Sharepoint site, or even Word documents on a file share). And, as a good citizen, I'd periodically open the defect tracking software to look at how I could help or what was assigned to me.

But, as someone who earned a living doing knowledge work requiring much concentration, that was really my limit for systems I wanted to monitor. Adding more cognitive weight started to make me feel unproductive.

Over on the QA side of things, they had a similar cognitive burden for their knowledge work, but with a different set of tools. They lived in Outlook, a testing environment, and their test management software. They'd run manual tests or execute automated scripts, and then they'd log results. And these results didn't just include a thumbs up or down. They had detailed execution information, environmental settings, recordings of what happened, and contextual notes.

And all of this led us to sort of a cognitive impasse because of the silo-ed nature of our systems.

I didn't want to log into their unfamiliar test case management software and fumble around to see what was going wrong. I'd rather have a ticket in defect tracking. On their end, they didn't want to replicate their efforts at recording problems in a second system, and understandably so. So in the end, we wound up communicating using the lowest common denominator: email.

All of these impressive, helpful tools at our disposal, and we used the one not really designed for any of us. I had access to my IDE, capable of sophisticated debugging, managing stack traces, and all sorts of error hunting possibilities. I also had access to the defect tracking system, which had plenty of room for description and great capabilities for issue history and search.

QA had tools capable of recording and executing test runs, playing back scripts, and capturing intensely detailed reproductions of issues. They had an impressively detailed handle on the exact state of the software.

And yet we collaborated by pasting text into emails. What a waste.

But collaborations eliminate that waste. Having tools that offer integration with others allow everyone to work where they're most comfortable, but without duplication of effort.

This is why Sauce Labs offers such collaborations through their third party integrations. Folks responsible for testing can manage and execute their scripts, and then use these collaborations to automatically send the message elsewhere.

Over the years, I've used a lot of tools for issue tracking and application lifecycle management (ALM). As I mentioned earlier, this is where, as a developer, I would have liked to find failed tests that needed my attention. And, while many tools for this type of things still exist, Atlassian's JIRA has come to dominate the landscape.

One of the collaborations available to you integrates Sauce Labs with JIRA. People responsible for testing can create and execute tests as they normally would. And then, with this integration enabled, they can create a JIRA issue for developers as easily as clicking a button. No duplicate labor, and no tedious data entry.

This neatly solves the potentially adversarial workflow between QA and developers. Neither wants to log into the other's system, and neither wants to perform manual data entry. Now neither one has to.

Of course, the potential for integrations doesn't stop with JIRA or even with ALM tooling in general. You can also integrate with HipChat, another Atlassian product.

HipChat is an instant messaging and chat service, often used within the enterprise. If a company invests a lot in Atlassian tooling, they may logically decide to use HipChat for its nice integrated capabilities with the rest of their tools.

Chatting and instant messaging play an important role within organizations, particularly larger ones. It sits in the sweet spot between completely asynchronous, low priority communication (email) and highly synchronous communication that demands full attention (in person meetings). Chat is synchronous but usually non-invasive. And it also scratches an itch in organizations where people are geographically distributed or sitting in different areas of large buildings and campuses.

So it's perfectly reasonable to think that someone executing tests might ping a developer about test results. With the HipChat-Sauce Labs integration, you can do this seamlessly, without unwieldy copy and paste or general friction. This integration packs a lot of information right into HipChat without being obtrusive in the actual chat screen itself.

Of course, you might not use HipChat in your organization. In fact, you might very well use Slack.

Slack is a team messaging platform with some killer features in and of itself. But one of its huge selling points is its huge ecosystem of integrations. This has resulted in it going from promising upstart to dominant player in the world of chat and messaging. If you're anything like me, you belong to not one, but several, Slack instances.

As many other organizations do, Sauce Labs offers a Slack integration, and it's very easy to set up. You just log in to Slack, use this link to install the plugin, and authorize your credentials. That's it. You're ready to start collaborating.

Once in place, you can paste the URL associated with your automated test and see results and metadata right inline in your chat. This creates a QA-developer workflow of "execute a test, copy the URL, paste it into chat, and say 'hey, take a look at this'." That's a pretty powerful way to interact.

I've been in the software industry a long time. The story I told about the gap between QA's tooling and my tooling took place in the late 2000s. At that time, this sort of thing was the norm, and there was no real expectation of integration between tool sets. If you wanted that, you'd probably have to write it yourself.

But a decade later, the world does not work this way. App stores and plugin architectures for apps have become ubiquitous. It's completely reasonable to expect your tools to integrate with one another. But you shouldn't just expect this -- you should take advantage of it. If you don't, you'll waste your time on manual labor while those around you are solving the problems that matter.