You are here

5 takeaways from the TestBash New York conference

public://pictures/Matthew-Heusser-Managing-Consultant-Excelon-Development.jpg
Matthew Heusser, Managing Consultant, Excelon Development

TestBash New York, the U.K.-based Ministry of Testing's software testing workshop and conference for software testing professionals, was held last week at New York City's Gramercy Theatre. Whether you didn't have time to attend or just couldn't get to all of the events, TechBeacon has you covered. Here are five takeaways that software quality professionals won't want to miss.

[ Get up to speed on quality-driven development with TechBeacon's new guide. Plus: Download the World Quality Report 2019-20 for lessons from leading organizations. ]

1. To develop stable systems, think resilience, not safety

Instead of talking about tools or patterns in their "Continuous integration and test automation at scale" workshop, automation engineer Noah Sussman and Bitly lead quality engineer Jessica Ingrassellino questioned the basic premise of most testing, which is to prevent problems. Safety in that world is seen as an absence of problems. Instead of safety, they propose thinking about resilience—accommodating change and absorbing disruptions without catastrophic failure. You can use test tooling to enable stable systems by reporting problems, Sussman says.

Instead of talking about Selenium, Jenkins, or other traditional test tools, Sussman says, you should add code to save metrics out to a reporting server. In this way, when your production and test code is executing, it can report response times, 400 errors, test results, and so on to another database you can use for visuals. Both Sussman and Ingrasselino recommend using statsd, a client library available in many programming languages that reports results back to the Graphite, database and graphing tool. Graphite displays the data round-robin, like a stock ticker, showing you a window with the type of data you select. Graphite is open source and works on user datagram protocol (UDP), which means the software adds almost no overhead and will stop reporting if the network becomes saturated.

[ Get up to speed with TechBeacon's Guide to Software Test Automation. Plus: Get the Buyer’s Guide for Selecting Software Test Automation Tools ]

2. Put testers in the product owner's role

There are two methods of collaboration, say agile coach Llewellyn Falco and software testing specialist Maaret Pyhäjärvi. Co-creation is where the programmer contributes software that is only three-quarters baked, the tester contributes problems, and you have an expensive find/fix/retest loop. But with full collaboration, everyone works together as a team. They create a shared understanding, prevent problems, and learn from one another. That's a more helpful way to think about the work, Llewellyn says. In addition, with wider responsibilities, product managers tend to be visionary but often lack critical details. At the opposite end of the spectrum, testers tend to be very good with details, figuring out what the software should do. That gives testers a sort of product owner role, but that usually happens only after the fact, after the software failed to work the first time. Make that junior product manager role official, Falco and Pyhäjärvi say.

3. Coach your programmers on how to test

Sigurdur "Sigge" Birgisson works at Atlassian, an organization that has hundreds of developers but no testers. The company, does, however, have a QA role, which is called "quality assistance." The company has automated tooling. Humans do testing, but the programmers do the work. QA professionals at Atlassian coach developers on test planning, reviewing test plans, and related activities. This includes feature kickoffs, where a feature is explored in depth, along with user interface reviews. During those reviews, the technical staff mocks up the graphics and the flows on a wall, then discusses what happens at every step. As a coach, Sigge leads an exercise to discuss what could happen, what should happen, and what might go wrong. The company also has a quality standard, its Atlassian Quality Guidelines (AQG) checklist, which it uses to make sure the team has thought about a series of possible problems.

4. Automating the wrong thing is an illusion

Tanya Kravtsov, head of automation and continuous delivery at Rokitt, spoke about test tooling, starting with the pipeline from idea to in-production. She says that any pipeline has a bottleneck, and automating anything that is not the bottleneck creates an illusion.
For example, say that a team automates all of its user interface tests, and can check the core flows in ten minutes instead of wasting a whole day. The problem is that in order to test a build, the team needs to rebuild the test environment. That means it must wipe and repopulate the database, which can only happen over a weekend, at best. Kravtsov's solution? Instead of automating one part of the build/deploy pipeline, automate all of it, so it is possible to deploy any individual commits. This can be an overly ambitious goal, so find the bottleneck and start there. That will be the area with the biggest opportunity for improvement. (And it might not be the execute/evaluate part of the test process.)

5. Can't make a conference? Visit a local meetup

Although he was a presenter at TestBash New York, software testing professional Nimesh Patel admits that attending conferences requires an expenditure of time and money that many testing professionals simply cannot afford. But Nimesh, who organizes and is a co-founder of Montreal Insights In Software Testing, a peer conference in Montreal, Quebec, says that if you can't travel to a conference, make time to attend a local meetup or conference event. These events are usually free to attend, happen outside of work hours, and provide opportunities for sharpening your skills and networking.

[ Learn how to apply DevOps principles to succeed with your SAP modernization in TechBeacon's new guide. Plus: Get the SAP HANA migration white paper. ]

Article Tags