Sunday, 16 July 2017

Hiring problems emerging from not knowing what a testers responsibilities are.

  • Does it matter to you as a hiring manager to know and share what a tester’s responsibilities are?
  • Does this knowing shape what a tester does in the role of a tester?
  • Does this knowing shape the future of testers and testing?
  • What gets communicated as a tester’s responsibilities does affect what a newbie /clueless tester does at his / her first job. It takes a rebel and an educated tester to question the norms. My education on software testing was that of the traditional sorts — write test cases by looking into the FRS, send it for review, rework on the review comments, execute the tests and log bugs against it. When I did something out of the recorded tests — one of these 3 happened: ‘In awe!’, ‘Why did you do this?’ or ‘Who detected this?’. 1. In awe because a new tester swayed away from test cases (It was unheard off for some that a newbie cannot follow the rules set). 2. Why did you do this was because it is not recorded as one of the test cases (and is not reviewed) and who will now explain the involved that we have a new test :). 3. Who detected this because the bug was disguised as a feature and remained undetected for a while, when test cases were followed as is.
  • How often do we witness and / or encourage a tester who questions the norms, professionally?
  • How often are the testers educated in software testing, prior to joining an organization as a tester? Is the syllabus for software testing formed with the consensus from any of the active software testing practitioners?
  • Are we equipped to encourage newness / questions that come our way when we make a hiring (accept / reject) decision? How often do you sum up your energy to ask for the reject reason? In the biased world, it is safe to sometimes not ask for the rejection reason. But when we do ask, know that they may or may not reveal the real reason.
  • Does it matter to you to know that you hired right? May be you did hire right, but the system and the processes followed in the organization remain unquestioned and you get a feeling that 'You don't fit in' or someone you hired doesn't fit in. 

An attempt to share a tester's responsibilities (actual versus the expected) is made here. 

A lot of this learning comes from the notes, articles, books I have read, being present at the test-opsy session conducted at StarEAST[2016] by James and Jon Bach and Michael Bolton. And by witnessing tasks I carried out in the role of a tester. In itself, this work is incomplete and there is scope for improvement as I see that contributing to building testing community, one own's credibility is also part of a tester's responsibility. 

Some of the questions that helped me frame the map are below:

  • What does a tester do? 
  • How do I define a tester?
  • What kind of responsibilities suit this tester versus that tester? (Automation / CodeJunkie / Script Kiddie / ET)
  • What else does a tester do? 
  • What matters? What doesn't matter?
  • How can I help? Who can I seek help from? 
  • Does this process versus that matter? What matters to the organization may not matter to a commoner / a user. 
  • How to communicate the good and the bad news about the product's quality? 
  • Is the information shared useful? useful to the relevant?

(Click on each of these images below, to view their enlarged version).

A typical CV would contain keywords such as the above for an automation test engineer and a traditional test engineer. But is that all, what a tester does and defines with everyday learning? 
A tester does more than document tests, prepare the tool to perform the tests and as part of performing testing, a tester also needs to learn, perform, be and become a tester eventually. See below for some of the other skills a tester needs to be educated in and be equipped with.

Process is for the program / project to run smoothly. Do not discard a tester / CV / resume because it lacks domain / process knowledge / information in it. How we design, program, test, build should reflect in the quality of the product that a user operates.

What matters to the business and the user is important. But what matters to a tester is equally important. If you are learning, you are growing.

Does this know-how help you to shape better questions to ask when you meet a tester to hire him/her? 
Does this make you rethink how / whom to hire? Am I asking the right and relevant questions to a tester who's being interviewed?

Add your comments below, how would you define a tester's responsibility differently when you share what a tester's responsibilities are. 

Do this exercise with your testers (already hired). 

Exercise - What tasks a tester is bound to do when they explore the requirements or perform a product walk-through? And take notes.

If there are no questions at the end of this exercise, then the client is not going to be happy with the testers hired. Hire better. Design the tests to test the tester better. Learn a way to solve hiring problems. 

End of it - Share your honest feedback of the candidate interviewed, and it's important to do it.

Sunday, 25 June 2017

Risk Versus Experiment

Risk versus experiment - A change in mindset for self learners attempting to learn by experimenting.

The tweet above about risk and experimenting didn't convey all that I meant to and in less than 140 characters it is hard to put into a single tweet the content and the context at times. Hence an attempt to share this short post on how re-thinking risk as an experiment can help us in self learning and not abruptly end our learning via experimenting because it is categorized as hard or as risky. 

Every experiment may or may not be composed of risks. 
I'd like to address via this tweet that some think few tasks as risky and wouldn't even attempt to figure out the solution by themselves. They would rather wait for someone else to conduct this experiment or take this risk on behalf of them to learn from it, which is fair too. But at the same time, if we are relaxed with whatever may be the outcome of the experiment conducted in the controlled environment, then we would continue to learn, focus on learning by experimenting and the results obtained rather than overly focus on the risk attached to the task.

Note that the experiments that I am talking here are not life threatening experiments, but those that are aimed to aid us learn. And can help us learn better when we are fine with what the outcome is__ success or failure. We learn from both these outcome on what to attempt next and what not to. Let us give ourselves the liberty to accept learning from failure/s as well as from success/es.

The context in which I shared this tweet (and in the way it was perceived and interpreted by Twitter friends), proves yet again how important it is to state the context. And to help the reader understand the context in a tweet sometimes isn't possible. Thus I made few more attempts by replying to the tweet to expand on the context. 
The tweet is aimed at an audience who would not try out (for themselves) tests, experiments when learning but rely on ready made answers or would stop looking for answers because it isn't easy to proceed further along this journey of self discovering answers / solutions. The target audience of this tweet would be those who are focused on learning and those who attempt to learn by experimenting. 

Point to ponder - Try replacing risk with experiment, as an experiment for a test that you are performing and check if there is a change in the mindset in the way we learn to perform tests. And note how differently are we continuing learning despite the end result of this experiment. Share your views of such an experiment conducted below. 

Concluding thoughts — Know that, if we did not try finding an answer / solution for ourselves we are relying on someone else’s assumptions, beliefs, circumstances, interpretations, limitations that they had created to arrive at the conclusion. If you had interest, time, resources and a drive to self learn then it isn't wrong in attempting to learn by self experimenting and along the way one might as well gain self satisfaction (if that is something that you crave for). 

Edited to include - 

  • One may refer other's work done prior to continue or to get inspired to perform their own experiments. 
  • If you find someone with similar drive to experiment on a chosen area, then bond with the inspired group to experiment together.
  • Find Make-a-thon groups around you to be a part of such experimentation. 
  • Become a mentor to aspiring students. Share your experience and results of experiments conducted by you / your group.

Tuesday, 23 May 2017

When should a tester engage in testing?

Test Early
Image Credit:
- Why should I hire testers at an early stage of a project and not just during the testing phase?
- Why should I let my testers test early?
- How can I hire and retain testers?

- How testers can evolve as PRODUCT ENGINEERS?

- And finally, why software testing is not a boring job?

Here is an attempt I made to address these questions.
As far back as my memory goes, I have been an advocate of testers involving themselves in the SDLC right from the beginning of a project. I have questioned when no testers were invited to the Architecture Review Board meeting at a previous firm that I earlier worked with.
I strongly wish that testers start contributing to a project from it’s discovery phase. Right from when the decision is made to build the software. This means that we do contribute to building the product right from the beginning and are not mere time wasters of programmers (coder/designer) who have already spent considerable amount of time learning about the product, data modelling, coding, unit testing and deploying the code to the test server. And who then will have to pass on all the (or filtered) knowledge to a tester just before or during the testing cycle. Does it annoy you as a programmer?
Point to ponder here: Is this the reason why programmers are paid more as compared to the testers? Let me restate it for the testers: Is this the reason why the testers are paid less as compared to the programmers?
Moving on: How can I as a tester contribute from the beginning of a project?
Here are some solutions on how testers can collaborate with the client / Product Owner, programmer, designer, SEO engineer, security analyst and contribute to each phase of software development.
Requirement Gathering Cycle
When the client / product owner shares the requirement, resolve to this:
As a tester, I want to refine these requirements based on quality criteria so that I will not contribute to cost, effort and time wasted at the last phase of a project.
And do thisShare a clarifications log with the client with the assumptions, clarifications and suggestions to enhance the requirement.
The clarification log can consist of columns in a sheet with these details:

|Query |Clarification by the client / Product Owner |Priority| Implemented in sprint|
Example: The user is able to download the report. 
As a tester, you can ask:

Query |By user do we mean a guest user or a logged in user in this context?
Clarification by the client / Product Owner | Both the guest user and the logged in user
Priority | Low / Medium / High 
Implemented in Sprint | Sprint number

Above is an example of the clarification(log) which we maintained throughout the product life cycle by the whole team in a startup I worked at. The programmers then become better equipped to add both the scenarios of making the report available for a logged in and a guest user.
Understand and refine the requirement/s when we receive it so that as a tester you can start contributing to the quality of the product and build credibility for yourself right from the early stages.
Design Cycle
Develop skills required to test the design / wire-frames. Some references are below:
Test for user flows / navigation, user behavior in the design cycle. Do not wait until the end of functional testing to begin with User Interface and User Experience testing. We are responsible for a user forming good habits when they use the software built. Let us make every click count :)
Development Cycle
Test the code that is being developed for missing validations, known vulnerabilities and bugs, ask for access to the code, database and learn what is being implemented as part of a fix and what is the impact of the fix. This helps us as testers to learn about the fix and the impact early on. And help identify a bug during the coding cycle and in fixing it then rather than wait for the fix to be made, unit tested and deployed on to the test server to be tested and then for the bug to be logged in the bug logging system to be fixed and re-tested.
This to me sounds like waste of valuable time for all involved.
Testing Cycle
Now that a lot of time has been invested by you in testing at different cycles of the project, utilize the testing time effectively to test the system post integration. Take time to learn about effective bug logging, interactions with the application, it’s users and invest time to gather user feedback and enhance the product suitably.
Release Cycle
Proceed confidently to the release cycle. Take time to test the release notes in dev/test/beta phase. Check for version numbers, fixed bugs section, whether adding this information creates an impact, can we do away without adding the trivial details. Those users who will read the release notes (which is not equal to the number of downloads) are unforgiving if there is nothing new that they can learn post reading the notes. Add value by bug logging and enhancing the product quality at this stage too.
Maintenance Cycle
Use this time to work on those low priority bugs and get it fixed and re-tested along with the other bugs found by the team / user feedback / suggestions / user reviews that you read.
Invest time earned to learn, take testing courses, give talks, attend webinars and conferences, invite users to test and to gather another test idea. Up-skill to remain relevant in the ever changing and ever growing industry.
Investing early efforts to test can help address major problems which we are facing as testers.
1. No time to test.
2. Building credibility early on.
3. Knowing that this credibility eventually gets translated to respect and testers being treated equally with the other roles in an organization.

My question for you today is: Do you recognize valuable respected testers around you? 
If yes, make them your mentors today. They are waiting for you too :)
Earlier published :

Wednesday, 10 May 2017

Few pointers to the translator

Certain translations that I came across triggered me to add some recommendations to the translator (someone who works on translations) who is yet to recognize or who undermines the value that they create by adding translations.

As I reckon that it is essential for a translator:
Click on the image to view it in an enlarged form.
  • to possess language skills (reading, writing, speaking)
  • to have knowledge on the tools used and 
  • to develop a sense of onus and service to the community.

In the above example:
The author, Girimane Shyamarao has written a book titled: 'I / Myself, Children and Education' but the translation roughly is made to as you see 'I have children and education'. Such slip can be avoided if we meticulously learn the language, the meaning/s of the words used and in a contextual manner.

Some recommendations are now part of the guidelines that I had earlier created when I was involved in translating some educational project for Khan Academy. Thanks to my mentor Julian Harty for encouraging me to volunteer to translate.

A few lessons learned are shared below in the form of a mindmap.

Click on the image to view it in an enlarged form.
Or refer the images below.

If this write-up inspires you to take up translation work, then do create an account with Khan Academy here: and volunteer to contribute.

Saturday, 6 May 2017

Socially Challenged By Social Engineering

Socially Challenged By Social Engineering - A study on Social Engineering trends in corporate culture.

Troy Hunt had advertised his Ethical Hacking course availability on Twitter, and since then I had wished to opt for Pluralsight learning (where it was made available). I got ample opportunities to implement the lessons I was learning this week.
A few scenarios that were opportunities in disguise for me to exercise the lessons learnt are as follows:
 — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Scenario 1

The first attempt — Creating a sense of urgency.
A co-worker let’s say ‘X’ who had met the team twice and had spent considerable amount of time knowing the work we do, had wished to seek some more information. And it came as an email request. This information which needed to be shared, yes was secure information.
What seemed obvious at first but suspicious next was that there was a sense of urgency in the email sent. “Need this information by end of day”. It did not though say who was the consumer of this information.
While I made genuine effort to fetch the information, it occurred to me that — Why is X asking me this information? (When X knew someone else in the team who had spent a lot of time with X and had built a rapport already).
So, I cross checked with all the others in the team. I inquired, “Did any of you get a similar request to share this information?”. The answer was ‘No’. I registered this.

The Second attempt — Introducing an unknown character.
My next suspicion was, X had made an indirect attempt to seek information via a new supposedly a ‘girl’ (before sending the email request). This girl was unknown to me. I wondered ‘who could this be’ when I got the request from this stranger. There was no attempt made by X to introduce the ‘new girl’ to me. This was the give-away move. Because when X knew me, ‘why’ make an attempt to introduce a stranger to seek this information. What was X thinking? Now that X has realized what he did and has spoken to me about it, I will attempt to know the why. 
Interesting at the same time suspicious to know why introduce a ‘new girl’ when X who knew me, could have directly contacted me.
Next day, the ‘new girl’ started pinging me (and again with a sense of urgency) to gain this information which was by now was already asked over an email by X. ‘New girl’ then told me that person ‘Y’ wanted this information. I did not know who Y is nor I was introduced to Y before or during the conversation. I clearly replied, I do not have access to this information and as I have replied over the email, let us wait for the authority to grant us the access. And I included Y in the email who was the ‘CONSUMER’ of this information.

The third and the fourth attempt: Cause fear and threaten.
Rest assured, I bid the new girl bye benevolently and logged off. Then X who obviously is aware that I have not given the new girl any information so far, calls me on my phone and it is evident from the start of the conversation that he is not in the right frame of things. X then tried the third mode: To cause fear in me to gain access to the information. When that did not work, X then uses the fourth mode: threatens me by conveying that ‘I will go to the highest level of escalation’. I am calm,very composed as I knew that I am not the authority to give X this information even if I had access to it.
To brief, Person X’s tries / attempts to gain information are as follows:
  • Create a sense of urgency for reasons (valid / invalid).
  • Introduce an unknown person (a girl, don’t know why?) — This being the incorrect move for obvious reasons. X had undermined himself as the first POC to reach out to me and had caused me to have my first suspicion. Please take note how this gullible new girl was victimized in the entire process.
  • Cause fear which then culminated as a threat.
  • Know and seek information from right sources.
  • Quote valid reasons for seeking the information.
  • Inform who is the end user of this information so that it can be sent directly to the consumer and not to the others who should not have access to this information.
  • If the seeker is the end user, then it can be helpful so the mediators do not gain access to this information.
  • Learn and know how to talk to anyone.
  • Educate the gullible, they need help.
This scenario not just helped me implement what I was learning but also led me to another knowledge source. When I was at a book store recently, my eyes lit up when I saw this book 'Maatu Hegiddare Chenna'? authored by Girimane Shyamarao (ಮಾತು ಹೇಗಿದ್ದರೆ ಚೆನ್ನ, ಗಿರಿಮನೆ ಶ್ಯಾಮರಾವ್) which roughly translates to 'How words uttered must be?'. Now reading and it is a good read for anyone who wishes to be a good speaker.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Scenario 2

corporate social engineeringA co-worker ‘A’ was made an easy target for wrong doings of similar patterns from his past and the authorities were trying to action against A for the same. I wrote to A about the allegations that were made.
A was taken aback and replied with proofs on what was happening.
I probed further, as I had spent lot of time setting things right with A. This probe revealed that these were false acquisitions and was not done to offend anyone in the process. But A did reveal that he had only faulted with me and not with the others, assuming that I will forgive but the others wouldn’t. I rested this case, but was glad that I inquired to get the proofs when there were false acquisitions being made on A. When I reported the authorities about the false acquisitions, the authorities understood while they also exhibited suspicion that A could be lying.

  • Information coming from a senior needn’t always be true.
  • Know that the an impersonator usually disguises as someone with authority, is trusted, is a senior, is legitimate, is respected. This doesn’t mean that you fear them but genuinely question and learn about the intention.
  • Learn from past mistakes and know when to stop.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Scenario 3

This is a case of:
  • An attempt to please a person with authority.
  • Fear of senior/s.
  • Not learning from the past mistakes.
Some give away passwords in plain text when merely asked to share only the username, this scenario occurred when a senior with a sense of urgency asked for information from a new joinee. Newbies are unnecessarily petrified, help them out and create a safe environment rather than instilling fear.
Do not leave mobile devices / laptops unattended, that can cause anyone in the vicinity to gain easy access into the system. Have strong passwords (policies) and be aware of the fact that there could be a threat lurking around. Educate and be better equipped to address security threats in the form of social engineering.

  • Educate the new joinee.
  • There is nothing to be feared, but only to be understand - Quoting Madam Marie Curie.
  • Instill a positive and safe environment to question and to learn from all.
  • Encourage learning and create a culture to reward learning.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — 
Final thoughts
  • It works isn’t sufficient. Know that SECURE systems are as important and for any reason security should not take a back seat. Introduce Secure Development Life Cycle at all stages of development.
  • Be aware of known vulnerabilities and address the security aspect of the system that we build and test.
  • Share professional information wisely to the right consumer.
  • Do not share personal information where it is absolutely unnecessary.
  • Do not encourage personal information seekers.
  • Beware of what you share on open source mediums. Know about OSINT — Open Source Intelligence. Know nothing is free, your data is what you trade for using open source apps.
  • Socially challenged is what we become if we fall prey to social engineering.

Monday, 20 March 2017

10 things I learned from being AGILE.

10 things I learned from being AGILE.
  1. I do not have to worry about knowing everything about the product / feature right at the beginning. I can take my time to learn the product feature by feature. And get to learn together with the team and from many about the product right from it's discovery phase. 
  2. Being Agile is almost like studying self, what works for me and what doesn’t. And to learn dynamically to make necessary changes when needed.
  3. Learn on the GO what technique / method / approach works for that context and discard the rest.
  4. Switch to the right sources of knowledge. It's about also being a pendulum when needed, shift left / right to deliver.
  5. To not buy the garbage, but to question and learn than mere adherence. To go figure out who can help, to have my own point of contacts who can help and to network with the learned. This means - To be DRIVEN.
  6. AGILE - Is not the ultimate rule book of do’s and don’ts.
  7. Quick and dynamic is what it makes me in how I begin to do things (requirement gathering to release and beyond). 
  8. To invest and better my own learning. To work on improving the code, the tests and the rest is good. 
  9. There is a good kind of urgency in Agile, to get things done.
  10. I can be honest and not be questioned for being honest. In sprint planning meeting, I can honestly share my presence / absence plan. It makes people honest and keeps them that way.

  • When taught well we can all learn from this professional experience of being agile and make other aspects of our lives better.
  • Do not be blinded by half baked ideas, figure out what works for YOU and apply it.
  • If calling it Agile hurts you for reasons known / unknown, call it by any other name that works for you.
  • Learn to learn from the right knowledge sources.

Tuesday, 14 March 2017

Problems are short-lived.

Problems are short-lived.
  • If we genuinely wish to resolve it.
  • Find and learn ways to solve it. And in the process of solving it, learn and equip oneself to address the problem if it recurs.
  • Communicate and seek help to learn ways of resolving it.
  • Set out to tackle it head-on post equipping oneself.
  • Set a target date for it to be resolved. So we can move on to solve the next one.
  • Learn from anyone equipped to address it, without a bias.
Here is an experience sharing of how I tried to address a problem.

I tried to recently help an employee who was in trouble and had called to ask for help stating 'You help everyone and hence I came to you'.
I was happy go lucky, trying to help others. The joy I got when their problems were getting resolved and the feedback I was receiving was enthralling. Without re-thinking, I was willing to help this employee too.

While I was away, the same employee threw a temper tantrum which arose from an unfulfilled *ask/want. When I came back in office, I tried to address the problem which the employee had shared over the call. I wished to help and address the problem face to face in a benevolent way.

(Later did I learn that the employee was not performing few tasks because it was not something that the employee wanted to do to get to the next level). *Ask/want, was to get promoted.

I believe that 'there is no professional problem which a quiet mind and effective communication cannot solve'. And clearly effective communication was not happening because the employee when we met to resolve the problem was firstly talking continuously. (Yes, this means less listening).
Secondly, is reading too much into my facial expression (which as I am well aware off, reflects nothing but what I communicate and utter justly) and conveying that 'I know what girls are. I can read their facial expressions and derive what they say and mean do not match'.
It has thus far not happened to me, that I said something and meant another thing. I am direct and say what I mean at all times.
Am there and fully present, listening to the employee and have offered to help and this happens! And the employee continues to demean.

A few days ago, there was no need to offer kindness in this situation (as I was away and did not have face to face connect with the employee) but training only. This time I did offer kindness to the employee and professionally. I conveyed to the employee that I am here because I wish to help. And left the room thinking 'All this I had to undergo because I tried to help you out in your difficult situation!'. What I did do was, respectfully listen to the employee, the concerns, immediate action points for both of us, convey the do's and don'ts and leave.

Food for thought
If a lady shows kindness, then she is assumed to be sentimental! If she is professional, then she is rude! Some expect bravery from a lady, for her to be a lady and to be a professional. This isn't true, and it creates unnecessary expectation from the lady to be her unnatural self. Have you ever noticed how some lady bosses put on an unwanted rudeness because of such silly / stupid expectations.
It is quiet natural for us all to be just ourselves without putting on an unnecessary brave face.
Why can't a lady just be a lady and just be a professional? As being professional for a lady isn't like entering a lion's den. It is much simpler and natural, why make it different and difficult because it is a 'her'?

I recollect what I learned at Fiona Charles workshop at European Testing Conference on Leadership, from management related tweets of Esther Derby and blog posts of Johanna Rothman that it is so much better to not heed to the negativity around and move on to what you set out to do. This allows one to focus on the good and rest the rest.

There are territories one must not cross as a leader when problem solving, like the one's mentioned below.
Offer to help those:
  • Who do not wish to learn - (How can tutoring help in this case?).
  • Who have a 'i-know-it-all' attitude - (Who can tutor someone with this kind of perspective to problem solving?).
  • Whose confidence you have not gained yet.
  • Who are brainwashed time and again (they are in a vicious circle).
Do what you set out to do.
Beware of the naysayers and maintain a convenient distance from them.
Invest your time where it's worth it.
Give a listen to this song 'What a beautiful world' by Louis Armstrong :)
Truth be told, be kind. BE KIND to yourself, so that you can be kind to others.

Wednesday, 22 February 2017

Mindmapping And Common Pitfalls To Avoid

There was one occurrence of plagiarism of my work, a blogger by mistake had passed the blog and map I had shared, as their own. I sympathized for that person, if I had mentioned my name or had personalized my work (with a signature / logo) then I would not have put that person in this situation. I am to blame, as I shy away from making my work copyrighted / add a signature. 

My knowledge sources are many. 
I refer books, articles, watch videos created by others, learn from many and from their experience. 
My credit goes to all who share their learning and in that case I cannot take credit.

Another incident that triggered me to collate common pitfalls to avoid when we share our work with wider audience is when I posted my own work over a year later without revisiting and revising it. A learner from the community TeemuVesala reviewed and provided with suggestions to revise it. Thanks Teemu.

Based on these events plus the mind map exercise that we conducted at my work place, as a result of which I got to pair with DanAshby to review the mind maps has helped me create the below mapThis can also save time, effort, reputation and credibility when we share our work.

Click on the images to view it in it's original size.

Friday, 17 February 2017

European Testing Conference 2017

I have earlier shared my experiences with conferences (local and others) but being at European Testing Conference was a tad different experience as a speaker and as a participant.

As a participant

What I liked?

Attendees and speakers got to attend the workshops scheduled on pre-conference day.
The workshop that I chose to attend 'Test Leadership' helped me share some of the problems that I have had with my stint as a tester, test manager and a leader.

Special mention of Speed meet.
  • One goes to conferences to listen and learn about new tools, new features of an existing tool, to learn about techniques first hand from the creator, speakers and volunteers who have signed up to teach.
  • To find solution to a problem that they are facing.
  • To discuss problems and meet people who can help them build something together.
  • Speed meet gave such an opportunity for the conference goers to meet a mentor / friend who can help them learn.
  • This meet brought many Twitter friends closer. Mostly the introverts / ambiverts to share about themselves.
  • At conferences we witness many rushing from one talk to another. If lucky, we get to spend time with a mentor and learn from them during the break/s. At ETC, breaks were scheduled to accommodate such meetings to happen frequently. It was great to see people come out of a talk and share their learning with others who were in a different talk. I listened to three attendees from 'Mob Testing' workshop during such breaks.

What Lessons I Learned?

To take 'me time' to learn lean leadership and to use that time for strategic thinking (that I learned from Johanna Rothman 's blog) even when there are interruptions.
Learning to say no, different ways of handling interruptions.

Many suggestions were shared by the audience and Fiona Charles who ran the workshop, on handling interruptions.
Some suggestions were to use the below methods to let your adhoc audience know that you are now available / not.

  • Red / Green flag at the desk.
  • Flag up / down.
  • Head phone on / off.
  • Block your calendar.
Participants from around the world shared book references, articles to read and techniques to learn and use for some of the problems shared in this workshop. Glad to have been a part of this workshop with Fiona and the attendees.

What I liked and learned from?

Fiona and her way of running the workshop.
Listening to your audience and letting them converse and share their experiences is very much needed when we run a day long workshop.
Providing your feedback when needed and when you have something valuable to add is what I learned from both Fiona and the audience.
Keynotes by Kevlin Henney, Gitte Klitgaard and Fiona Charles.
And I did love Finnish culture which is different from where I come from and is grand.

As a speaker

Instant feedback for my talk from the organizer Maaret Pyhäjärvi was valuable.
I could with the help of this feedback, convert the talk to an exercise during the Open Space which was held at the end of Conference day 2.
I was introduced to Market place for the first time here.
Market place is where the willing participants come forward and ask for knowledge on specific topics to be re-shared. Mob testing / programming, Calabash, Creating and using re-usable mind-maps were topics that I recollect were talked about again. 
Thanks to participants few of whose name I recollect Sergey, Evgeny Borisov, Miroslava Nikolova, Vivien Ibiyemi, Ru Cindrea, MaaretP, Kevlin Henney, Bettina Stuhle, who were present at my talk and provided feedback.
Loved speaking to this audience, I just wished they would be a little interactive. Later did I learn from Kevlin Henney that the Finnish audience is a bit different from the US audience where I had earlier spoken at. Lesson learned, I have to change my style of delivering the talk differently based on the audience and where they come from.


A nice experience conferring at ETC 2017.
Gained confidence to change the style of the presentation on demand and based on the feedback and deliver at Open Space. 
Met a lot of brave and independent people from the community, learned from them a lot professionally and personally. 
Met leaders from the community and made new friends.
Learned that I can help the community in my own way.

LLewellyn Falco, was a grand host and organizer of the conference. From this experience, I learned to extend my help / support to two leaders who will be conferring in Bangalore, next month.

My thanks to
Mentors Carsten Feilberg, Isabel Evans for their valuable time and guidance. 
All my friends at European Testing Conference who equipped me for Finland. 
The organizers (all involved) who facilitated and provided with timely help. 
My organization who gave me time to be a part of this learning.

European Testing Conference comes to Amsterdam in 2018, stay tuned and to know more:
Follow EuroTestingConf on Twitter and hashtag #ETC2017 #EuroTestingConf #eurotestconf

Image credits:
Photographer, Twitter, Llewellyn Falco.

Thursday, 16 February 2017

A few tips to mindmappers

As I started out to mind-map the test ideas for a feature that I was testing / learning to test, many lessons were learned and are now shared below in the form of tips to use when we create or reuse mind-maps created by others.

Reviewers and the community of learners helped shaped the way I today create maps.
Some of them from the community who read / used the maps provided me with valuable feedback which are incorporated in my learning and is brought to you in the form of these tips.

Hope these tips can help when we start out to build a map and share it with wider audience.

Make it generic - Here it means, do not feed your audiences with steps to re-create but only act as a trigger to move on with an idea to test.

Earlier shared at European Testing Conference

Coming next - Common pitfalls to avoid when mind-mapping.

Thursday, 26 January 2017

How to pick a mind mapping tool?

For those of you all who are starting out to mind map and like to know what tools are available and on which devices/OS, here's a non-exhaustive list of mind mapping tools collated. Hope it helps you pick a tool that you can make use of.

How to pick a tool?
  • Make a list of tools to explore
  • Shortlist few based on the device / operating system you use
  • Explore the features available
  • Compare it with the rest of the tools available
  • Choose one that best fits your need
  • Use it for free, check the features available in the paid version
  • Try to use other tools when in absolute need
  • Continue to explore a new tool that's made available
  • Contribute to the open source community by suggesting improvements or by reporting bugs found
  • Get in touch with mind mappers (mind mapping community) to learn what / how else they use the tool
  • Engage with the learned to learn tips and tricks

Mind-mapping tools
Click on the image to view it enlarged.