The five enemies of continuous software (and what to do about them)
This is a guest post for the Computer Weekly Developer Network written by Eran Kinsbruner in his role as lead technical evangelist for Perfecto.
Perfecto is known for its ‘continuous’ (as in delivery, integration, testing and deployment) automated, cloud based mobile application testing tool.
Kinsbruner points out that early in any given year, development teams everywhere often find their pipelines filled with bottlenecks, which can put the breaks on release cycles – and ultimately, their bottom lines.
Often overlooked, there are five specific challenges these teams need to overcome to ensure things move smoothly throughout the software delivery lifecycle.
Kinsbruner writes from this point forward:
#1 Tighter release schedules
To move faster with test automation in the face of tighter release schdeulues, teams can either implement faster SDLC methods, e.g. those that are based on BDD or ATDD and/or shift to faster and more stable test frameworks like Espresso and XCUITest (mobile specific).
In addition, consolidating the CI (Continuous Integration) process and having a single CI that serves all teams, will result in products being tested faster and more reliably.
#2 Test automation lacks best practice
Test automation stability and reliability lack best practices — but we do know that test stability can be attributed to two major factors.
- One is the lab and test environment in which the test is running.
- The second is the test code itself.
Assuring a reliable test lab that can guarantee device and browser availability and connectivity is a critical precondition of the overall execution.
Following test development practices ensures that the tests will be less flaky and generate accurate results, continuously. Test code is code — and therefore requires maintenance and ongoing refactoring as products and features change or are retired.
#3 Text execution’s flaky management
Intelligent test execution management isn’t optimised, there, we’ve said it.
With little time between releases, teams should optimise tests executed within the DevOps pipeline as much as possible.
To do so, teams need to be able to focus on the right tests and the right target platforms on which these tests will run.
Today there are few ways teams achieve this goal; one is through analytics and test report analysis that helps identify the most valuable tests and the most problematic platforms. Another – a growing trend in the industry – is the use of machine learning tools that run through the entire test data and guide the decision makers or tools that can more easily generate robust test code.
These techniques help increase product release velocity.
#4 A framework frame of mind
Evolving and maintaining test sets will maximise productivity, but do we have this insight at our disposal?
This challenge can be overcome through a smarter selection of test frameworks.
Having a test framework that manages the entire object repository, the execution at scale in parallel and provides proper insights and reports is the key to maximising test team productivity.
Teams often choose more than one framework to address their objectives – some will be open source tools and others commercials. However, success lies in the have freedom of choice and ability to manage the entire test artefacts.
#5 Synchronisation is out of sync
There’s a lack of synchronisation within the tool stack and organisational capabilities
Similar to the previous point, having the freedom to choose a test framework – whether you are a developer or test engineer – is critical to success. But, if there is no efficient orchestration of the entire testing activities and the dev and test teams are out of sync, wrong decisions can be made and blind spots will appear in the overall quality processes.
In an age dominated by fast and frequent software and app releases (iOS 11 is a good example), the DevOps pipeline cannot run efficiently without testing continuously throughout the software development lifecycle.
Eran Kinsbruner’s recent ebook ‘Best Practices For Expanding Quality In The Build Cycle’ is linked here.