When enterprises take on Agile methodologies, first up it requires a radical mindset re-boot to prepare them for doing things the Agile way. Next, it’s a case of picking the low-hanging fruit in terms of what changes will quickly help them become Agile. Often, people start with Lean tools like Scrum, or Kanban. In other words, testing and CI/CD usually come a little later on the Agile journey.
You can’t be fully Agile without Agile testing, and the more Agile an enterprise is, the easier and better Agile testing becomes. It should be a virtuous circle, right? And yet, enterprises often find Agile testing a challenging frontier.
If you’re reading this with a mobility initiative in mind, then you’ll probably have a good idea of how mobility uniquely complicates the landscape of development and testing. Never before have we seen quite so many devices, use cases, platforms and connections in quite such a short space of time. So, if you’re in a quandary about where to go next with testing, here is what you need to understand.
There’s no going back
Traditional methods involve the test and development teams working apart and separately, with little interaction with the business driving the project. The testing is done at the end of the SDLC, there’s little deviation from the original plan and once testing starts then, that’s it. No changes until it comes out the other side.
Mobility projects demand that process speeds up to the extent that those methods just won’t cut it. New products are released weekly or daily, or more frequently in some cases, all thanks to Agile.
Let me spell it out: traditional testing methods can’t support Agile practices. If speed is one of the key drivers to transition to Agile, then testing needs to change too.
Agile methodologies require that we tear down the walls between teams, and nowhere is that more evident than testing. If you want to jumpstart your Agile testing then you need to start ….earlier. Ideally, right at the start of the project. Combine issues and project tracking platforms (like JIRA) with continuous delivery tools to give your mobility project the Agile touch.
What mobility testing means
Most enterprises aren’t ready for the level of complexity that a mobility initiative presents their QA and test management. Mobile, web and hybrid apps need to be tested across several platforms, operating systems and devices, as well as be ready for connections across different protocols. The Internet of Things (IoT) brings a whole host of exciting challenges from a testing perspective, but leaves many enterprises woefully unprepared for what’s ahead. There is no one-size-fits-all when you’re testing products as different as smart footballs, an ingestible health technology or a fitness bracelet. Fortunately this is where a specialized app dev partner can really help. For example, we’ve tested more than 250,000 apps in our two test centers, each site covering 300k square feet, encompassing our virtual labs with over 3,000 real devices. Pretty cool, huh?
When to automate?
If you’re striving for rapid integration and delivery, then I probably don’t need to tell you that manual testing alone is unlikely to achieve it, especially if your mobility project is particularly complex, far-reaching or unusual. Knowing when and what to automate is key for successful testing. It’s not always easy, though, weighing up what could be tested with the cost implications of automation. There are many tools to help you on your way (Jenkins, Selenium, Appium, Perfecto and our own QMetry Automation Studio), and an experienced app development partner should provide guidance too.
Keep in control
Linked to the issue of rising levels of complexity is how to maintain control of all areas of the SDLC. Numerous tools exist that will help you keep on top of all the phases of testing such as administering, organizing and maintaining mobile test libraries, and tracking and reporting performance. We highly recommend QMetry Test Manager from Infostretch, but other great alternatives include HPE Quality Center and ApTest.
Test everything at once
Compressed development times require smart workarounds to age-old problems. Consider investing in tools or services to help re-create real-world conditions in which multiple devices are synchronously tested. This relies heavily on automation and simulating “in the wild” performance and will help you realize significantly improved release times. Perhaps more importantly, it quickly identifies which projects will fly and which should be de-prioritized or adapted. When choosing the tool, keep usability top of mind; e.g., does it matter if you access it via the cloud or a standard browser interface? Will it work on any device?
I hope this has been a helpful introduction to advancing your Agile testing. Please feel free to share your experiences via the comments section or by getting in touch directly.
I call it a philosophy! Agile development using sprints is not new to the software industry. It’s an iIterative development where requirements and solutions evolve...