Testing Inputs or how to avoid driving your process with your eyes shut

Back in school, we learned that each process has inputs and outputs. Inputs provide the information and feedback needed to define the internal operations of the process, while outputs specify the deliverables that are handed out.

Some of the biggest process mistakes result from not identifying or failing to correctly map these inputs and outputs.

In the Testing Process the most common Inputs are:
– Application Requirements
– Project Schedule
– Software Designs
– Product and Project Risks
– Defects
– Organization Feedback

Outputs usually take the form of:
– Testing Results
– Reported Defects
– Formal and Informal Feedback provided to the rest of the Organization by the QA TeamLet’s focus now on the Testing Process Inputs:

1. Application Requirements are the most “trivial inputs”, and at times also the most difficult to find.
The main issues in gathering requirements are the lack of a formal and correct definition, the constant change in product scope (scope creep), and the lack of a single person or point of contact for definitions or clarifications.
Even with all these problems, it is imperative to defined a set of application and testing requirements, and sometimes the QA team acts as the catalyst for the formalization of these definitions.
Remember that even if the nature of a project forces you to cope with changes in the requirements, at all times you need to make sure your testing coverage is based on the latest functionality that defines your product.

2. Project Scheduling is almost as important as requirements since one of the objectives of the QA is to provide timely information to all parts of the Organization. The project’s internal and external timelines (and their changes) define the time to start and stop specific tests in your plan.
Most importantly, you are expected to constantly analyze your test results in order to estimate if the application will be ready for delivery on time to the end user.3. Software Design helps you define how to test your application. Use the functional and non-functional design specifications to plan and structure the testing strategy starting from the complex and risky features and changes, which are the places where the most problematic issues have a bigger probability of appearing.

4. QA Risks come in 2 different flavors: Product and Project. Product risks are the ones I mentioned in the previous point and are related to complex and bug-prone features.
Project risks are the areas where a non-product issue may appear. Examples of these issues are lack of technology experience in a group, scheduling issues, geographical or cultural difficulties, or any other issueor factor that may harm or delay the project.
The QA manager needs to take these issues into account when planning the testing strategy and schedule. Important process risks should be reviewed and covered by tests in the same way as their product counterparts.5. Defects and defect-statistics are two of the main points of information for the QA Manager.
Understanding not only the bugs but their distribution and origins help you modify the tactics of the test plans in ways that provide better coverage in places where you need it.

6. Organizational Feedback is the last input channel and the less defined, it refers to all the “other information” that moves throughout the teams and helps you understand what is needed and where things are happening within the project, product and teams.
It is hard to write down how this information modifies the testing process, but any experienced testing manager understands the strength and effects it has on the complete development process.Process inputs serve as a guide to the QA Manager, who constantly needs to asses the situation and make modifications to the plans in order to assure the best possible coverage and timely information. Ignoring or failing to react to this information would be like driving at night with the lights off and your eyes shut, hopping the plans you made before you left home will safely deliver you to your destination.

About PractiTest

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.

No comments yet.

Leave a Reply