Are APM tools used for testing or for monitoring performance?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
On days when I am feeling a little rebellious, I like to pose odd questions to IT executives to challenge their thinking about how we develop software. One of my favorites is, “Why do we manually execute the automated test suite?” It does seem ironic to me that test automation is a largely manual task.
Along those same lines, I frequently ask the question, “Why do we give the testing tools to a separate QA group when they are neither responsible for creating the bugs nor able to correct them?” It has long puzzled me that we continue to allow developers to hand over code that has not been fully tested when we have in our power the ability to rigorously exercise the functionality and operationally test the executables before they end up in the hands of the quality and release management teams.
As the velocity of development accelerates, and the number of simultaneous development streams increases to an almost unmanageable extent, we have orders of increased magnitude and complexity added to the development process. With this, we have the introduction of significant risk, and much loss of the traditional control we have exerted over application delivery activities in the past. Additionally, we are responsible for ensuring applications are both functionally correct and that they continue to perform in accordance with the topology and chronology constraints they have. Never before have we been so constrained by methodology and regulations. So it is no wonder then that we struggle to keep quality, delivery times and cost under control.
We all know that the earlier errors are detected, the cheaper they are to remediate. So the answer should be obvious-- automated testing needs to move further up in the lifecycle, and that includes application performance monitoring tools.
Of course, more tools earlier in the lifecycle means more licenses and a potential bonanza for the software vendors. But contrast this with cost of remediation of a production outage and the consequent commercial losses as a result of that outage. Even a reduction in service levels today may have massive financial impact and, in some case, legal implications and adverse effects on the corporate reputation.
“Automate, automate, automate!” I heard George Laurie of Forrester say recently. He’s right. We have the technologies we need to bring the same rigor to application delivery for ourselves as we have been delivering to our very own finance, HR, warehousing, manufacturing, lab, sales and every other department in the organization. If we can build systems that are accurate to the penny every second of the day through automation of the processes in our finance department, we can surely turn that same skill set on our own processes.
We have extraordinary tools today for monitoring the performance of an application in production. We should turn those tools loose on the development team.
This was first published in August 2011