Originally Post on April 28, 2013:
One of the new job responsibilities in my current role at work is to help guide the development of a QAT group within our Systems Development Department. QAT, for those of you not indoctrinated, is Quality Assurance Testing. For our company, this is somewhat of a new concept. In the past, developers, analysts and project managers have all accepted / tackled the responsibility of testing and promoting new applications and features. That testing was both technical/feature based as well as UAT (User Acceptance Testing) focused. Those same developers and analysts, and in some cases, project managers have also tackled the long-term responsibility of supporting the application and features. That support, in many cases, did not have an expiration date, nor did it have real business hours. Along with support also came documentation. Team members often took their own notes or wrote their own support procedures, generally for their own use, so those documents were frequently biased to a particular skill set or set of experiences in the lifecycle of the application. After years of frustration and angst, and based on a desire for consistency and objectivity, we as a department made the conscious decision to dedicate resources for these functions. Now, we have the daunting task of actually figuring out how to do it.
After a few long conversations with teammates and colleagues, I wrote on the whiteboard 3 questions that I believe are at the heart of this new QAT department. I believe these questions are fundamental, specific, necessary, and ordered according to their importance to the process of Quality Assurance Testing:
1) How do we properly and consistently test applications, systems and features? 2) How do we methodically and consistently document systems and support scenarios? 3) How do we consistently supply effective support from all team members?
Since I have already admitted to a necessary order of operation for these questions, let’s begin with question #1 – How do we properly and consistently test applications, systems and features? This has to be the first question that you answer for a couple of key reasons. First, technical testing is both obvious and, unfortunately often overlooked in the development of sound and effective systems and applications. Bug testing and fixing by technically sound and objective teammates is essential to overcome the nature bias of the creative process. Our Development team, like most, is filled with extremely talented and committed developers and analysts, but even the best talent in the world cannot overcome the limitations of reviewing a critiquing one’s own work. An objective set of eyes, trained to understand the development process, is the most effective way to identify potential issues and flaws in an application and correct those issues before the application or system goes into production.
The second key reason this question must be tackled first is the role and input of the user community. It is not very hard in any project, especially those larger and more complex projects, to lose sight of the needs and desires of the user community. All projects should be driven by a specifically defined set of requirements, but even articulate and specific requirements can be interpreted in different ways. Developers can from time to time find themselves writing and creating a product that meets, to the letter, the requirements they were given, but the spirit of those requirements might still be lost in the development process. A well-defined QAT team should always have the needs and necessary functionality of the user population in mind as well as a well-developed process to test the realities of that philosophy. Consistent and effective UAT processes should be maintained and deployed by an objective group of resources. If this is accomplished, at the end of the day, you know you have a system or application that will be accepted, used and appreciated by your target audience.
This brings us to the second of the three questions we must answer – How do we methodically and consistently document systems and support scenarios? This question logically follows the first question. Once a functional and user accepted system or application is developed and tested, all of aspects of that product must be documented to ensure that it can be properly maintained and deployed as it was intended. In a perfect world, once an application is developed, tested and found to be functional and complete, the development resource will be assigned to another project and move on. Once they have engaged in another assignment, knowledge of the last assignment begins to slip away more quickly than any of us want to admit. Hence the need to work with QAT to hand off that knowledge while it is fresh and accurate. That handoff should be complete and consistent for every project. QAT teams must develop processes to ensure they learn everything they need to know in the documentation process to ensure long-term support and maintenance is possible without unnecessary development resources.
A second aspect of proper documentation is a consideration of the many forms in which it must be written and the many audiences it must address. Good system or application documentation takes into account user populations, tier 1 helpdesk support, tier 2 QAT support, and tier 3 development support. The documentation must take into account the skill set of its audience and the ways each audience may use it. Users may simply want FAQ-type answers to everyday questions. Helpdesk associates will want the same thing augmented by more technical resources related with more common technical issues. QAT will want significant technical details including testing results and deep-dive functional parameters. Finally, development resources will want exhaustive details including development comments, coding methodologies and other information to ensure they can support future rewrites or system integration work. There is never a guarantee that the original developer will be available to perform future work on the system.
These various levels of documentation serve another purpose beyond meeting the needs of their defined audiences. By providing consistent and accurate documentation at every level of system or application interaction, you can reduce the need to escalate support issues to higher cost support personnel. The more end users can solve their own problems, the less calls you generate for the helpdesk. The better informed the helpdesk, the less escalations to QAT. The better armed the QAT team, the less interruptions created in Development. Teams can focus on what they do best without constantly supporting trivial issues.
This brings us to the final question in our trinity of QAT processes – How do we consistently supply effective support from all team members? As we mentioned in our contemplation of Questions #1 and #2, sound testing procedures and good documentation should reduce the overall number of support issues, especially those issues reaching beyond the helpdesk to QAT and Development. That being said, no system is perfect and a strong subset of support resources will be necessary in any successful QAT team. There are several key points in any effective support structure including:
· Communication – Understanding the “how’s”, “why’s”, and “how often’s” of support communication is critical. The QAT team should define the various communication channels, how they will be utilized and how frequently in the course of any support issue.
· Documentation – As we learned when considering system and application documentation, consistent and accurate information is critical in the support of any system. Support ticket information should be maintained and stored centrally. Problem resolution info should be recorded and shared with all involved. This allows the team to learn from their mistakes and reduce the fix time in the future for similar problems, if not eliminating those problems altogether in the future.
· Cross-training – Everyone cannot be an expert in every system or application, but everyone can be taught the basics and made aware of the power users and best technical resources. Anytime you can reduce the time it takes to find an answer, the time you are freeing for other more productive work.
I fully recognize that answering these three questions is not a simple task and I also realize it is often difficult to keep the answering process in the right order. Support issues arise before documentation is complete or distributed. Documentation must often be started before testing is done. I view the order of the question answering process as both a best practice scenario as well as method to track system milestones. Development work is not complete until testing is done and signed off. Testing is not complete until all relevant information is gathered and documented. Documentation is not complete until all users and support personnel are informed and trained. And support…well, support is simply never complete until an application or system is decommissioned. If we focus on and strive to meet these milestones, I think we will lighten our overall burden and function in an IT system lifecycle we can all live with.
Comments