The first question any reasonable person will ask after discovering a great new tool is: what does it cost?
deltaTest is a great new tool, so let’s talk about that.
Cost in enterprise software—whether currency or headcount
—comes from a number of different directions:
- License Fees. These can be shockingly high, even with seat volume discounts.
- Infrastructure & Support. Prerequisite hardware and software, plus billable hours to set up up and fix it when it breaks.
- Operational Costs. Using the thing will impact somebody’s time.
- Project Risk. Cost savings are no good if the project fails.
- Consulting. Get a leg up from someone who already knows how.
From a licensing perspective, deltaTest is a win: it’s free! deltaTest is an open-source tool, and always will be.
A deltaTest implementation is very lightweight: just a collection of various kinds of text file. It resides easily inside an existing project infrastructure. Key enabling technologies:
- PowerShell
- Source Control
- Network file share
- SQL Server
If these technologies are already in place, then no significant additional capacity is required beyond appropriate permissioning.
deltaTest enjoys community support like any open-source tool. Users who discover defects are encouraged to report them in GitHub, and even more encouraged to get involved and help us fix them!
Because tests are themselves artifacts of code—written by the same developers writing the code being tested—those developers are usually best placed to support their own tests.
Operational costs are tricky, because they are so much a function of tools and practices that may or may not already be in place.
As a matter of practice, developers should already be writing and maintaining tests—even manual ones!—as they develop code and components. If they aren’t doing that, then obviously adding that task will slow them down. Note that it takes about as long to write an automated test in deltaTest as it does to write a usefully complete specification for a manual test.
Actually running one is much faster! 🙂
Developers who begin writing tests in deltaTest will very quickly begin to execute those tests iteratively as they work on their code. Why? Because the experience is SO much less painful than setting up tests ad hoc and running them manually! So with practice they will be able to perform more iterations, faster… resulting in higher-quality code, sooner.
The bottom line: developers will probably have to learn (or at least refine) a set of skills. In return, the team will get:
- Improved code quality.
- Higher delivery velocity.
- Lower production support costs (because fewer defects make it into production).
- Dramatically reduced project risk!
The final cost area is consulting. This is clearly an optional cost: deltaTest is well-documented and ready for installation, so a team could certainly go it alone.
On the other hand, Test-Driven Development is a rare practice in Data Management and will require a fresh approach from most teams. Experience matters, especially when contemplating a culture change, and a few weeks of proper setup and mentoring can save a development team months of painful lessons learned.