In a given software development project, the implementation phase is almost always the one after final round of testing. But often it is found that most of the products in live production have faults in them, which was not found in testing or not reported. Some of these issues arise due to certain scenarios which are not common and no one could have ever thought of. But there are a bunch of defects, which occasionally do not get reported as they do not come under any of the requirement categories of Business or Technical. These defects are normally to do with system error messages, which give a direction to the investigation carried out by technical support team in the event of a production issue.

This article looks at ways to find and correct these defects during development and testing phases. This needs a collaborative approach to some of the important phases in software development lifecycle most importantly the technical specification reviews and testing. The steps below are just a set of guidelines, and are not exhaustive. Experiences gained over a period of time in different projects can be added to this list.

Involve the Tech Support Team Reps in Requirements Review
In any organisation, the requirements for a project are reviewed by business stakeholders, the development team and the testing team. As a result the Technical Support team do not get to see the requirements and comment on them pretty much till the end. Not many business requirements have the software supportability requirements documented clearly. If we include the Technical Support Reps, they can add some valuable points like what sort of error messages they should see in case of failure. This may not be complete list to start with, but there will be enough details for the development team to build supportability into the application.

Request a placeholder for Operational Requirements
As a test analyst or quality representative of the project, request for Operational Requirements. Many a times, these requirements are either not documented or documented very poorly. It is left to the author of the Solution Design to address the operational requirements. In the absence of Operational Requirements, the importance given to the system error scenarios and relevant error messaging is relatively low. If we have clear Operational Requirements, it is much easier to address them in solution design, functional specification and testing.

Brainstorm with Technical Support to create Operational Test cases
The test cases to cover the Operational Requirements may need a lot of input from Operations/ Technical Support Team. It is best to brainstorm with them and get their input while creating these test cases. This will leave less room for ambiguities and missed requirements.

Include Test Cases to cover System Error Messages
Once the System Error Messages are identified, appropriate test cases should be designed to cover the scenarios correctly. This may be isolated into smaller test scripts or be a part of a huge test script. As long as the scenario is correctly simulated, it should not matter as to which phase of the project they are executed in. But it adds a lot of value when they are executed during end-to-end testing or implementation testing. This is because theses two phases of testing is closest to how the product will be used in production.

Communicate with Technical Support Team during test execution
Even if we have technical and operational requirements, we see something that is unexpected during test execution phase. If the system behaves differently and shows symptoms of operational failure, try to engage the Technical Support staff to resolve it. This may help us uncover more Operational Requirements, which need to be addressed before the final implementation. This may also help us enhance our test suite by adding scenarios and error messages that we have not thought about.

Conclusion
In the above article, the point I have tried to stress is to work as a team with Technical Support/ Operations to address the Operational Quality of a System. Testing being the first point of call during production failures, the responsibility lies on us to improve the quality by addressing the Operational Requirements. In order to help the Technical Support deal with such issues, we can take adequate steps to address the overall Operational Quality of the end-to-end solution before the final implementation.