Some testers and QA managers won’t admit they use informal testing as part of their QA routine. In some circles this testing approach is considered a waste of time or an unprofessional way to perform a testing task.
I think this is a misconception, and a knowledgeable tester should enjoy from the advantages of both QA methodologies.
Whenever I start to plan a new testing project I make sure to include both formal and informal testing activities into my testing schedule. Here is a simplified and generic example of how I do it:
Stage 1: Requirements Definition
Testing Objective: Assure that all the application requirements are properly defined by the customer and/or project responsible party.
(1) Informal walk-troughs of the requirements where the tester takes the role of “Devil’s Advocate” to make sure that all corners of the application are covered by the current definitions.
(2) Formal review of the requirements to assure that the structure, language and information provided is correct and consistent.
Stage 2: Software Design
Testing Objective: Assure that the design covers all the necessary aspects of the application such as functional consistency, security, backwards compatibility, scalability, testability, etc.
And additional objective for the tester during this phase is to gain a better and more concrete understanding of the application in order to write his formal test plans.
(1) Informal design review meetings with the solution architects and application development teams to go over the high and low level design documents of each part of the system.
Stage 3: First Delivery to QA
Testing Objective: Provide initial feedback to the development team regarding core aspects of the application such as stability, usability, consistency and other elements that may require major coding re-work.
Calibrate the QA Testing Plan according to the initial status of the application.
(1) Formal acceptance test cycle, covering all the major functional and infrastructure areas of the application. Assure that no major bugs or blockers will prevent the continuation of the tests before engaging the whole team on the task.
(2) Informal exploratory testing of the application, to get fully acquainted with all parts of the application and quickly detect most of the low hanging bugs in the system.
(3) Formal initial testing cycle, performing the first complete swipe of the application or at least of all the new functionality for the specific project.
Stage 4: Periodical Deliveries and/or Builds to QA
Testing Objective: Provide input and feedback to the development team regarding the status and progress of the application, while reporting all defects found in the system.
Monitor the progress of the project, providing feedback regarding its major assumptions and risk (e.g. timelines, technological stability, regression status, etc).
(1) Formal build acceptance test, making sure the delivered product is stable enough to enter the testing cycle and engage the whole team on the task.
(2) Formal testing cycle, covering all the areas of the application based on the test plans written with the knowledge gathered from the requirements and design documentation and reviews.
(3) Informal testing activities such as bug hunts and/or role playing testing in order to catch bugs in places and scenarios that were not covered by the formal cycles. These activities should be timed based on the stability of the application and the progress of the project in order to assure that they are efficient and effective.
Stage 5: Final Acceptance Tests
Testing Objective: Assure that the product answers all the customer’s or end user’s requirements based on own their testing scenarios.
(1) Formal testing based on the customer-defined scenarios.
(2) Informal testing based on customer scenarios and role playing testing if possible in the customer’s environment and with their duplicated data.
Stage 6: Postmortem Analysis
Testing Objective: Review the recently completed development and QA processes, gathering all positive and negative feedback from the participants and customers in order to leverage the knowledge and experience learned on this project on to the following ones.
(1) Informal questionnaires and cross-group debates, analyzing all the separate stages of the process in order to create a list of lessons learned and points to re-enforce for future projects and processes.
(2) Formal analysis of statistics gathered throughout the whole process.
My experience is that informal testing techniques are not only valid but necessary during some stages of the development and testing lifecycle, and they provide the most effective way (in planned conjunction with their formal counterparts) to correctly cover an application. In most projects this balanced mix of formal and informal methodologies will provide the best coverage for your system under test.
Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.
Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.
With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.