My journey to the MiagiDo School



This was something that I always had at the back of my mind but some how just could not do it. This year one of the objectives I set myself was to get into the MiagiDo School.

Markus Gaertner had asked me to ping him in the beginning of Jan this year when I enquired about him being my mentor end of last year. Ping I did which was followed by an introduction to the MiagiDo School and the FAQ's. 

What I like the most about this school is every tester in it has to go thru a testing challenge, prove his worth and then he/she is granted a belt and access to the MiagiDo School forum. How simple and yet great is that. Isn't it one of the best peer review or recommendations one could make? This one thought of to be among such fantastic testers inspired me more.

It was now time to test myself. I expected me testing an application/program as the test challenge but the challenge surprised me. It was nothing that I expected it to be. In fact not even close to what I had in mind.

I was to watch a tech talk from a leading tech company and then develop my own approach to testing. I also had to consider the advice of the authors. And then defend my answer in terms of overall quality, test effort, total cost of ownership over time.

Markus answered all my questions/clarifications and it was now my time to deliver.

I had never watched a tech talk with an objective before. Should I watch the video in full or should I watch it in bits? What should I concentrate on? everything the presenter says? The audience questions? The application they test? The claims they make? Their test strategy?

I then decided to timebox my exploration to 15 min. I watched the video in sessions and note down anything that seems to be interesting, align with my objective. I ran 6 such sessions and now had enough notes about the application, authors test strategy, audience question pattern. I also now could do my exploration around the claims they make and how it stands.

All of this then helped me design my own test strategy and justify it for overall quality,
test effort, total cost of ownership over time - which went into my final report

This was followed by more questions by Markus and finally a Brown Belt. Markus then said "I was the first one to work through his original black-belt test on the google guys" and that put a huge smile on my face :) Thanks Markus for taking your time off to engage with me on the testing challenge.

Not a bad start to the new year? Is it. Now it's time to interact, learn and contribute  with these amazing folks in the MiagiDo school. So looking forward to it.

Comments

Anonymous said…
A very warm welcome to you!
March 7, 2013 at 7:02 AM
Phil said…
Congrats - and welcome !
March 7, 2013 at 9:13 AM
Post a Comment

Popular posts from this blog

Exploratory testing, Session based testing, Scripted testing…concertedly

In my last assignment a mix of exploratory, session based and scripted testing helped won an award, appreciation by managers & stake holders at our organization. The quotes from our award certificate “ QA team has come up with some intelligent testing techniques to validate the product. The customer test team was not able to find even a single critical bug after delivery ” Though the award was a small one in terms of the award categories our organization have, it meant a lot to me and the team, because this was the first time the team used exploratory approach. The assignment was not pure exploratory or session based, in fact it was supposed to be scripted, but a mix of all three exploratory, session based and scripted testing helped us learn, enjoy, and meet our mission. The assignment started off with developing test cases. We wrote test cases based on the initial requirement document provided. We did come up with a large number of test cases, of which most were re-written, some
Read more

What do you do when you find a bug?

What do you do when you find a bug? Hold on do not answer it right now. Let me first set the context. You are part of an agile team. The developers sit opposite to you. You are testing a feature in a session. You are time bound and have the good habit of capturing notes when you test. When you now find a bug what do you do? Assuming that you have taken enough notes you go on to write a good bug description and may capture a screen shot, video of the bug and continue with your session. At the end of the session do you Open the defect tracking tool (wait for it to load), enter all the fields for a bug, upload necessary evidence and have the tool share the defects with your dev team? Or Open the defect tracking tool (wait for it to load), enter all fields for a bug, upload necessary evidence and then compose an email to the dev team with the bug id’s/descriptions? Or Walk to the developer share your notes; reproduce it if required, work together to identify the problem? I work in
Read more

Regression Checks + Regression testing = Regression testing?!

One of the questions I find hard to answer when I use exploratory test techniques in my project is,”How do you run regression tests? How do you prioritise them? Do you automate them? Do you document regression test cases?” And then a bunch of questions follow. Let me define the context. I work closely with developers; we use either Scrum or Kanban - which ever best suits our project, product owner, business. We do not believe in individual metrics, blame games, stringent processes, and heavy documentation. All we care about is to deliver high quality software. This does not mean that there is no process, metrics or documentation. We have them all, but they are there to meet our needs and to help those who will come onboard to support/maintain the software. Regression Checks At the start of a story, testers pair up with developers to develop feature files using SpecFlow. Some call it Acceptance Test Driven Development and others Behaviour Driven Development [I am yet to figure out the d
Read more