Ad-hoc testing in a vendor environment

Ad-hoc testing in a vendor environment
I am sure we all get this, ad-hoc testing. The definition is simple, if the testing was not properly planned, scoped and resourced, and it just happened after a conversation from a meeting or over the phone, it’s mostly like an ad-hoc testing. Like it or not, this is often what tests will have to face in their daily practices, it is even more of a case when you working inside a vendor environment, where testing engadgements are likely to strike in small chunk and with very little or no early indication of its arrival.

Personally, I found ad-hoc testing can be a bit handful sometimes. More often than not, what the ad-hot testing achieved at the end didn’t really meet the basic objectives from testing point of view, in some circumstances, it could even ended up with lots test scripts produced, but adding very little or even no value to the business. I have to say, I always became frustrated when that happens.

Throughout the ad-hoc testing that I worked over the years, I found the following areas to be particularly challenging.

• Very limited budget. Budget is always limited, unfortunately, testing is probably the last thing that’s on PM’s mind, this inevitably leads to even more reduced budget. Limited budget always directly translates to poor testing quality.
• No visibility to the long-term plan. Because testers were rushed in at the last-minute, kind like fire fighters, they were only able to see what’s in front of them and get those done. This is useful in the short run as it directly saves the PM’s backend, however, in the long run, this approach is not going to be sustainable, and will fail to work when the testing effort became too large to handle in just a few days of effort.
• Unrealistically aggressive deadline. There is nothing wrong with aggressive deadline, but if it’s unrealistic, there is going to be problems. Trying to squeeze a 4 weeks testing job into 1.5 weeks is just not going to happen. It puts a lot pressure to the testing team to meet the deadline, there is only 1 thing testers can do when under deadline pressure, that’s to reduce the testing quality.

The unfortunate thing is that we can’t really avoid ad-hoc testing, as they generates revenue to the organisation, they brings possibilities of more big contracts in future and they fill those non-chargable work slots very nicely. So I personally found some ways to help me work easier with ad-hoc testing engagements.

• Act fast, as soon as you become assigned to a testing work that even vaguely looks like an ad-hoc testing, start auctioning on it.
• Be proactive, PMs, BAs, Solution Architects are always busy, especially when the project has reached a point where they need testers to be involved (a sure sign when project didn’t go as planned), be proactive, ask all the questions you need to, because if you don’t, it will become your fault.
• Have a plan, because you only have very limited time to work with, the key is to produce a plan and get everyone agreed on it. This essentially serve 2 purposes, to keep you focused on what needs to be done, and cover your backend if things went the wrong direction. So do your planning, and get key stakeholders agreed on it.
• Focus, it is important that you focus on what’s been agreed, don’t get distracted by other things you found in the project, if it’s something that you think should be covered, don’t do it without approval from the project.
• Communication, frequent updates are always welcome to keep everyone in the loop, and reduces the chances of you doing wrong things.
• Prioritise, you will not be able to test everything, so plan your test, assign a priority to each test scenario or test case if it’s possible, then start from the ones with the highest priority. This is a good technique the most in least time.

Advertisement