Constant demand for more
We live in a world where updates and improvements see the world faster than anybody can even imagine. Testers need to adjust. New technologies and methodologies of testing pop up like mushrooms after a rain in September and testers need to adjust. There’s the next crisis in your company and there’s less money than usual hence testers are doing more for less – adjust.
A nice way of adjusting is improving test efficiency. Surely it’s easier said than done, however we might try assisting with that particular one way of adjusting. For starters you will require…
…Deep understanding of your current test efficiency
You can’t improve what you don’t know. Nor should you even try doing so. I have witnesses a lot of testers and even entire teams who are not that certain with their particular goals. Can you even imagine measuring efficiency if you don’t know the end result you are expecting? What are testers usually doing? In general, every testing activity may be divided into three processes with three certain goals: a) reducing risks, b) finding defects, c) creating confidence.
Don’t forget about stakeholders. They are also a valuable part of the process and they also have obligations. After all you are testers, tot all-powerful creatures of will-force and magic. These people should help you get certain with what goals are you following exactly.
So now I know what I’m doing, what’s the next step?
So now, after getting certain with your goals simply ask yourself a question: can I actually measure efficiency in every single area? Just consider the following math, what does it cost to track and fix a defect found by testers. Compare it to the price the same fix would cost in production. What are the risks you team is covering actually and how does every single risk coverage cost you? Do the same math for cases, specification elements, user stories, etc. Only deep knowledge in what your team is capable of and how much is it worth will grant you with the power of improving efficiency.
Afterwards you may consider some following options:
- Lightweight test automation. Automating everything may seem like the best way of improving efficiency. But, well, it’s a trap. Return of investments on full automation may go from a complete zero to negative even. Or there’s GUI automation that may be profitable only in theory, over some time, perhaps, occasionally… Despite that automation may be way less expensive. Open source tools and code are opening wonderful gates before anybody.
- A tightened test set. There are a lot of ridiculously heavy regression tests sets, etc. that are pointlessly dragged around from project to project. Every single written test finds its last stand in such a set. However if your automation process in incomplete this is only making testing last longer. Consider every single defect, feature patch, everything going through regression. Try removing the less vital and critical data from the regression set.
- Risk-based testing. This is a nice approach (considerably) when risk reduction is your primary goal. You are testing to make sure no risk takes place in the app after release, right? Try prioritizing those risks. Your test team will not be able to manage such a task on their own. Prioritization needs to be done with testers as well as the tech and the stakeholder teams. Consider potential business as well as technical risks. Determine the most dangerous ones and start tests from them.
But one must enter these woods carefully because quality is still top priority. And reducing cost too much may lead to unpredicted results when your solution sees the world. Think twice before using any of the advice given above. After all you are providing software testing services and not cost reductive services.