Back from lunch!
How to turn a 403 into a 202 at the API party – Gwen diagram & Ash Winter
So we just got a parental advisory warning for this talk… ok sets it up nicely!
It’s started off with a lesson in REST APIs and http request/response… good baseline stuff.
It’s great to get involved as early as possible. If design meetings are happening, and you’re not invited, turn up anyway! And when you turn up, contribute! All interfaces are important, API, logs et… so treat them as first class citizens. I really like this and not really thought of it that way before.
Deisigning then documenting the API interface is so very important and this is something I have battled with for years. Without a clear contract for the interface, it’s too easy for a dev to change a property or type of the end point which deviates from the original design, without appreciating the world of hurt this will cause! This usually happens without anyone knowing until everything breaks!
Building customer happiness with a tiny team – Paul Campbell
This is a story about how Paul built Tito, a ticketing payment system, used by many events including ministry of testing. Great user experience is more importance than a great product…. but a great product is a part of a great experience. Very much try and I totally believe in this. Doing so is about optimising the whole company for providing a great experience.
The talk veers into the story of how the company has grown and survived to where it is now which is interesting, but I feel not yet that relevant to this conference. There are slight undertones of quality at the team level, but nothing explicit. He does talk about their philosophy for dealing with customers and I can really relate to this. Treat them how you would want to be treated. Imagine you are on the receiving end and that can change your approach. It’s not rocket science but often forgotten.
Lots of slides with various tools they use which is sorta interesting but nothing I can learn from.
Break, coffee and reflection…
One of the great things about Testbash is being unexpectedly reunited with people I greatly admire and respect… this afternoon I bumped into Alessandra Moreira @testchick, who I have not seen for a couple of years!
Also just picked up a pack of Testsphere cards… another activity to do with our test group at Cambridge Consultants:-)
So far this afternoon hasn’t been as interesting for me personally as this morning…
I don’t go to many conferences, but I’m starting to find that there are not very many ‘aha’ moment any more, but I do find that I get reminded of stuff, almost using the talks as guideword heuristics to jog memory or provide avenues to rediscover.
What I learned about testing software by becoming a developer then a CEO – David Christiansen
Or renamed as “Testing reflections from a testing has-been”!
David has been a CEO, then helped many entrepreneurs start companies then he joined one of them, and he still doesn’t know what Quality Assurance means! That’s nothing to be ashamed of in my opinion.
Love the back story about his daughter being a dork! Then “A QA engineer walks into a bar…” lol
Definition of dork – “Smart, quirky, endearing people who are immersed so deeply in their craft that it’s hard for outsiders to appreciate.”
HICCUPPS is the one of the most important things he learnt as a tester, and I can attest to this. The mnemonic is great for providing a framework to base an issue, argument on.
Testing your own code is hard, it’s a bit like working out if a pair of pants makes your butt look big… “im very familiar with my butt, I just can’t see it!”… love the analogy. He talks about the many times you pick up a new code drop, and it crashes the first time you run it up. It doesn’t mean it wasn’t tested, but a developer is writing tests with the same head that wrote the code so can miss the simple stuff. However, it doesn’t make it any less infuriating, and in my opinion, dev said should run their own stuff first!
Testing software is a boldly empathetic activity… putting yourself into the mindset of a user. This is something I used to very strongly believe in as the primary role of the tester.. but now I’m not so sure. Yes, having knowledge of users and how they will use the product is important, but can we really empathise to the extent that makes us a true user without actually being a real user ourselves. They have different pressures, different environments etc.
Coach, explorer and toolsmith walk into… – Richard Bradshaw
Coaching is about asking questions to find out about someone’s approach, why they are doing something, how they feel about it. I’ve used the WWWWH approach (who, what, where, why, when, how) and find this very useful for developing questions.
When coaching, it’s very easy to just fire advice back at the person, but this is not helpful, and providing feedback is a two way activity.
It is also very important to listen. Not just hearing, but listening. Listening to everything, and observing how teams work, how the testers work. This will give very useful insights into why they have certain behaviours.
Now on toolsmith, Richard explains that this is not just the Automator… it’s someone who can create tools to support testing.
I think I am pretty much a toolsmith, and I need to think more about this, especially as Richard talks about such people not really taking about their coding skills, they talk about their test automation skills. This is very true.
There is nothing wrong with quick and dirty tools for solving problems. I think I would caveat this with quick and dirty is fine, but consider coding it properly to make further development easier.
Lastly, the explorer … as testers we should be explorers. We don’t just test software, we explore it!
This is something I very much adhere to, and something I am encouraging at work. Exploring is vastly more exciting and interesting that just simply following instructions. It asks many more questions, it encourages observation.
Regression testing is fine, and automation is ok, but also use chartered explorations on a new build.
Richard talks about job titles and how he changed his title to just ‘Tester’ from software tester referring to the Martin Hynie talk about how job titles affected what he and his testers were able to do on projects.
Very interesting talk, with good content and a great way to end my Testbash as I need to leave before the 99 sec talks unfortunately.
Thanks Rosie and the gang, and see you next year!