Friday, January 17, 2020

My Starting Days with BDD, Cucumber and Automation

I think how to put a thought of me into discussion mode before I start to speak. I take several approaches and strategies on same i.e. to bring into discussion mode rather as a argument and debating tone. Yet there will be set back at certain times and I learn from it. I have not let it to demotivate it me, but I have taken it as an opportunity for communicating better. The intention is doing the job best and right for context and vision of the organization.

I once said, "I don't know and this is what I know" in a meeting to a team member. When I reflected on myself later that day, I could see that I had given up on holding it for long time. Which usually I don't do i.e. I don't give up. I get stuck to it and have patience with silence in doing the task, which looks odd most times to people around me. The point here was not doing it to perfect or excellent, but doing the work in the right way. Figuring out the right way is not easy when we have team with diverse skill sets and culture practice.

Most of the times I wrote feature file (outcome of the collaboration in BDD practice) that was written, though I know it should not be me writing it. I wanted to keep it at least on average though not at good, hence I rewrote on review. Different teams practicing it in different ways and none knows who is better and not better.

If there is a design approach for a product in programming, every programmer follows it in the team, say. But this does not go in testing and automation practice, most of the times. When I sit back and ask myself, "why it is this way?", I happen to see -- could be the team is not trusting on what I'm saying? Then whom do they trust? I don't have an answer for that as well. I asked myself, "why are they so confused when we have clear cut solution approach with clarity?" I learn this is where the skill and expertise gets distinct in the work.

During this time, I observed the work we were doing and I use to analyze by staring at it to know -- what are we doing and are we doing it right? That was one of key job I believe in my role. To mark where we were right and not right, I had to learn the subject which was new to me as well. I took time here thinking it will benefit the team and organization. I asked myself, is it worth doing it? Then who else had done it? I have no answer for that in me.

In this context for me the best thing to do was, to let the testers do it and if they see a failure or difficulty later, so they might reflect back. That was a hard call which I took. I failed! You see, that's how the failure tag is put on a senior or junior in team for doing and not doing a work, when nothing goes as expected. Anyways, I failed!

What did I learn from this, then? It is okay to fail and I have pride in it. What I got from this fail are incredible learning.

I'm glad when a friend Nikolay wrote about it here --

It is not just me who goes through it. There are other people too and I saw on reading the post of Nikolay. It is one of the good posts which I will refer to a tester who is practicing automation using Cucumber and the word BDD.

As well, I observed, at times even I give up and lose bit of my patience which I hardly remember doing in my career so far.

At the end, if the question is "Who is wrong here?", I don't see anyone. There comes the time -- where a person A feel other person B is wrong; then the person A feels I'm wrong and person B is right; then the time comes, where person A see that both Person A and person B both were right (or wrong).

It was the outcome which counted most that day and the decision that was made for the outcome, speaks out more unsaid. The team has to move on and continue doing what it is expected to do and in a right way for context.

Tuesday, December 3, 2019

Test Charter and the Four Components of a Charter

A tweet from Ministry of Testing was -- Do you use Test Charters?

Speaking out of my so far practice, I heard the word 'charter' 10 years back when I was referring to SBTM in James Bach website.  Till then I had not heard the word -- charter.  The two words which confused me then was -- Mission and Charter.  

I looked into the sample SBTM reports which James Bach had shared.  I observed the word 'mission' for each session.  That is each session is chartered with a mission to accomplish.  Meanwhile, I strongly believe the spark that took off to testing globe wide referring such testing resources had its birth in Bengaluru then.  Most will say nah and disagree to it.  But that's the truth and Weekend Testing was one of its outcome.

Coming back to the subject of charter, I say, it was not that easy then for me to write one.  I got better each day and I try to get better today as well.  While I worked in the role of Test Coach in Moolya Software Testing, I pair tested with freshers and lateral hires.  I insisted the testers (whom I was assisting to practice testing) to write charter on their own.  I could see the difficulty they were going through and it was a mirror of me showing what I went through some time back.  In beginning all had difficulty to practice in session as they could not concentrate for 30 minutes (forget 45 or 60 min or 90 min) and to take make test notes in parallel.  Yet, there was no practice without a session and a charter to it.

To keep it simple and make lives of the tester easier, I broke the charter into four components. They are:
1. Intent  -- What is the intent of my testing in this session?
2. Target -- What I should be testing?
3. Resources -- What I should be referring while I test?
4. Information -- What information I have to learn from the tests and how to report it.

For example, say the charter of a session is -- Browse through the different doctors displayed based on specialty by swiping the doctor info card in the app. Validate if the subsequent result pages of doctors displayed is still relevant to the specialty chosen, while a doctor can have multiple specialty.  Refer to the HTTP request and response coming in for each result page and validate data displayed on client end. Report with logs and test data when you find or feel there is a problem.

The same charter can be written as this -- Test for the specialty displayed for doctor in search result is consistent in each result pages returned by server. Make sure the test data of doctor have multiple specialty. Report with logs and test data when you find or feel there is a problem. Make note of the confusion if you have any in analyzing the search result.

Also it can be written as this -- Test for the doctor card shown in search results based on specialty chosen.  Report with logs and test data when you find or feel there is a problem.  Make not of the confusion if you have any in analyzing the search result.

If I had to break this charter into four components, then:
1. Intent -- Search for doctors based on a specialty
2. Target -- Doctors info card displayed in the app that is search result pages
3. Resources -- Specialty of a doctor; HTTP request and response; Data displayed on client app
4. Information -- The search results returned and displayed are consistent with chosen specialty? Report if any problem and confusion.

All the above written three charters mean the same.  But how it is written and details provided, varies.  What style to pick and details to provide it depends on multiple reasons when I work with team.  When I work as a only tester testing, I keep the charter pretty self explanatory with details to the reader of session notes.

In my opinion, a tester gets better in writing charter when these four components is clear and can be identified.