Ultimately the goal of these best practices is to make sure as many issues as possible are prevented from making it to production.
A. Pre Validation
Communicating in test plans what will NOT be included in your validation is as equally important as what WILL be included in the analysis.
Testers should get involved as early as possible in project meetings before requirements are even talked about where they can get an idea of the size and scope of the project from a high level, as well as how the software is going to be tested.
Rather than raising questions late in the process, compile a list of questions about the product that will be under test and hold a meeting with the technical leads to avoid confusion, oversights and costly hold ups later down the line when racing against the clock.
Have all stakeholders review the risk analysis, requirements, design document, test plan, and test cases well ahead of time. If any modifications need to be made to correct errors in interpretation there will be plenty of time without added pressure.
Analyze needs for hardware, add-on programs, browser versions as soon as possible.
If the test team requires anything and tickets have been opened, they should be followed up on. Things should never sit idle because it’s a sure bet that if the QA lead doesn’t make it a priority no one else will.
After all test cases are written a mock run should be done before the actual validation. This will be a verification that testers have all test data needed, test accounts, profiles and permissions required. It also allows them to get very familiar with the application under test so that by the time validation commences there are no surprises.
If QA historically does front end user validation via black box testing, have development conduct their unit tests from a logic based white box approach. This will automatically balance and fill out the testing effort for a more thorough analysis of the application.
Once all of the code has been implemented to the test environment perform a high level smoke test. This is the only opportunity before the real testing begins to catch if the test environment is missing a component, code hasn’t been deployed in its entirety, code hasn’t been deployed AT ALL, or any segment of the myriad of middleware is even up and running. All of this can save an enormous amount of time troubleshooting false positive results.
B. Validation
During validation it’s essential to update defects and conduct defect reviews on a daily basis. It is also here that the expectation in the frequency of build releases is set. This is especially important if the changes involved require a complete round of regression testing after every build.
At the close of every test day forward a brief testing analysis report consisting of the number or type of cases run, all passes and failures, total number of defects found, severity of defects found and any blockages to testing that need immediate resolution.
C. Post Validation
This will comprise all test cases run by functional area covered, all regression analysis results, and a summation of suitability for promotion to the production environment. Business owners can then make the determination as to their comfort level with known issues or constraints in light of the final deadline and make the familiar “go/no go” decision.
When confirmation of code promotion to the production environment is received a high level analysis should be done to confirm that all of the requested changes have been completed.
