Australian Testing Days – Day 2

After a cracking first day of the event, its workshop time at ATD2K16! I had enrolled for the “Ruby For Testers” workshop by Scott Miles. Scott is an organising committee member of TEAM and has been conducting short workshops for us at the TEAM Meetups.

The workshop was sold out and we had a great day of learning with lots of discussions, troubleshooting and setting up a Ruby framework for testing. The schedule was always a problem with the setups and explanations involved, as well as the varying knowledge skills among attendees. For my part, I had never used Ruby earlier and it was good to get an overview of the power of Ruby in Test Automation. Selenium combined with Ruby and Capybara could be quite handy tools to learn.

Note taking as such was a minimum on the day, however I managed to scribble up a mind-map for some of the things we covered at the workshop. May not be very useful as this was primarily my note taking method and you may not get the full idea without sitting in the workshop. Nevertheless, I don’t mind sharing 🙂

Ruby for Testers

Three other workshops were happening at the same time:

  1. Coaching Testers by Anne-Marie Charret
  2. Exploratory Testing by Paul Seaman, Lee Hawkins and Rajesh Mathur
  3. Security Testing by Santhosh Tuppad

The bad thing about conferences of this kind is that you have to make trade-offs for which sessions and workshops to attend 😦 I would have preferred to attend all of them! 😛

And thus, 2 days of awesome learning is over. What a great 2 days it has been..

The blog post cannot be ended without a special thank you to the TEAM Organising Committee. Here they are, the TEAM team 🙂 You guys have been terrific. Bravo!

From left to right: Paul Seaman, Rajesh Mathur, Paul Crimmins, Lee Hawkins and Scott Miles.


Not to forget the active participation from the attendees, Michael Bolton and Anne-Marie available with their wisdom to share. A great learning experience. Looking forward to the next one already!

Australian Testing Days – Day 1

What a day we had at the #ATD2K16, the inaugural Australian Testing Days Conference! A day filled with lot of learning, community and connecting with fellow testers.
The day started with the Keynote from Michael Bolton on “The Rapid Software Testing Guide to What You Meant to Say”. Michael had delivered this talk earlier at TestBash 2015 and I had seen the videos, but watching it first hand is an experience in itself. There was lot of fun and wisdom in his presentation and it stressed on the importance of communication, Testing vs Checking, Testers getting out of the QA business and so on.
Next up, was the talk from Michelle Cross on “Transformation of a QA Department”. Hard to believe that it was Michelle’s first conference talk, as she presented it in her usual effortless ease 😃. The talk was about her attempt to integrate context driven testing to her team, the learnings and the challenges of a cross cultural team. Great insight and research and she has really done a wonderful job, we could see that from the team snaps she shared in the presentation.
Catherine Karena gave a fantastic account of raising a tester through the WorkForce program. It was inspiring to see the effort that has gone into this venture and the way the trainings are done. Absolutely brilliant. Catherine was also a first time conference speaker, via the Speak Easy program.
Two other talks were happening at the other room during this point, with Oliver Erlewein and Hamish Tadeschi giving talks on “Reaching Beyond Performance in an Agile World” and “Testing your Driven Development” respectively. I missed these talks, I  hope TEAM will be having the slides or videos up at some point 😃
During lunch, I got a chance to meet some of the Twitterati – it was great to have faces to Twitter handles. Met with Richard Robinson (we were classmates at BBST Foundations a good 4 years back!), Katrina Clokie, Erik Peterson, James Aspinall, Deepak Puri… that’s a long list 😃
And then came the moment with Michael Bolton where we tried the Diffuse Bomb game. Whoa! I liked the game and the challenge. Although we managed to blow the bomb on the first two attempts, we successfully defused it the third time. High Fives! 😃 The game is just for 3-5 minutes, but there is great learning involved in those minutes. Probably in another blog post! Thanks Michael for your time and patience!
We moved on to the next talk – “The School of Rock – CDT Uncut” where Brian Osman made all of us laugh with his rocking presentation. Lot of energy and passion on that one. The talk gave his journey from an artefact based tester to the CDT rock star, creating communities and cultivating a passion for better testing. You truly rock, Brian, such fun and you have got some moves 😀
Katrina Clokie delivered her talk on “Testing Web Services and Micro Services” and the challenges she faced in them. Despite battling a sour throat, she gave a good account on her learnings and pathways on testing web services. The talk had a good response from the crowd with lots of questions being asked.
Two fantastic talks were happening at the other room during this time, with Aaron Hodder delivering “Software Cartography (or how to build multidimensional information radiators)” and James Kitney on “How to Build a Guild”. From the Twitter reaction, I could see that Aaron’s talk had a lot of inspiring stuff. Would love to attend that talk some time!
We had 6 lightning talks:
  • Jason Lee on Mobile Exploratory Testing
  • Erik Peterson on 3 Hash tags and 2 zones
  • Lauren Allen on Collaborative Leadership – A Tale of 2 Heads
  • James Irving on his Journey as  a Tester
  • Ayta on Pair Testing with Developers
  • Santosh Tuppad on Learning is a f***ing drug
Obviously, Santosh Tuppad delivers his talks in the calmest high octane way 😀  I love listening to this guy, it is hard to find a person who has such clarity on his thoughts. And his passion for learning is unparalleled in my opinion. His moto seems to be “Get bored, learn something new” 🙂  I’m proud of you Bro, you are doing awesome for the community 😃
Then we had the closing Keynote by Anne-Marie Charret “A Test Management Retrospective”. Charret talked about Test Management. Test Leadership, and Coaching. A lot of it had been a retrospective of what she had done at Tyro and being obsessed with delivering the best testing service. And the most important part is “It is true that there is a lot of struggle in building a great product. But when we struggle, we Learn”. We need to keep learning and we need Test Leadership for that. I’m glad we have lot of people to look up to in the CDT community!
Thus ends a great day of learning. There is a whole lot of Twitter Activity with #ATD2K16 which you can follow. Lot more images from myself and from many other attendees.
Thanks to TEAM for this awesome conference, looking forward to the next one!
Tomorrow, the work shops! I’ll be in the “Ruby for Testers” by Scott Miles. Hoping to be a great day of learning, just as today!

Australian Testing Days 2016 is here!

The inaugural Australian Testing Days (ATD2K16) is happening in Melbourne on the 20th and 21st of May 2016.

I’ve been part of the TEAM (Test Engineering Alliance Melbourne) Meetup group since its inception, and even though I was in India at that time, it was great to see the passion and the way monthly meetups are organised. I’ve been to 3 meetups since I came over to Australia and it is a privilege to be part of such a passionate bunch of testers. TEAM has come a long way and ATD2K16 is a proof for that.

This is going to be my second conference after Test-ED 2012, where I got the chance to meet James Bach and attend the RST course. And this time I will be meeting Michael Bolton and Anne-Marie Charret, two great teachers who have been the inspiration for many in Context Driven community along with James Bach.

There are some standout conference talks and lightning talks and I’m sure it is going to be a great experience. I’m looking forward to the talks from Michelle Cross (from what I know from the TEAM Meetups, I’m pretty sure that Michelle will make you smile no matter what!), Aaron Hodder, Katrina Clokie and Brian Osman to name a few. The choices are abundant and I’m having so much confusion on which ones to attend 😦

Then the workshops that are happening next day (21st May). I’ve enrolled for the Ruby for Testers by Scott Miles and hoping to meet some automation experts while starting my baby steps on Automation. Scott’s CSS selector workshop at one of the TEAM Meetups was awesome and I’m looking forward to a great day of learning (don’t worry Scott, I hope you don’t mind the high expectations ;-))

I’ll be present and mostly tweeting/blogging at the conference along with a host of attendants. You can catch my tweets @nandagopalr and blog posts in this blog. I hope I’ll be able to provide a good tweet coverage as I have done for Test-ED 2012! If you are coming for conference, please don’t forget to say Hi! I would love to connect with you!

See you at the conference!


A bit of house keeping..

I’ve been away for a long long time! So long that I forgot about this blog and I need to start from scratch 😀

I thought of putting the list of my popular posts below so that it will be easier for anyone finding my blog to quickly go through them. So, here’s the list (in no particular order):

Hope that helps some one! And I hope you enjoy reading them. As always, feedback would be great.

Until next time, Happy Testing!

What we want from Devs?

Hello my dear Dev friends!

First of all, I would like to thank you for the code you gave us for Testing. Without your code, we wouldn’t have anything to test! I really appreciate the great effort you put in the research and investigation for each of the modules you develop. However, there are some things that I would like you to do “more”; which will make life easier for us, as a team. Here are my suggestions:

Read the Requirements and ask questions.

Pretty obvious, isn’t it? I know you are reading the requirements and I know you are asking technical questions about how to write the code according to the coding standards. But I’m not quite sure whether you are asking questions about how the “feature” you are developing is going to be used by the end user! Unless you don’t know how the feature is going to be used by the end user, your development is not complete. Please don’t say that it is the job of the testers to do that! Yes, we do that; but there is no harm in you doing it either. Now you might ask “Why should we do that?” Because, when you ask that question before you develop something, you are effectively minimizing/avoiding the rework that can happen for something that was developed is not fit for the user! What is the point of wasting your time and effort in writing code that is not fit for purpose? Your one question might save a lot of time and effort for the whole team!

Take responsibility for your code!

Hmm, that is also pretty obvious. It is hard to be 100% perfect, but there is no harm in trying. Try to set a benchmark for your code, set a challenge for yourself “I’m not going to allow any tester to find defects in my code”. Code like your life depends on it. We all are humans, and we make mistakes. Owning our mistakes and taking responsibility to fix it will only make life easier. You can be rest assured that you are not going to make that same mistake in your life again 🙂

Ask your Tester for help!

Alright, do you think we are your enemies? NOO! Understand that I’m trying to help you. You are developing the code, and we are trying to give you information about what didn’t go well with your code! That doesn’t mean that we are giving you more work in terms of fixing bugs and implementing new changes. Imagine what happens if the testers also miss an obvious defect in the code and the customer finds it! Yes, Testers get the blame first, because we didn’t find that bug. But, we didn’t code that bug in the application either! So who is suffering in the long run? We all are! Our Organization’s brand is at stake if we don’t do it properly. When we work together and find defects together, we are working on the same goal and we are working on making something that is good to be better! And don’t you know that when we interact well, the rapport increases and you can be rest assured that your tester pal is there to save your back even when you have made a mistake? Quality is everyone’s responsibility, right?

Read my bug reports to the full!

Yes, you read that right. Read the reports to the full. Because, like the code you develop is your output; the bug reports we write is our output. My personal opinion is that I consider myself a disgrace as a tester if you are not understanding my bug reports on the very first read. You have every right to shout at me if I’m writing poor reports. That being said, if you don’t read the reports to the full, you may not know whether it is written well or not. Just skimming through the bug report may not be enough for some complex issues. This is something similar to the first point we discussed. Not reading a bug report to the full and implementing a partial fix is only going to increase rework for the team!

Ask me questions!

Yes, we like to answer queries and explain scenarios (if you don’t find that boring ;)). There are chances that even a very well written bug report might be complex and you are not able to understand it. Come to us! We are all ears. Also, asking questions might help us realize that the bug reported is a big blunder or a duplicate. 😉

Communicate your changes!

Obviously, we all want to have the information on our finger tips. So, once you make a change and deploy those changes to the Test Environment, please send out an email or ping your tester buddies to stop testing. Otherwise, they won’t be aware of the change and it could result in unintended bug reports, confusion and a whole lot of mess. Yes, the same rework stuff we discussed earlier. Your tester buddies might be investigating some other issues or setting up the test data for an important scenario, and one change in the environment can sabotage all the plans. It is a good thing to keep your team informed about what you are working on and when you are making changes.

So, that’s it. If you could try to accommodate at least a couple of things mentioned above, that will make a difference! I am great fan of Dev-Test collaboration and the points mentioned are NOT intended to start a Dev Vs Tester war. I know that my Dev friends have similar points on “What we want from Testers?”; and I would be really interested to know them! Send in your feedback, comments, mails, tweets…. 🙂