Are you really agile testing or is it a buzzword you use for management however still very traditional in approach? Sean Rand, Senior QA Engineer, Nephila Capital, explores how agile we truly are using his own experiences as a temperature gauge.

Agile testing is a topic close to my heart as over the past number of years having spoken about it at conferences, discussed with industry leaders, companies and colleagues trying to really drive out if agile practices have been utilised successfully in workplaces. And the majority of my findings are that it’s not close to being successful in half of what I hear, which might be a shock to some.

Agile testing has become a real buzzword in development and testing teams, still to this day employers request agile experience but I ask why? Surely a proven track record of fast frequent delivery is further reaching than knowing the principles of agile but not applying them successfully in previous roles? I’m a firm believer that agile testing and development methodology has brought us some great advancement in technology delivery models; however, because the word agile can be all encompassing, this has allowed us to hide behind it at times.

Building an agile test team

Whenever I’ve built test teams in the past, and especially as I grow my team within Nephila Capital, I do not chase candidates who constantly push the word agile testing in interviews without backing it up. I let them describe their delivery methods and workings with developers/business users/product owners, only then from their narrative can I clearly derive if they’re a suitable candidate or not to work in a highly agile test‑driven world that is the environment we work within. It’s so easy to say the words: agile, delivery, testing, frequent, release, sprint; however, to form them into a structure that truly works and works for your industry and business needs, that’s a different story.

This leads us into the key fundamentals and principles that I have found to be productive ensuring the agile testing strategy delivers frequent, fast, on point, tested and accepted features released to production giving business value via a measurable feature road map:

• Work in sprints and make sure everyone from the CEO through to the intern knows what sprints are and why run in a pre‑determined time blocks.
• Sprint duration is aggressive and currently two weeks for the delivery of development, testing, user acceptance testing and the push to production. Thinking of taking a holiday? You’ll probably miss a sprint including a push to production; this shows how constant the feedback loop turns.
• Expect at least 3 ‑ 4 releases to the test team during the given two week sprint. This is an every other day method understood from the whole team.
• Sit tightly coupled. Tester, business user and developer sit a few feet from each other or at least interact many times during the day together remotely via video calls as opposed to just email.
• Continuous integration (CI) build servers, TeamCity, executes all our automated tests (unit, integration, GUI) for each sprint, feature or bug branch.
• Green builds via CI are release candidate branches only; this gives the developer a faster feedback cycle when pushing code ensuring regression issues haven’t been introduced.
• The test team must strive to write automated tests before a line of code from a developer has been written.
• Ensure the business/product owner knows what tests are written upfront, have them write tests with the tester and share those tests with the developer at all times.
• QA is responsible for the quality of the testing and bug finding but isn’t responsible for overall feature quality that’s owned by the agile team.
• Push the limits and let the team know that it’s ok to fail, as long as you learn from those shortfalls.
• If you test the same path twice, then automate it the third time as you don’t want wasted time on a test path which can clearly be taken care of via an automated test.
• Manual testing is paramount in agile, especially the form of exploratory testing.
• Ensuring a large regression automation suite is in place is key allowing the focus of the tester to be present on the feature(s) being delivered.
• Finally a really important notion in agile testing is to be a core member of a successful delivery team, not a member of a development team! I prefer to deliver than develop and never deliver…Food for thought for many of us I’m sure.

Giving the above I am fortunate to have worked for companies who have embraced the above in buckets and don’t stand still in the space, instead are always adapting and overcoming challenges to get on the front foot.

An agile work environment

As an example, I head up the global test team for Nephila, whilst actively being a delivery member coding daily integration/GUI tests and forming strategic decisions for the team. Being a multi‑billion dollar hedge fund, Nephila lives in the financial world. Financial companies are notoriously a different beast of company with more regulations and red tape than a supermarket opening when trying to move progressively with the times. Nothing however could be further from the truth within Nephila and that’s why it’s such an exciting and cutting edge place to work
within the agile, technology and financial space.

Within Nephila we work as described in the fundamental principles section: we’re nimble, we’re not scared to change direction, we don’t fear to fail on features, instead we go again and become even stronger in our delivery. This is due to not being bound by 900-page functional specifications that are out of date before they’re even finished, giving us as testers no chance to be able to sign off on a product. Thankfully everyone understands the power of being agile and delivering true value to the business frequently and it makes for a really fantastic work environment.

This model ensures we have the capabilities of using features which are wanted by the business, relevant and ahead of the curve when dealing with pricing multi‑billion dollar deals across the funds for investors.

Final thoughts

In my opinion the main reason why agile testing and delivery fails within a company comes down to one keyword: communication.

I work with a lot of very highly regarded technologists, from Microsoft MVP’s, Scala Masters to AKKA Masters – these titles show that technically we have a gifted set of developers across our technology stack. However, to work in a highly effective team is only possible due to the excellent communication skills of those team members and the business users. Without those communication skills I truly believe you can employ people who are very deep in a skillset area but will ultimately fail due the lack of soft skills.

If you have managed to get this far with the article firstly I’d like to thank you. Secondly, I ask that next time you’re testing a release candidate with one or many features where you don’t quite understand parts of that feature which you really should to allow you to test rapidly then consider what you would change to not be in that situation again, as time is precious when agile testing!

Not one answer fits all to the above but if you keep asking that question of what would you change in the process to best fit your environment, then generally it comes back to better relationships and communication within the test team and wider delivery team.

I hope this article has triggered some thoughts in your working practices, questioning how to keep pushing forward and ensure faster, tighter test cycles within an agile delivery model. Please don’t hesitate to reach out to me with any questions via LinkedIn.

This article was first published in the July 2016 issue of TEST Magazine. Edited for web by Cecilia Rehn.