As a CIO/CTO, you are well aware of the challenges of creating a strategy that accounts for the demanding nature of your business. As if that weren’t enough, you are also tasked with proactively adjusting to the evolving nature of the IT industry. While many organizations have moved beyond the days of considering IT as a cost warehouse, stretching every dollar in your budget is still a vital component in accomplishing your goals. When choosing a technology partner, there are a few things that you should consider when doing side-by-side comparisons. One of the most important considerations, while often overlooked, is Quality Assurance.
Developers vs. QA?
At the surface, Quality Assurance (QA) sounds like a process that involves a room full of obnoxious individuals who lurk through other’s work, happy for the opportunity to find something someone else did incorrectly. While this may sound like playful exaggeration, there are organizations who feel this is the best way to approach QA. They create a division between the development team and the QA engineers.
A process is only good as the weakest point. In a manufacturing environment, one might identify these points as bottlenecks. But often eliminating one bottleneck exposes us to another. The same can be said when development and QA are isolated from one another. Including the quality assurance people as part of the product team, and henceforth as part of the overall development process, we mitigate the risks that are present when people are operating in a vacuum.
Unity of Vision
Now that we’ve made the decision to integrate QA as a component of the product team, we need to ensure that we have defined expectations. Whether your team is operating in waterfall or agile, it is important to ensure that your team understands the vision of the product from the time the project is initiated. It is important to charge your entire team with the responsibility of bringing the project owner’s vision to fruition. Many organizations make the mistake of running the communication of this vision through hierarchical channels (upper management -> middle/lower management -> non-management). Using this tactic, at best your team can rely on the artifacts that should exist in your application lifecycle management tool (i.e. Team Foundation Server) to identify the vision. It is more likely that this hierarchical form of communication results in a very scary reality show, starring your product and project members (emphasis on the fact that we refer to these folks as project members and not a team).
Artifacts and User Stories
At this point, we understand the importance of creating a unified vision from the moment the project is initiated. The next important item we need to address is ensuring the appropriate artifacts are created and managed as part of the processes that have been put into place (which obviously would vary based a number of factors, including whether the project is agile/waterfall). This is where you can really begin to separate the novices from the experts. A mature partner with solid development and QA practices will ensure that the artifacts articulate the true requirements of a given body of work—i.e. the user story—as it relates to the product vision.
Articulation of requirements is a key component of creating real value as it relates to quality assurance. Driving a true definition that encompasses the product vision is the difference between a software tester and a quality assurance engineer. While the difference between the two may seem subtle at first glance, this really can be the difference between testing ad-nausea, and testing with a plan and purpose.
There are a number of other factors that can dictate whether a product team will be successful. These factors really center on the proficiency of the team members and the processes that the team adopts as part of their strategy. While these are obviously important factors, it would be difficult to really evaluate a partner on those facets of product development. These are things that can be evaluated based on a partner’s reputation. That said, take a few minutes to engage with the companies you may be partnering with to solve a business problem. Ask them a few questions regarding their team composition and QA practices. The question you really should be asking yourself is what the true cost of your project is. Can your business afford to enter into an engagement based solely on the cost, or do you want to partner with a company that believes in procuring solutions that demonstrate quality-assured craftsmanship?