KWST has become part of the mainstay of the testing world Down Under. And just like the previous years the two days spent focussing on all things testing was a blast! Many attendees said it was the best yet.
This year’s content owner was James Bach with “Defining and Defending the Role of Testing”. For the Wellington and NZ market this topic is bang on the money. We have a lot of change in the market and discussing the role of testing is key to our success.
Attending this year were James Bach, Oliver Erlewein, Richard Robinson, Aaron Hodder, Sarah Burgess, Andy Harwood, Adam Howard, Mark Boyt, Chris Priest, Mike Talks, Joshua Raine, Scott Griffiths, John Lockhart, Sean Cresswell, Rachel Carson, Till Neunast, James Hailstone, David Robinson and Katrina Clokie.
Adam Howard with “ Negotiating the role ”
Adam Howard started his career as a tester for a position where testing was very much defined as “validating requirements”. Large documents filled with requirements would be passed to testers, who would write large numbers of test cases – if the test cases passed, the product was ready.
From interactions with other testers, Adam began to suspect there was more to testing than that. He became aware that in truth he was “really testing” when he was playing with the software to write his detailed test cases. This was where he was finding out what the software did and didn’t do and led him to learn more about the actual role of testing. What he was doing was exploratory testing.
He pitched to the customer that he could find more problems quicker, with more value using exploratory testing. The customer was initially skeptical, but agreed on a trial, increasingly feeling comfortable with the new direction and redefining the role testing played in the organisation.
Joshua Raine with “ Working where there are no defined roles ”
Josh talked about one of the first projects he’d ever worked on as a tester. There was no induction or definition of the role, and development was equally at sea. The only thing there was were contractual obligations in the form of
scripts.
By necessity he approached his role in an exploratory way, defining it by what needed to be done / what could be done in the context.
The problem occured on his second project, where there was an expectation for something very different. The motto was, “where are your test scripts”. He found it hard going from one project where everything was up for grabs to
one where there was a high level of formal expectation.
This led to a large discussion about these two extremes, (a) where testing is not defined at all or (b) where it is tightly defined (not necessarily by someone involved in the role of testing). James offered this advice for all testers finding themselves in this place. Asking these questions would make you understand your role.
- What problems are you expected to solve?
- What competencies are you expect to develop?
- What problems are you expected to anticipate?
- What meetings are you expected to attend?
Sarah Burgess with “ Foray into Being a Developer ”
Sarah works at TradeMe (similar to eBay in the US), where there are a lot of squad teams within the different applications. One sprint they comically suggested the team should trade roles something the product owner thought was worth a try.
It should be stated, that although their product was not part of the customer front end, it is strategically important. It manages the deployments of 30 products across hundreds of servers.
So she became a developer for the sprint. This wasn’t just “throwing anyone” into a developer role. She did have the backing of her computer science degree. But even so, she really got out of her comfort zone and experienced “the other side”.
It turned out quite well, and everyone gained an appreciation of what other team members do for the project. It also meant with leave and sickness, they were able to cover for each other much better. Particularly as the developers were starting to appreciate the challenge of doing deep testing, it improved their coding skills as they became more mindful of the issues they experienced.
To Sarah it didn’t mean “we don’t need testers now”. Her take was “my role is testing. But I can step out of it if needed.” Most of all, it helped the team build empathy, better communication and appreciation for what other disciplines and roles were delivering. The practice has been upheld since then and is working for the team.
Katrina Clokie with “Turn our team in to testers”
Katrina continued some of the themes from Sarah’s Experience Report, looking into the definition of roles in an agile team.
Although Katrina had experience of a number of agile teams around Wellington, there was a government team which stood out. She was brought in as a testing coach they had a number of very siloed roles, where the people were subject matter experts, but the team had no role for a tester.
The team knew testing was important, and it was brought up in retrospectives but no one really championed it. There would be a great benefit from someone who could look at the daily tasks and go “that might cause a problem for our testing”. People were building fences though and defined what they were responsible for, and testing fell in no man’s land.
Oliver Erlewein talked about how such teams require agility not just from the processes they follow, but from the team members involved. People have to be prepared to grow/expand into the gaps their team presents. Agile will fail if those tasks don’t get done. There was lively debate here around whether the growing into nonrole tasks was permanent or not and how it would play out long term in Agile projects.
Chris Priest with “ Exploring legacy software; roles in a test-first project”
Chris wrapped up our experience reports with his talk about a project that was failing and under fire. The project team as a whole was toxic, with a lot of political infighting. There had been a lot of problems, but testing was where the failures were most visible. It therefore came under increased scrutiny, attack and micromanagement common statements were that “ testers don’t understand the requirements ”, or “ testers are trying to test in too much
detail ”. This was made that much harder by testers not being allowed direct access to business analysts or the COTS development team everything had to go through several layers of management.
Chris felt he was being forced into a role of constant defense, not just him, but his whole team. He tried to protect his test team from this infighting so they could just get on with testing. He tried tightly defining the team’s tasks and roles so they could actually function. In many ways the testers role was being defined by the level of challenge they were put under.
Many in the audience responded positively to this story James Hailstone stated such projects are a testing form of the “ Kobiyashi Maru”; a no-win scenario, which exist only as a test of character and resolve.
James Bach said that he tends to walk away from such toxic projects. Chris had felt the temptation to do that several times, but felt it would make things worse for those in his team left behind.
In the end, Chris got access to the COTS development team. It turned out there was a fundamental problem with the products, which was just not designed to work in the manner analysis required. In hindsight, Chris feels he is now more proactive, and less reactive to the role of testers to prevent being cornered like that again.
Close-Out
KWST was two days of testing fun and learning. It was interesting where the discussions went. Personally my biggest takeaway was around the roles in agile and how they change. Highlighting the elasticity in IT roles from sprint to sprint. The Experience Reports were all awesome, and the stories really got the room buzzing. As always, all attendees were brimming with action and the moderation cards were flying.
A big thank you to the Association for Software Testing, BNZ and PartsTrader for making this event possible by sponsoring it!
The AST Grant Program is here to help you energize your local testing community.
Recent Comments