QA Lab: Process-Driven Tools Against Tool-Driven Processes

No votes yet.
Please wait...

Selecting the right tool for testing you should bear in mind that your selections are to be made at the right time otherwise all your efforts will appear to be wasteful. To be more precise, we can get at the meaning of this claim through analyzing the following dilemma: Process-Driven Tools Against Tool-Driven Processes.

Test-driven process (development), also known as test driven design, is a software development life cycle which consists of performing repeated unit testing on the source code. This methodology focuses on writing the code and only then verifying it in QA lab or any other specialized testing room.

The concept lies in “getting something functioning now and perfecting it afterward”. “Once each test is completed, the specialists start to refactor the code and then an alike or the very same test is carried out again. This process is iterative, i.e. it is done as often as required until each unit is working in conformance with the target specification documents. Test-driven development is an essential constituent of a paradigm for bigger software design also referred to as Extreme Programming.

The overwhelming majority of organizations tend to select the tools first and only then define the processes. Based on their bitter experience one can claim that it is a wrong approach to service quality assurance because you become unable to manage the tools as soon as you let them create your processes and drive your everyday operating activities. Tools are just assistant instruments so they cannot be your plans, strategies or organizational objectives, therefore, you should not allow them to have control over you. Instead, if you use the tools at the right time and place you can greatly benefit from them. For example, they will be helpful in the achievement of your objectives.  

This makes sense only if you choose the right time. You should not even mention about tools or PoCs, till you set a common language within your test office/department and define your test processes (like strategies, policies, lifecycle, basis, deliverables, etc. )

There is a test governance pyramid that can be used as a personal guidance for you to move step by step.  Only when you are done with exercising, processes, methods, organization and techniques you can get down to the very last block – the tools.

Comments are closed.