The iTKO Difference: Test Execution and Quality Strategy
Rules we all live by!
Before they get to know us, customers often ask us how we are different from the other testing software vendors out there. There are three big differences you should know about us right up front.
1. Everyone owns quality.
2. No manual testing or coding.
3. Instrument and test everything.
These three elements of iTKO’s approach go hand-in-hand. Everyone must own quality, not just developers or QA teams. Everyone can’t own quality if they are manually testing or coding their own tests – most will give up on testing. And to eliminate manual testing, we need automation, which means you must be able to make complex software testable.
How does this affect my company’s bottom line?
As businesses attempt to become more agile, their software hasn’t kept up. Yes, service-oriented architectures have delivered new levels of flexibility and functionality, but that increase comes at a huge price in quality. Every new point of connection becomes a potential point of failure.
Software failures in production hit the bottom line hard. Errors and problems become much costlier to find and fix. Software failures drive lost work cycles, customer failures and lost revenue.
Most of us are familiar with the old “waterfall” method of development. Testing on an infrequent or episodic basis, or “acceptance testing” only, may seem like an expedient route to meet requirements, but it creates lack of predictability, more costly change, and more visible failures.
We call this idea “mistakes hurt, misunderstandings kill.”
Developers might be able to find structural bugs or mistakes in their own programs, but they can only test for how they think the software should work. Since testing is largely a technical discipline, and the software is untestable until near completion, the business and QA side don’t get involved in testing.
This is not just a question of finding “bugs” anymore. What if the developer built a perfectly solid program, but misunderstood the business requirements? Misunderstanding the requirement can completely fail a project – much more rapidly than a mistake. As seen below, without the involvement of everyone earlier in development, you are headed for a cliff.
So what is the answer? How does my company get “agile?”
Continuous testing, over every distributed component, is a goal that remains out of reach of the enterprise. Why?
You are trying to move to a continuous, iterative test process, but since only developers can really code tests, you run into the same wall when the business and QA teams must wait until the end of development to help.
The concept of Continuous Integration is considered a best practice. But if your developers are “in the bubble” of test-first, while the rest of the team is outside, it will take you nowhere fast. Compare it to running hard in one of those exercise wheels you see in the mouse cage.
How can companies actually make test first happen?
When everyone owns quality, continuous testing happens. With LISA, the business gets reliable value from software at a lower cost. Because LISA is no-code, your non-technical teams can dig in and even test deep components far before release. Developers save hundreds of hours coding tests and test clients, and benefit as well by being able to apply a “test harness” to their custom code to make it rapidly testable with LISA.