Time-boxed Software Testing

A primary problem faced by testers relates to time available to do testing. There is never enough time to do all the testing that may be possible to perform. Testing always involves a trade-off, making choices on what and how much to test within the constraints of available time. Look at it this way - if we were to measure test coverage as a percentage of all the tests that may be potentially performed, the test coverage would always be zero. This is due to the fact that for a significant real-world system, the number of tests that may be run are infinite.

Testers need to understand requirements, assess risks and prioritize tests to be performed. It is essential that testers involve stakeholders while making decisions on what to, what not to and how much to test. Time-boxing of testing is not restricted to any particular phase of activity. Time constraints are set from the start and tend to escalate as the project moves towards completion. It is not uncommon for testers to be pressurized to finish up testing quickly or shorten test cycles as the release date gets closer. It is important for testers to be able to clearly communicate the risks involved when deciding on dropping any tests to accommodate requests for shorter than normal cycle times. Stakeholders can use the information provided by testers to understand the risk-return trade-offs and decide on the release.

New Manager - tip

This little tip is intended specially for the folks who recently moved into a Manager role from an individual contributor or a technical engineer position. You now have people reporting in to you. So, how do you deal with your direct reports ?

Let us take a step back and look at the reason for your promotion to the Manager role. Why were you promoted ? In most cases, your stellar performance as an individual contributor or technical resource played a significant part in your elevation. And, your performance as a technical resource either as a developer or a tester would have occurred mostly by dealing with your tasks in an "object oriented" manner. 

What I mean by “object oriented” in relation to tasks is treating different tasks / work entities as objects or modules that have a defined interface for interactions and for the most part exhibiting a black-box attribute that hides their internal complexities. By organizing your work in such a way that you abstract out and deal with the various tasks as distinct black-boxes with a specific public interface to deal with, you make your tasks simpler and easier to handle. Handling complex code or applications as a set of modules interacting with each other via interfaces promotes efficiency and keeps things demarcated clearly. This works well when working with Software development or testing. 

However, when a similar concept is applied to people, things take a different turn. Coming from an individual contributor position, it is easy to apply the principles that worked well earlier to the new role. People however, cannot be viewed as distinct black-boxes; their work life cannot be seen in isolation from what happens outside of work; just by having people assigned responsibilities does not mean that they will be able to handle them; each person needs to be handled uniquely and deserves exclusive focus and attention; to perform well as a manager, it is essential to realize a basic precept of managing - people cannot be modularized or commoditized.