The Drawbacks of Developing Your Own Test Tools

[article]

tested or demonstrated to work.

Obsolescence
What happens when the in-house created test tool or no longer meets the requirements of the QA team or support the company's newer IT systems for record/playback? Will there be a new development effort? Often times a company might change its underlying IT system. This may cause an in-house developed test tool to become obsolete and irrelevant. With a commercial test tool a company might have the flexibility to upgrade its license or switch to a different test tool with some price difference if its existing test tool no longer supports the new IT system. This option is not available for in-house developed test tools.

Missing Third Party Integration
Some commercial test tools have APIs that allow them to integrate with software from other vendors. However an in-house test tool may not enjoy integration with third parties. Furthermore, the cost of attempting to integrate the in-house test tool might be prohibitive since many resources would have to be allocated to this effort.

Not Enough Time
The development and gathering of requirements to produce a test tool might take several months. In addition a company with plans to create its test tools will first have to decide on a programming language, and back-end to develop its test tools, and secondly it will have to find the necessary resources to develop the test tools. Given a company's existing deadlines, it might not be possible to develop and produce a test tool in time for the various testing phases.

Requirements
Who is going to provide the requirements for the test tool? Many QA teams have testers, or SMEs that have little or no exposure to automated test tools. These testers do not have a firm grasp of what the automated test tool should do, what its use-cases are, or how it should function. Understanding precisely how the test tools will be designed can be a challenge. Another wrinkle to gathering requirements for the creation of the test tools might be that the documented requirements are ambiguous and untraceable. This makes the test tools more prone to customer dissatisfaction and/or defects.

Differences in Opinions and Political Battles
The QA manager, SMEs, and testers who are the end customer of the in-house test tool may have a different agenda or perspective on what the features of the test tool should be. This could introduce a conflict or strife between the development team and the QA team that may not be easily resolved. This would not be an issue for a purchased commercial test tool.

About the author

Jose Fajardo's picture Jose Fajardo

Jose Fajardo (PMP, M.S., and SAP certified) has worked as a test manager for various companies utilizing automated testing tools. He has written and published numerous articles on testing SAP and authored the book titled Testing SAP R/3: A Manager's Step by Step Guide. Throughout his career Jose has helped to create testing standards and test plans, mentor junior programmers, audit testing results, implement automated testing strategies, and managed test teams. Jose can be contacted at josefajardo@hotmail.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09