Small projects in QA: what can be easier?
Have you ever found yourself in a multi-tasking environment dealing with a range of small IT projects at the same time? Chances are, yes. If that is the case, keep reading, as it is my goal with this article to provide recommendations that will help better set priorities, allocate tasks and balance the workload among the participants, using the example of small-scale projects in software testing.
Most people think that working with small projects in QA is quite simple, because they are short-term, small and do not require too much effort. But they are quite mistaken. Imagine 15 small QA projects “in the task list” for one tester in one month. You might say 15 different tasks can be “stacked” within one large project, nothing unusual. But let’s have a look from another angle.
Each of those projects is headed by a project manager, which means you have to deal with 15 PMs monthly and about 45 software developers, each of whom has various questions, desires, plans and personal interests. This is when managing the workload and still managing to be effective can become challenging.
And it’s no wonder when each of the 15 PMs requires his/her project to be tested as soon as possible; many may say they “want it done yesterday.” In order to control the flow of spontaneous desires PMs express, and have a clear plan, you need to use a Query Forecast for the near future. This instrument is considered to be indispensable in these types of circumstances.
You can “shape” it with any convenient form (MS Outlook, Jira, or any other tool that allows you to obtain systematic information). What is most important is that you not waste your time questioning each of the PMs, and make it clear to the development team that they must provide planning info up front.
Once a plan is in place, PMs tend to get “on fire,” and they all want to test the projects the same day; no one is willing to concede. This is when the “live line” principle is applicable – the team that sent info earlier and chose a free day captures the tester’s attention. This encourages project managers to not postpone things until the last minute and promptly respond to such requests.
The “live line” principle certainly has value when it comes to improving proper management; however, some other circumstances should be considered. Some urgent projects may have a release date right around the corner. Quite naturally, such projects should come in line before less immediate ones. Builds are also different in size. One may need four hours of testing, while another may need 32. There is no need to make a small build wait a week. Sometimes plans change; imagine the build, planned for instance, from Monday to Wednesday, has been canceled. Accordingly, with these three days freed, we can admit another project (the “free cash” principle).
When a project manager is a former developer himself (which occurs often) and burning with desire to check bugs just after fixing, he may focus on one bug when handing it off to the tester while not mentioning 50 other existing bugs, which is unfair to the tester. In order to prevent a nervous breakdown for yourself, be clear with the PM that the build will be accepted for testing only when all active defects have been corrected.
Incorporating “risk” time into the testing timeframe you promise to the PM is generally acceptable. If you end up completing the project ahead of the estimated time, of course, the PM will likely be grateful.
Regarding timeframes, another consideration is that developers are rarely punctual in providing builds for testing. For example, you were promised to get one at 9 a.m. The developer arrives at the workplace at 10 a.m. and says the build will be ready in a half hour. Midday arrives, and you are informed that the developer is already in the process of writing the notification, but in the evening, the developer says something went wrong and the scope of work will be provided the next day.
Now we have two problems. The first is that you already have another project planned for tomorrow, and the second is that you ended up with no workload during the day. The solutions to these two problems are flexibility of staff planning and a “pool of tasks.” Thus, employees are able to solve the problem by taking the task out of a pool, or offering assistance to an overloaded colleague.
Testers usually deal with projects containing two hard limits: overall timeframe and time spent for a particular project during each day. For such projects, you always need a pre-planned strategy, and the approach of “we’ll see how it goes” does not work. So, set a time limit – for example, a half hour on research and an hour to create test documentation.
Another situation that could arise is when a lot of different testing combinations are needed. For example, a webpage or an application form of any kind may have five drop-down lists, each containing 50 unique values. To check all the unique combinations, you need a lot of time, which is not always acceptable for small projects. In such cases, the test matrices are applied in order to check optimum combinations for a limited time.
In conclusion, one should say that working with a large amount of “small” projects is not so simple. The advice presented in this article could be useful while managing several small IT projects as well as bigger one with many tasks. You will find you have a significant advantage if you learn how to incorporate the aforementioned techniques.
