My learning from Agile Testing Days Asia 2017

I had got an opportunity to attend Agile Testing Days Asia 2017 (ATDA-2017). I thank my friend Jyothi for sharing me this opportunity.  Before I happen to say much, I request the reader to go through this post.  I will share what I felt on being part of this conference and what did I take back to my desk so I can practice my testing better than before.

I'm a person who adapts to an environment of project and do what is needed for delivering the best. Whether I'm in a project which claims to work on Agile principles, manifesto and its various methodologies or in a project that claim to be on other methodology, principles and process, I work to see what best I can do there in context.

With that, I have no idea if Agile is successful always or not. I have an idea -- the teams working together to accomplish will get it when each assist each others to deliver.

I have worked with teams which claims to be on Agile. Still being on Agile, I have worked beyond office hours, in weekends, in pressure, and yet seeing the release delayed beyond timeline. There are all problems here as exists in projects which claim to be non-Agile i.e. before Agile got adopted to Software Development. Its all in understanding, solving and going forward is what I see irrespective of principles and methodology.

I don't say Agile is wrong or effective or not effective. I learn, it is we people who adapt it, will do it something else be Agile or non-Agile. Now, I will stop talking on process or Agile here as it not my area of interest for now.

ATDA-2017 conference was organized by STeP-IN Forum and I should be thankful to them. It is not an easy job to organize a conference. Getting people together by taking care of their presence, giving space for networking with the fellow testers of different organizations and helping to carry the thoughts back to work place is not an easy effort.  I thank you STeP-IN Forum, your people and the committee. Respects!

Coming back to conference, I attended Conference Day 1 and Conference Day 2.  The audience were from around India, Bangladesh, Canada, Romania, Spain and USA.


The day 1 had below talks

1. Evoke the Soul of Agile - Keys to Lasting Transformation, by Selena Delesie, Leadership & Innovation Coach, Speak & Soul Igniter, Delesie Soljtions Inc.
2. Leveraging Global Talent for Effective Agility, by Todd Little, Agile Leadership Consultant & Innovation Software Executive
3. Agile Testing of Microservices, by Praveen Kumar, Manager-Agile Practice and Manoj Kumar Nagaraj, Director, Capgemini
4. The Agile QTOPIA, by Rahul Verma, CTO & Founder, Test Mile
5. How to avoid Internet of Insecure Things, by Gaurav Maheshwari, Engg. Manager - Software and Prashant Jain, Project Manaager, TVS
6. Building Inner Trust - there is no agile without confidence, by Ginna Encache, Founder & President, CHOICE
7. Rev up to Agility, Apply Lean Six Sigma in Testing, by Ramesh BR, Sr. Director, OpenText
8. Agile Games -- to build a jeep

The day 2 had below talks

1. Divide and Conquer: Easier Continuous Delivery using Micro-Services, by Carlos Sanchez, Engineer at CloudBees, Member - Apache Software Foundation, Startup Technology Advisor
2. What New Approaches to Software Can Teach the Enterprises, by Puneet Gupta, Global CTO, Brillio
3. Agile and Startups - What can go wrong - A case study, by Vipin Jain, Director QA, Astegic Infosoft
4. All sprints are guilty unless proven innocent, by Deepak Chopra, VP, Genpact
5. Testing in a Responsive Enterprise, by Abhishek Johri, Agile Coach, TEK Systems and I remember other co-presenter was by name Mahesh, consultant.
6. Agility for The Last Mile, by Diwakar Menon, Founder, Last Mile Consultants
7. There is no such thing called Agile Testing - Debunking Rituals and Ceremonies, by Srinivas Kulkarni, VP, JP Morgan
8. The Big Fight - Cirque (Dangal) -- Agile - to be or not to be. Debaters -- Raj Netravati (moderator), Selena Delesie, Rahul Verma, Pradeep Soundararajan, Jayapradeep Jiothis, and Jayaprakash Prabhakar

Here is my experience of Day 1

• I understand, Agile practice is a culture. It is very much essential to have culture that helps an organization and team grow and deliver. In doing so, the process come in; how to make use of process and tailor it to accomplish, is the key. This was iterated probably in one or other way by every presenters giving an example of their work and process brought in to the project or work place. I did not see any thing about testing. Rather it was all about the process.
• Todd Little shared about domain knowledge importance in programming and testing from one of his project relating Petroleum Industry. Further he went ahead and shared how collaboration is important when working with teams situated in different geographical locations.
• A contrasting presentation was from Rahul Verma and to me is evident as I see him presenting in similar lines. I was not of surprise, however the audience had tickling and laughs as he expressed his thoughts. It was around the process, culture and mindset.
• About security in IoTs, it was more about the practice and guidelines. I expected to see testing here. It did not happen for me. I repeat it is for me. I'm not sure about others. And this was the only presentation which did not have the word 'Agile' in presenters talk.
• Gina Encache shared about importance of people relationship in project and working place. It was her first talk and glad that she made it in India.
• Ramesh, gave the case study of his work which had to with process and illustrated how it benefited team in saving time and deliver. Nice! He showed his team members photo to the audience and that is remarkable! But again I was disappointed as I did not see testing here. It is about process. 
• Game session was interesting. It had three teams and each were given stuffs to build a jeep. I enjoyed watching it.  The collaboration, communication, team efforts, and one goal to accomplish helped all to stick together. Interestingly, here team did not follow any process however it was time boxed activity and team members spoke what they have to do and in what order. This was an example probably which the conference should have highlighted having each team to talk on second day of conference. May be the organizers did not think about it. I enjoyed this activity.
• Atul Khatri presented his stand up comedy. He did say, that we will recollect his jokes after two or three days and it gives tickle and brings the laugh.
• Followed this, it was a announcement of winning team who designed the jeep in given design constraint and time. 

Here is my experience of Day 2

• It looked as continued journey for me from Day 1.
• I did not get how to detail out testing the Micro-Services. It was more about the infrastructure and concepts. For one who hasn't heard about micro-services, this session will help to get a idea at a conceptual layer.
• Vipin Jain, had a case study and it was around a process and the impact if not understood how to use process.
• After this, all talks were on process and how to go with process so one can be informed well before a huge cost in the business.
• Testing in responsive enterprise, I was waiting for this talk. Eventually, this too was on process discussing on latest trend in software development and its methodologies.
• Following this, there was a debate about being Agile or not to be.  Each person in debate seat had their views on Agile, tools, and Continuous Integration.  But, none of them here spoke about testing! That was too sad. I expected at least they bring up point asking where is testing in all what we have heard for two days around Agile. It did not happen. See, how one gets into process trap while all are talking around the process.
• Shrini, I have seen him presenting and sharing his thoughts. It was no surprise for me. I did expect something from Shrini which would have spoken about testing execution. The only presentation which said word "testing" quite often along with the words "process" and "Agile".

My observation

• The conference was Agile Testing Days, but it did not have testing in it i.e. in two days of conference.
• Most of the speakers were of management level and was on process thoughts.
• Whereas most of the audience were in execution level i.e. Testers who do testing. See the gap of presenter and audience. 
• Process, process, and process.  The same is heard in office and same was heard in conference. Where is the testing? Or, where is the automation? How to do it? An example and demonstration of one such problem went missing in the conference.
• Testers want to know and seek help in doing their task better. At least I look for that than hearing about the process. I did not get that. 
• The game activity in the conference is clear example for collaboration and deliver as a team in knowing what is the goal. In the game session all were agile and did what their role expected do to in the team for building a jeep by assisting each others.
• I do not remember if there was much discussion on The Four Testing Quadrants and how to work on it, if Agile Testing was being discussed in Agile Testing Conference. As well I remember, just one liner mention in Shrini's presentation on the four quadrant of testing.

My humble appeal to STeP-IN committee

• I wish to share my honest opinion here as a practicing tester and seek your help to practice better. Please do not feel bad on me.
• I see the most of the audience in conferences were to be practicing hands-on testers in desk. It is they who execute and inform the stakeholders (managers and management) about the risk. When we testers better our testing skills, eventually we will learn how to deal with process and principles that comes with any name. Thereby we actually assist the culture of the project and company as well to get better. That said, I request to have more of testing in conferences than process and management.
• If looked into presenter and audience, you will see the gap clearly.  Please do encourage and pick the hands-on testers. Give more slots to these testers while we give few slots to management people. Ask for testers to come up and speak about their testing, automation, problem solving and innovations. This is what we need, importantly, to march forward in the testing practice as a start.
• Having management people talk all the way is good until we testers get what we want to get. If not, it will be boring, at least for me.
• To the panel which selects the paper or topic for presentation that come to them, please do keep the practicing testers in mind. See what is that we testers need and get that. The orientation of problem for tester and management is of different kind. You see, management sends their testers to conferences and not most of their management to conferences. I'm not saying to eliminate management talks but that should not fill the space and eliminate testing all together.
• I wish to see audience feel happy for coming to conference and say it was very useful and recommend it for themselves and others.

I took below to my desk from this conference

• To focus on my testing. Learn how to make use of process to its best for delivering by adapting it to the context on tailoring.
• Convey the same to fellow testers on desk and work along with them to deliver useful testing which is of value and creates demand for itself.
• I said myself, testing is agile in itself when understood the purpose of testing. So is the automation when it is to assist the testing. If this is consistently learned by me on each day, it will help me to adapt and tailor for any process to do better.

When not to test? When is the no need of testing?

I saw a tweet interacting with me and it was from my colleague Pradeep Lingan (PL). He had shared a question -- When to start test once the build arrives?

When to start test once the build arrives? @testingGarage @moolyatesting

— Pradeep Lingan (@Pradeeplingan1) March 15, 2017

I was in silence for few second on reading this question. In silence, I asked myself, "Why should I test? Why at all I should start testing in whatever timeline of product development?" Now, I have two questions, the one from PL and the other which I ask for that question.

The question asked by PL is not always easy to answer. But it is a very logical and technical question which should be answered. If not answered, stakeholders involved and those who are expecting 'valuable' (if expecting valuable) from testing will happen to ignore testing.

I wanted to ask PL what is the context in which he is asking this question. You see, it is not a simple question. It can be better understood when known the context which raised that question.

As a practicing tester, I understand, when there is contextual question, it is also possible to derive questions which is context free. When I say context free questions, it is the question which is generic and can be used along with contextual questions.  Is context free is also a context? I will leave this to you for brainstorming.

I will not ask PL for context here. I will answer my thoughts using context free learning approach here. From there, I will let PL to brainstorm with context for the question he asked.


Why we test? When is "the need" for testing?

I learn, I test and purpose of the Software Testing is,

• To provide information on product, so authorized stakeholder make sound informed decision on product's development, scope of development, pause, abort and release
• Information on testing the product can be -- about it's quality criteria and risks around it; and about the risk of carrying out and not carrying out the testing in context
• Information obtained from testing can be used for -- to make decision about the product; about the decision which stakeholders going to make and risks out of it; if it is worth to pay for tester, testing team and seek the information which is being received; are we investing too much for information that's not worth; prioritization; should we carry out much more testing and better testing?  etc.

Software Testing is not about fixing. Software Testing is to assist the fixing in better, rational and empirical way. The information obtained out of testing to be used for bettering the product. That means if carried out testing, it does not mean, it improves product. When information out of testing is used to better the product by fixing, it helps the product to improve.

The above points should have helped now to start understanding the Software Testing and its service to development of product and stakeholders. If I and you mutually agreed for above points, then you are looking for information which can ruin the existence of product or purpose of building the product or something that will incur loss to everyone in the business.

When not to test? When is "the no need" for testing?

On reading why we test and when testing is needed, it is quite straight simple to know when not to test and when is there no need for testing.  This can be used as a start point to decide whether to start testing or stop testing.

In below cases, it is useful not to test

• When a tester and testing team has no clarity in knowing -- what is useful testing and not useful testing for stakeholder
• When we don't know about risk(s) on which the testing has to focus in product and provide information
• When we have no clarity on what is expected out of testing
• When a tester or stakeholder feel the outcome of testing being carried out is not going to help in making the decision
• There is no area or a question in the product for which testing help to see an answer
• When no one is interested and curious in outcome of the testing

In below cases, there is no need for testing

• When the stakeholder learns or believe and say there is no risk in product, and say to stop testing or denies testing for product
• When the outcome of testing will not change the decision of stakeholder
• When no information is expected out of testing
• When a tester or stakeholder feel the outcome of testing being carried out is not going to help in making decision
• There is no area or question in the product for which testing helps to see an answer
• When no one is interested and curious in outcome of the testing

It is business and business is also on money and time. As a tester it is my responsibility as well to help make decision when testing is not needed and when not to test. For doing this, I need to build the credibility with stakeholders.

However, as a tester, I continue to uncover risks if that really helps stakeholder and if I'm sensing it from my testing. While this is being done, it is also good to note, time of tester is also important as it is value and money. If I think my investment on time is needed here, I will do it, provided I see a good cause and benefit there.

Did that help now in context free way to decide when to start testing once the build is available or yet to be available? Further, build the contextual reasoning to figure out when to start, when to stop and no need for testing when there is a situation.