TestBash Retrospective #4 - Automation: Time to Change Our Models

Automation: Time to Change Our Models

Mr Iain McCowatt took a relaxed but jaunty stance and delivered the first words about his talk on automation: "This talk isn't about automation".

And therein lay the point. He continued: "It's about people". This was a talk about replacing testing as a goal with the purpose of testing in the context of our tools. Seeking out what to automate replaces the question of why automation in the first place, and how?

A great little heuristic I latched onto was changing perspective from automation as a replacement for the test process to using tools as an instrument (as a scientist would use a thermometer. The example used was the invention of the barometer in solving a liquid dynamics problem.). But it doesn't stop there! How you view your tools also provides a filter for your choice of tools - and your choice of tools will change your behaviour and how the testing problem is perceived. Getting this wrong at the outset corsets the possibilities and the value that testing can provide.

There was also talk of our mental constraints which can poison people from solving problems. The example used was testers asking for access to the production environment. Why? Because they needed to do something there that they couldn't do in the test environment. Why? Because they can no longer do testing in the test environment. Why? Because there's no more disk space in the test environment. So the belief that they couldn't ask for more disk space lead to a bad solution to a fairly simple problem. The use of WHY as a powerful questioning tool against imposed constraints I think was a glaringly obvious and often overlooked and forgotten point. Another example given was goal displacement - the instruction from on high to automate tests because of a recent goal-setting meeting rather than it being a solution to a problem.

Considering our test tools as instruments lets us look at how tools can be used to help specific tasks - implement tools to solve problems (whilst understanding their limitations and flaws) rather than find tools to replace existing tasks for the sake of automating them.

This was a talk that is better than I can describe in a blog post. It really illuminated the power in a shift in perspective on tools rather than mitigating individual risks by patching them with automation tools.

TestBash Retrospective #3 - Inspiring Testers

Inspiring Testers - Stephen Blower

This was an amazing talk. An interesting story of a journey from factory to context-driven. A story of empowerment (a common theme at this TestBash, it seems) and by the end there were plenty of inspired questions being asked. The story rotated around being bored and uninspired at work - something I'm very familiar with from past jobs where scripting was the order of the day and I didn't know enough to challenge it - and moving from place to place until inspired by Michael Bolton's work. We've all been there! For me it was a lecture on YouTube by James Bach. 

Some of the points raised included:

Have Integrity - Stand by your principles, be prepared to defend your actions, be open, honest and truthful

Pragmatism - Be prepared to negotiate a solution. Be pragmatic and understanding.

Use Facts - Not assumptions

Use Paired Testing - Dev/Tester and Tester/Tester. Swap who drives and allow people to learn.

Don't Say Pass/Fail - Use problem known/no problem known

There were more, but I won't go into too much detail. I loved a little tip that was mentioned for dealing with infuriatingly named "Pass" button in JIRA - that it means to "pass it along". Some people audibly smiled.

The thing that really hit me hard, mainly because it's so blindingly obvious whilst being a vital reminder for me, is to stop complaining and take action. Provide solutions. Get up and do a good job, rather than sit around complaining about it. I need to do this more - I do tend to whine when I should be doing something about the problem, and that is born, basically, from fear. As a few people said at TestBash (I think including Mr Blower himself) "I don't need anyone's permission to do a good job".

How's this working for y'all? It's pretty rough first-draft reporting but it's actually satisfying (instead of my usual state of unease) when I hit "publish".

TestBash Retrospective #2 - Don't Be Vague, Respect the Bug Report

Anna's 99 Second Talk

Anna Baik [@TesterAB] (no less) gave a talk on being less vague. The cornerstone of the talk was to be more specific in our language so that we're respected within and outside testing - in our company and beyond. To talk about skills instead of just naming processes. To use words like modelling and exploring in place of test cases and scripts. Be specific and proud of what you do, and talk about it in a professional way, for the benefit of you and the software industry.

I was the last 99s talk, about tester skills - so if you're interested in learning & helping others (inc devs) learn - talk to me! #testbash

— Anna Baik (@TesterAB) March 31, 2014

Amy's 99 Second Talk

Amy Phillips [@ItJustBroke] (no less) gave a talk called "Respect The Bug Report", with a personal admission of a lapse in bug report quality. A brave thing to do, and it gives me the confidence to admit that I have been known to lapse in my communication. The thrust of this talk was to remember to respect your communication channels - to provide your test clients with good quality information, which is after all half the purpose of a tester. I've done some work on this at my own company and I found that talking to developers (I know! Crazy!) asking for feedback is a great way to identify the information they want from their report, and what information they actually use that you provide. You can streamline your communications by understanding the needs of your audience. Don't forget that testing and then keeping the information to yourself is a waste of time - testing isn't an end in itself, but a means to an end.

It strikes me at this point that all the people I've begun with are women. Hey, non-testers, if you're wondering where all the female talent is in the tech industry, I think we stole them all. Sorry*.

*not sorry.

TestBash Retrospective #1 - Tester Exchange Program

Well.

TestBash.

If you weren't there it's hard to describe. It's a set of fantastic talks by great people with a superb community. Okay, not that hard. I have a lot to say, I don't have a lot of time, and as I've said to so many people in the community before - I write far more than I publish. So this will seem less polished but will actually be readable by someone who isn't me! In non-chronological order:

Sarah's 99-Second Talk

99-second talks at TestBash can be done by anyone. The prerequisite to get on the roster is, I believe, to say "I want to do a 99 second talk" and then do it. There have been poems, lists (there was a hilarious one this time), there have been silent performances and, occasionally, talks. These might be a rant or a request or a suggestion or a plea or.. well, anything related to testing. Sometimes not even that. There's no going over 99 seconds, though.

Sarah Glanville [@GirlsTest2] talked about an idea which I suppose I'll describe as a tester exchange program. The core of the talk was a request to get in contact with her to talk about getting test teams to visit her company (SkyBet) to share notes, compare challenges, and so on.

I talked to her for a while about this, and I think this is a game changing idea. It's applicable across nearly any company, This has so many benefits - understanding of one's own context, examination of one's own constraints and processes, examination of how testers work in different methodologies and industries. There's so much to learn and apply! The difference between this and, for example, a meetup is the difference between testing a product by interacting with it and looking at the documentation. There's lots of tacit information to be gained, and it provides an examination of things like company culture and an understanding of the ACTUAL implementation of methodologies and approaches and the problems that have been overcome. You know how you feel motivated to improve after a meetup or conference? Why not get together with another company and learn for free?

To me it's one of those ideas that one looks at and is marvelled by a combination of its power, simplicity, and the fact that nobody's really thought to do it before. So get together!

More information here: [Sarah's STC Post]. If you're near enough to Leeds why not send her a message and talk it over?