Monday, 27 August 2018

Problem Solving - A hands-on Workshop

Caveat: You will see and read the word 'problem' many times :)

For over eight months of inactivity, I took the role of an independent test consultant this year in June. To say the least, I went through a phase of depression. Absolutely did nothing in this time period that made me feel alive, this was only adding to the sorrow. But thankfully I found what my calling is by the end of this traumatic phase with the help of an excellent coach Selena Delesie and friends from the testing community. I alone couldn't have navigated safely through it all and I did realize post this phase, that I feel the most alive when am learning, helping myself and others along this journey.

Coached by Selena Delesie to resolve many inner tumults and a few months of releasing the pain by having multiple sessions with a friend, well-wisher, and a therapist, I equipped myself and had solved the problems that I was facing with the help of them.
Most importantly I learned what do I need to do next, what work helps me to be content with and solved many of the problems I had personally and professionally.

It was at the end of July that Ajay Balamurugadas asked me to do a workshop and co-present with him on the topic: Problem-Solving. Having spent over eight months solving the problems I had faced until then, I accepted to do this workshop and share the lessons learned. This was also the phase when I was ready and was equipped to move ahead as I had embraced life-enhancing disciplines and habits that were showing results in the form of good overall health.

We began to work individually on the slides and met only on the day of the workshop which also happened to be a national holiday, Indian Independence Day. As Ajay wrote in his blog, it was a grand experience to run the workshop and alongside with him. The participants involved a student, a new mother and working IT professionals who all had different challenges. As Jerry Weinberg rightly puts it we found that All problems are people problems. We prepared for the exercise, examples, use cases, problematic situations we had faced, solutions, not solving as an option, emphasizing and de-emphasizing where it's required, book references, slides, hand-outs, content for problem creation, identification and understanding, contexts of a problem, solutionizing, tools, techniques, tips, traps in problem-solving and in no time. It felt like a breeze.

Ajay called me this week to convey how the participants benefitted from this workshop, that we co-presented. One participant enthusiastically shared that he had solved few problems encountered at his workplace post this hands-on workshop.

We learned:
Problems can be solved by a better understanding of it.
Understanding the context of the problem is necessary to seek a better solution.
Different contexts that we need to be aware of when problem-solving are: the problem owner's, resolver's, solution seeker's context, who are affected by solving and who benefits if the problem remains unsolved.
Do size up the problem well.
Know what traps barricades you from solving it.
Don't solve it, delegate it, move out of the equation when needed.
Not all problems need to have a solution.
A problem can have more than one solution, suit yourself with what best fits you and your ecosystem.
Tough problems with simple solutions exist.
Permanent and easy solutions to the toughest problems exist.
Hasten to learn and be curious and abort the mission when it is required to.
Time your problems - they all need a target date.
Don’t let problems co-exist with you.
Make more room for solutions - paid/free.
Equip and then engage in problem-solving.
Escape a problematic situation/people - this is one of the solutions.
Make peace with solutions, they may not be the desirable ones.
Accept success and failed attempts, as one of the outcomes of your genuine effort. Embracing the result is a part of the solution.








Happiness comes from problem-solving ~ Mark Manson










As I type this, we are on to the preparations for our next workshop. If you are in Bangalore and wish to be a part of this learning, look out for announcements on http://enjoytesting.blogspot.com/

Through this all I am learning to:
Self-organize - Trello and Google Keep are my go-to tools to organize a lot of my findings, learnings. I have taken notes every day since I got over the tough phase. A glance at the organized boards, help me learn what my interests really are, where should I invest my time, and more benefits I notice as the data builds up in these data collectors.
Invest in self-care - The most important topic that Selena helped me with is to invest in Self-Care. Do more of what helps, makes you and less of what doesn't define you.
Being back to work, running the workshops and learning from many defines me and helped me to connect with myself and am raring to go.

Book reference/Optional reading
Amplifying Your Effectiveness ~ Solving Other People's Problems by Don Gray.

Monday, 20 August 2018

D, E, F’s of Software Testing

DATA, EVIDENCE, and FACTS.

D for Data
Data Testing - Do extensive testing of the input and output data and provide coverage in terms of the below. 

Test:
For its legal usage and infringement of the right to data privacy. What data can be used and when and who can use it and why?
Test the data - how is data collected, stored/saved, transmitted, used and disposed of.
Test the data - for correctness and reliability. Not everything on the Internet is from a trusted source.
Test the input data - for idiosyncratic patterns.
Test the output data - if it's spewing out relevant output for the input fed.
Test the data - input fields for the invisible forces attacking them.
Test the data - for who prepared it, who is the end user, are they the authorized end user, where did we get the data from, where are we storing it, how are we storing it, how better can we store  it, how securely can we store it, how else can we use it, how legitimate the data in transit is, how do we distribute it across systems, third party and otherwise, are the users aware of how their personal/valuable information is stored and used, who/which tool generated the input data, is this tool licensed, how is the data generated, who are the makers of this tool, who else can access the data and how is the data disposed of.
Test the data - for its quality.

The question for us to think about here is:
Why are we collecting this data from a user?
Answering this question can help in solution-ing the software for apt usage and can help reduce the cost incurred in designing, implementing, testing and when the solution is released to the users.


E for Evidence
Evidence collection of the testing performed is of utmost importance to testing. It is also significant to understand the value-addition of testing evidence produced and provided to the client.

Testers need to be trained to use tools to capture and produce evidence. From the project initiation phase to completion and beyond, evidence of the testing done, coverage provided, scope altered, tools used, checklists filled are filed by testers for the consumption of an end-user. The test lead needs to ensure that the test evidence is easily accessible to the consumer (for the client) and in time.

Be punctilious of the testing approaches you learn and use, as it creates value. Including the context-driven test approach which sets up the tester to form and base the testing by cautiously understanding the context. Failing to state the context prior to performing testing and during execution, can set the product up to have lousy quality.

With evidence collection, the testers learn the fine distinction between testing and providing proof. Without which, testing is deemed valueless.

The question for us to think about here is: 
What steps you take or have taken to gather evidence?

F for Fact
Lest we forget the value addition of the reviews, root cause analysis of the bugs which reveal that lack of fact-checking can be fateful to any project.

Testers as fact checkers can ultimately lead them to be and become better quality contributors.

Fact checking as part of testing can trigger a tester to be hawk-eyed during the whole process and make one quality conscious. 

Fact-check:
The statement of work
Collated product and testing requirements
Use cases referred and used
User stories created and suspended
Agreed user acceptance criteria
Test ideas, charters designed for execution with valid and invalid inputs
Product understanding and bug review
Test reports and graphs generated
Risks encountered and mitigation planned
Experience and closure reports

The side effect of doing this helps a tester to better time track the testing activities one is involved with. And raise relevant questions related to estimation which is a faux-pas when planning for testing is considered.

All of the testing related activities needs to be fact checked for. Testers, practice checking for facts before filing a bug or sending out a test report. Tester vocabulary used when testing and not testing plays a prime role in doing so.

The question for you here is:
Dear testers, have you fact checked today?

Wednesday, 1 August 2018

Understanding The Context

Establishing the context is essential when conversing, writing and especially when testing.

Reasons why establishing the context prior to testing can be missed out:
  • Ignorant or Unaware –Testers/Leaders are not yet aware of the science behind establishing a context.
  • Code and test enthusiasts hastening to verify and validate the product against set requirements.
  • By not encouraging the idea of questioning at every stage of software development, one could dampen the outcome of testing. Relevant and well-timed questioning leads to challenging the status quo and learn new dimensions and the changing contexts that are akin to testing. 
  • Change in requirements requires a change in context, which is seldom accommodated in ardent and uncompromising work cultures.

The above scenarios can occur in instances when:
  • The team has not set clear team and individual objectives prior to testing.
  • The code delivered to be tested is delayed and has passed the test execution start date. 
  • When the manager is pushing for testing to be completed and delivered at the earliest. 
  • Every member of the team wants to be in the good books of everyone else and is not asking lost time to test.
  • There is a mentor missing whose guidance can help in fire-fighting.


What is the context?

*Context - The set of facts or circumstances that surround a situation or an event. 
*Definition via the WordWeb.


De-constructing Context
  • Making sense of the system under test is itself the beginning of testing and is the first step in knowing the system.
  • Understanding the circumstances that surround a situation or an event - In this context, the system under test is needed to be understood in the environment it operates in, in order to test the system in an interactive mode.


Why is it important to establish the context when testing?

It is required in order to construct solutions for testing problems and to understand the system’s isolated and interactive behavior. 

Testing is to learn and to know the system under test.
I would like to suggest further reading of Chapter 1 from the book ‘An Introduction to General Systems Thinking’ authored by Gerald Marvin Weinberg to understand, to know, to extend, to limit the learning/testing and how far we can/need to go when subjecting the system under test to contextual mode.


An analogy
Recently, I was asked to prepare interview questions on logical reasoning and this request came as a 1 liner. I went ahead without questioning (or establishing the context) and spent a considerable amount of time defining, redefining, learning about questions, various types, and modes of questioning and learned the definition of logic, reasoning, facts, ways of thinking, asking and framing questions. Found various online resources to learn about questioning and interviews and I finally submitted the 20 questions that I prepared with some original questions in the list.
It was only later and when I asked for a review did I learn that since the context was missing in the written communication(the e-mail request sent) the effort was rendered waste, however original. The email clearly lacked the information that was required about the context and I had assumed the context of my current understanding and this whole effort was rendered a waste of valuable time for all involved.

Key Takeaways
  • Do not hesitate to ask relevant questions.
  • Establish context whenever needed.
  • This tweet from JeanAnn Harrison sums up the other lesson learned.





Optional reading

http://www.testthisblog.com/2008/10/i-got-tested-by-James-bach.html
http://roadlesstested.com/2013/07/13/3-practical-takeaways-from-playing-the-dice-game/
http://www.bettertesting.co.uk/content/?p=438