The new millennium ushered in a new excitement; it’s not every year that a new millennium begins after all. There was a fresh energy in the air – indicating it was time to start doing things differently. This thinking differently reached software development too where we saw the process change from Waterfall to Agile to DevOps in a matter of years.
Only in retrospect can we conclude that indeed the first years of the noughts produced a significantly new paradigm when it comes to the development process.
From my perspective, the most exciting part was the integration of testing into development.
First, There Was Waterfall
In the previous century, R&D and QA were two separate operations running parallel, or more precisely, one after the other. The method, called ‘Waterfall’ sufficed for the constrained technology for the masses that was common at the time.
The Waterfall paradigm had two main advantages: the two teams – R&D and QA, were experts in their respective domains. Their worlds were narrow, but they ruled them with conviction and excellence.
The other advantage was the ease and strength of maintenance. Each team took special care to modify, update and maintain its part of the equation.
There were, however, clear disadvantages that eventually drove to innovation of the entire process:
- QA testers had limited knowledge of the product being developed. This harmed their ability to properly test.
- The process was long, since it consisted of two cycles that didn’t overlap; only after a development run was completed, QA could begin.
- It was expensive. Companies took a long time to churn out each new version, invested heavily in maintenance and, most importantly, needed to have two completely separate teams.
When compounded together, these downfalls led to a lesser quality product. It makes sense – when two pillars operate independently from one another, it’s close to impossible for the end result to shine.
Then Came Agile
As technology became more and more ingrained into everyone’s daily lives, the need for faster releases adhered itself to the agile process. Though even this had its challenges:
- Companies needed to start working on the integration of two teams.
- Companies had to integrate different coding languages; programmers and testers didn’t necessarily work in the same language.
- Training protocols had to be unified.
- The QA team all of a sudden shared responsibility for the overall quality of the product, rather than testing alone; this was a big shift in their mindset.
- The biggest challenge of all was actually shortening the cycle length and developing new working protocols from scratch.
“S” for Selenium
All of the above challenges created the need for a tool, a platform, a solution that would be able to at least partially relieve these new pain points software companies were experiencing. That is to say, Selenium didn’t come about out of thin air. The agile methodology called for it, and Jason Huggins was there to take the call.
Selenium provided a framework for the agile process in which R&D and QA could collaborate using the same language and the same infrastructure. Enter IDE, fast and free. And then came other folks to improve and expand Huggins’ work.
The big shocker, however – Selenium wasn’t perfect.
New Problems Arise
Open source frameworks, Selenium included, are truly remarkable. They’re everything the web should have been: knowledgeable, generous, and attuned to people’s needs. And free! However, they are often exhaustively technical. And ‘technical’ comes with its own price tag.
Specifically regarding Selenium, three main problems present themselves:
Setup
Installing, configuring, integrating and testing a new framework is a massive task. Framework specialists are required, and plenty of time is needed too until seamless integration with the other pillars of your operation is achieved.
Maintenance
The highly technical, code-y environment makes it extremely difficult to apply constant changes, which are frequently required with an agile development process for the modification and addition of features.
Skills
Testers all of a sudden needed to know code. Companies could either teach their testers code, or hire trained engineers to conduct testing; neither option is too appealing. The former is time consuming, while the latter is costly. Also, testers weren’t necessarily technical people that could easily learn code, and professional engineers weren’t all that thrilled to do testing.
These problems led to inflating costs. The FREE tag attached to Selenium (and to open source in general) turned out to be somewhat misleading.
The Story Continues
The beautiful thing about technology is that problems are never the end of the story, but rather the opening chapter of a much more exciting story. The agile process, as clever, efficient and attuned to the market’s needs as it was, lacked flexibility. This led DevOps to break new boundaries with faster delivery times, better maintenance and reduced costs.
CI/CD frameworks, Test Labs and NextGen testing tools contributed greatly to these new and improved performance metrics, but still, some challenges remained in the process:
- The expensive and lengthy setup
- The need to recruit and train more engineers
- Maintenance, maintenance, maintenance
There Must Be a Better Way
We examined software development’s two-decade history with such a close lens in order to pinpoint the current roadblocks that hold back release cycles: time and money will forever be pain points of any project, but testing is a paramount issue that still has a chance of being solved.
It may sound harsh, that testing is the main bottleneck of software development, but from my 15 years of experience in the field, testing has proved time and time again to be the weakest link. This is by no means pointing fingers at the testers themselves, rather, it’s pointing to the fact that innovation in testing is lagging behind innovation in development.
Automated testing has been around for a while, yet it still has not reached its full automation potential. Execution has become automated — running tests in volume, on different platforms and with great speed — which is a step in the right direction. Yet creation and maintenance of tests is still reliant on coding.
In order for software development to take the next leap, all aspects of testing will need to be automated, from creation to execution to maintenance.
Mind the Gap, Close the Gap
The good news is that some companies are already working on developing codeless testing, 100% automated and fully integrated into the agile / DevOps processes.
There are of course different approaches to tackle this, the most commonly known are recorders, which offer only a partial solution. Maintenance remains a major issue there, as is regression testing. When you need to re-record a test whenever you relocate a button, that’s problematic as it slows you down. Again testers need to play catch-up with development; in today’s nearly-instantaneous release cycles, that’s not good enough.
A different approach is codeless test creation, execution and maintenance. One company (full disclosure: I have the pleasure of being on their advisory board) that’s managed to close these gaps is TestCraft, which offers visual and automated test creation (being converted to Selenium code), remote execution environment and simple maintenance.
The biggest gap is always cost. Offering a remote environment for both creation and execution of tests, combined with Selenium code generator and thus eliminating the need to set up a framework – huge sums of money are being saved. This doesn’t affect the cycles directly, but it lets companies jump above a serious hurdle on their way to fully integrated DevOps.
The second gap is code. Industries such as e-commerce and business websites have closed the code gap with companies like Shopify and Magento (online shops) and Wix and Squarespace (content sites) that offer simple and codeless platforms for creation and maintenance. Sites and shops can now be created in mere hours and with minimal cost, which only a few years back was a very expensive and lengthy process.
If a ‘creative’ process as erecting a website was able to be made codeless, there’s no reason why a technical task as test creation cannot be made codeless as well. Code is a very hot gap right now, across many industries. It will be closed, I’m sure of that, in testing as well. It is essential in order to have a fully integrated development & release workflow.
The third gap is maintenance; a combination of the first two – the result of full-codeless approach, a driver for significantly reduces costs. But the most prominent advantage of swift, simple and effective maintenance is time saving, finally enabling testers to catch up to development.
Looking Ahead
Integrating testing into development is proving to be as successful as the integration of automated testing into manual. To that we’ll add the integration of codeless automation, and we’ve got a win-win situation — testers can focus on testing, and coders can focus on coding. Even though the two disciplines are merging into one another, in order to keep the operation working in high capacity, it is crucial to let everyone hone their expertise and free them from rote, time-consuming tasks.
If we’ve learned anything from the shift from Waterfall to Agile to DevOps it’s that consolidation works, and DevOps is the ultimate example of that. It’s gotten us this far, and it will get us to the next stage in technology, whatever that may be.
About The Author – Yaniv Levin
Yaniv is a veteran professional in the testing field, with over 15 years experience in the field. He’s a former functional testing executive in HP and currently the CEO of Tokabot – a sports start-up.
Yaniv is also part of the advisory board of TestCraft – a codeless automation start-up
Image: phoenixts.com
