What Is Unstructured and Unplanned Testing?
There is a huge difference between informal testing and unstructured or unplanned testing. Informal testing is not completely anchored by the low-level planning of the steps you want to run, but it is very far from unstructured or Unplanned Testing.
If you ask most testing professionals, they will explain that their testing approach involves a balanced blend of formal and informal testing, mixed to achieve optimal coverage of their application under tests.
Knowledgeable testers will also tell you that Informal testing alongside formal testing requires a plan that will make them work together like a couple of ice skaters performing a routine.
What is an Unplanned Testing test plan?
The Test Plan is the instructions manual for your testing process. It describes the intentions of your project (why are you testing?) and the high and sometimes low-level schedule of the activities you want to perform (how are you testing?).
Test plans can sometimes list the risks you foresee in the project (what are you testing for?), and they may also include things such as resources required (what are you going to be testing with?). Are there other aspects you think are interesting or important to share with your testing approach?
Have an organized approach
So, how do you create a test plan that includes formal and informal testing activities into a testing schedule? Here is a simplified and generic example of how to do it:
Review Your Requirements
Verify that the customer clearly defines the requirements for the application or whoever took his place in the project. Look for completeness and correctness in them, and list any issues you find during your review.
Informally play “Devil’s Advocate” and review the requirements to ensure all parts of the application are covered. Formally review the requirements and ensure that the information provided is accurate and consistent.
Analyze the Software Design
Verify that the software design covers all the necessary aspects of the application, such as functional consistency, security, backward compatibility, scalability, testability, etc.
An added objective here is to understand better the application to write the subsequent test plans.
Informally, schedule meetings with the software architects and development teams to review high- and low-level design documents for every system part.
Feel free to ask questions whenever something “does not sound right,” regardless of whether you have or lack the technical knowledge; it takes a pair of fresh eyes to ask “naive” questions to find the big flaws in the software that were hiding under the noses of the technical experts…
Run a cycle of Initial or Preliminary Testing.
Pass on preliminary feedback to development regarding core elements of the application, such as stability, usability, consistency, and other aspects that could mandate significant re-coding work. Don’t wait to run all your tests; start with those that will give quick and important feedback to the development team!
Informally conduct exploratory testing of the application to familiarize yourself with all the different parts of the application so you can quickly detect simple-to-spot bugs in the system.
Formally conduct an acceptance test cycle. This should cover any major functional and infrastructure parts of the application to verify that there aren’t any significant bugs that might prevent testing continuation before getting the whole team on the task.
Provide Periodical Deliveries from the QA
Continuously send feedback and commentary to the development team about the progress of the testing on the application while providing information about any bugs found along the way, as well as relevant information regarding project constraints such as timelines, regression status, priority, etc.
Formally build acceptance tests to ensure that the delivered application is solid enough to continue into the testing cycle. Then, move over to the formal testing cycle that should cover all the applications, both what is mentioned as new functionality in the requirements and all the regression functionality that should still work as your users expect.
Informally conduct “bug hunts” by assuming the role of the application’s user to catch on to bugs or scenarios not covered by formal testing. Ensure such informal testing is timed alongside the progression of the project to remain effective.
Create User Acceptance Tests
Assure the final result meets the requirements of all the customers/ end users based on their testing scenarios.
Formally test based on the pre-defined scenarios from the customer while Informally testing customer scenarios when possible in the customer’s environment and with their duplicated data.
Post Testing Analysis
Time for the high-level review of the development and QA process. Gather all feedback from any stakeholders in the project, including development, QA, customers, etc., to create a knowledge base to learn and improve from for the following projects.
Formally, analyze statistics from throughout the QA process. Informally, distribute and collect questionnaires, or group debated about separate project stages to gather “take away” points for future reference.
While mistakenly disregarded by some, the right balance of informal testing techniques alongside formal testing protocols contributes the most QA coverage for any application development from design to release.
Searching Words: Unplanned Testing Report, Unplanned Testing
