There will always be a job for you , if,

Stop sweating over whether <insert latest tech trend> will take your job away, rather focus on getting better @

  1. Learning new tools and practices with curiosity
  2. Putting Team outcomes before individual outcomes
  3. Sharing your knowledge
  4. Improving your facilitation skills
  5. Improving your public speaking
  6. Learning to build persuasive  business cases
  7. Writing code every day
  8. Volunteering in fields other than yours
  9. Finding mentors from fields other than yours
  10. Giving, taking and actioning feedback

Image source – Quora

Failure is good, it is an actual option, take it

https://en.wikipedia.org/wiki/The_Persistence_of_Memory#/media/File:The_Persistence_of_Memory.jpg

 

Since childhood (or the time when we were all artists) , we have been programmed to perceive failure as a non-viable option.

Something that needs to be avoided , dreaded and is socially unacceptable

“If you fail at <x> exam, you will end up being a failure in life” , constraints like this are slapped onto us.

As a result, failure becomes very closely knit with shame,guilt and inexplicable discomfort

Talking , atleast in a professional work environment context, these constraints not only influence the decisions we make  professionally but also dictate the narrative through which we articulate our achievements ( or side step risks that might lead to failures)

I “failed” recently, I made a significant emotional and physical investment in a career move . The career move did not work out , I ended up ( still am) being without a job within couple of months of that career move.

What have I learnt from this experience ?

  1.  The world will not end . It really does not .

Your kids will continue to be carefree and look upto you for being a role      model 

       Your father will continue to annoy you for remote IT support 

       The nature  and your direct environment will continue to be tumultuous  ,presenting you the same challenges as before with disregard of your current LinkedIn status

2. The world will change though

    Your career path will be foggier now 

    Your financial situation will present significant physical and mental stress 

    You will drop your kids in your jammies

    You will seek refuge in immediate relief ( in things ranging from alcohol, to taking up the first plausible employment opportunity)

You will feel that regret is your middle name

Because, we have been programmed to not fail .

Because, quitters never win

Because, it would look bad on my CV

Because , underneath all this,we allow ourselves and our successes to be “seen” through metrics that someone else created ,rather than us.

We stole those metrics and applied them to ourselves,our careers as if they were ours.

It is not only our prerogative but a life-duty ,to choose our own metrics of our success rather than be led by a third party yardstick.

Hence,time to choose the option of failing .

Hence,time to reflect and  ask if the world could matter in different ways ?

Which leads to my third learning ,

3. The world ,now, will matter in different ways

You will stop fearing venturing into professional and personal territories ( that you only had watched from the fringes) 

You will question your existing decision making parameters  and biases

  You will shun some of your existing metrics of success, might adopt couple new ones

   You will realize the irrationality of your fears 

You will strengthen existing professional and personal bonds

   You will  form new professional and personal bonds

 You will realize that the safeguards  or needs that you had constructed from being gainfully employed are faux or misconstrued

  and , most importantly

You will realize that you are only able to challenge your mindset or confront your fears or topple the apple cart of your beliefs, because for you ,the world is mattering in different ways now

It will continue to matter to you in further different ways throughout your life

You just need to continuously keep challenging your norms, keep refining what you define as success  and what you classify as failure or to even consider whether there is value in classifying at all !?

 

 

 

 

Testing != Automation

Automation is not the goal .

The goal(s) is to –

  • Make humans effective at the craft of discovering,communicating and advocating risks to user experience,commercial reputation and utility of what we ship.
  • Keep feedback loops to humans as short as possible
  • Provide information to humans that is reliable and consistent( to answer the question…”if we ship now, what are the risks to our customers’ existing experience and utility of our software ?”)
  • Reduce repetitive tasks ( repetitive i.e. following the same steps with the same data with the same intent to achieve the same objective done over and over during a work day), so that cognitive load on humans is lowered and creative intent is sustained

Automation is not just about a Tool set

Automation , before tools, is actually, about –

  • analysis of the architecture
  • change
  • communication
  • facilitation
  • workshopping
  • reflection
  • test data
  • test environments
  • shared understanding
  • business risks
  • business strategy
  • product roadmap
  • commercial significance
  • experiementation
  • probing techniques
  • not Automating everything
  • not dichotomous to “manual” Testing

 

Self assessment skills matrix for a Testing practice

During my stint as a Test Practice Lead last year, one of the key strategic initiative that I created and led was to assess and uplift skills and capability of the whole test practice.

The process that I employed to deliver on that initiative was –

  1. Create a framework for Testers in the practice to assess their skills against
  2. Gather data (through the framework)
  3. Analyze data and create top 3 areas of focus , for the Test Practice’s upskilling

In this post I am going to share my approach to achieve point # 1 above.

There were 3 key elements of my approach

  • Why do the testers need to assess their skills
  • What do they need to assess themselves against
  • What will be the levels of assessment

1. Why?

Starting with the “why” was absolutely critical in my mind , because I did not want to the Practice to feel insecure in terms of this being an appraisal or rating exercise. My narrative was built on the plank that this is essentially a data gathering exercise that will inform where we (as an organisation)  should invest in terms of upskilling our Testers.

I addressed the practice with the below rationale and it was taken very well (in terms of no push back received about the intent of the exercise)

2. Skill set(s) to be assessed against

The next step was to frame the various skills that the Testers will be rating themselves against. I wanted the practice to self-reflect against ( what I believe) are a set of skills that every “contemporary” Tester needs to posses to be effective in cross functional Teams (working in complex Tech and non-Tech organisations).

I captured the following technical and non-technical skills and tool sets for the practice to rate them selves against . This by no means is an exhaustive and a precise list , but my best judgement (based on my awareness and research) on where the Testing industry is at (and heading towards). This list should be taken with a pinch of context i.e. that the skill and tool set will need to be fine tuned based on the organisation ,product and technical circumstances.

Skill set # 1 –

“Core” (sapient) Testing skills

Skills set # 2 –

Tooling set to augment core testing skills above

Skills set # 3 –

Programming and scripting skills that enable a Tester to be wield tools (skill set # 2) effectively

Skills set # 4 –

Practicing knowledge and experience of methodologies

 

3. Levels of assessment

This was a tricky one to articulate objectively. I was keen on collecting data on folks who have explored some of the above skill sets as hobbyists ( a trait that I respect) while also differentiating from actual practitioner experience . I also wanted to track the skills that people were keen to learn ( and had been deprived of because of either no training being offered and/or lack of client opportunities)

So, ultimately I settled on the below categories for the Testers in the practice to rate themselves against.

The central assessment question became …

Are you a  Starter ?  a Learner ? a  Practitioner ? or a Champion ? for this skill set 

Is this a skill set that you want to grow in ?

Putting it all together –

Here is a copy of the mind map that collates everything in one place. This is what the whole Practice filled and assessed themselves against. .

Hope this helps other Test Leaders in collating skills data for their Teams or Practice to make informed decisions on where the training focus should be

 

 

 

 

 

 

 

“Testing is slowing us down” , moving from blame to involvement and engagement

“It is Testing that is really slowing the Project down”

“Why are we finding all these bugs, so late in the Project”

“Testers must be testing edge cases to death”

I dont know of many experienced Testers who haven’t heard  some or all of the above statements before .

I heard it again yesterday and that set off a bomb of creative rage that has inspired me to write this post.

This post collates my experiences on what typically ,the root cause turns out to be (when Business/PMO folks perceive that Testing is slowing down things)  and tactics that I have advocated/employed to change the narrative

What it could actually be – 

  • That the Project estimates did not take cognizance of Testing risks when planning the Project schedule
  • That the Project plan trivialized the Integration work with 3rd party components
  • That some of the risks are actually materializing and the schedule needs to be inspected and adapted
  • That Testers and Dev Team dont work in a cross-functional structure
  • That even in a cross-functional structure , Developers dont help with Testing bottlenecks ( and rather pick the next Dev item from the backlog)
  • That your code base is reeling from tech debt
  • That you dont measure tech debt (and mistake tech debt related bugs/constraints as “slow” Testing)
  • That you dont have automated tests to detect timely regression
  • That you compromise automated testing coverage over stability
  • That you have dependencies on IT Ops to complete your Definition of Done
  • That your Developers only take ownership of the Dev part of Definition of Done
  • That Testers are not allowed to directly talk to SMEs/end-users
  • That Testers can not articulate their Test approach ( to non-tech folks in the Project)

How could this be changed ?

The narrative needs to move from “blame” to “invovlement”

Have the Testers’ skin in the game in activities that they usually are not involved in ,listen to their feedback and support them to achieve their ideas

Involve Testers (more) in –

  • Discussions on choosing a vendor
  • Discussions on choosing a solution
  • Discussions on designing the solution architecture
  • Managing Test environments
  • Testing in Production ( yeah, this is actually a useful thing depending on the context)
  • Scoping a Project schedule
  • Talking directly to end-users
  • Challenging responsibilities for Test Automation in the Team
  • Determining code standards for the Team
  • Technical design reviews

Engage with Testers (more) on –

  • Designing Tests
  • Eliciting their Test approach and coverage
  • Reviewing Automated Test code
  • Observing their Test approach
  • Eliciting how could Testing could be made better
  • Taking joint ownership of quality
  • Supporting them to uphold quality standards of the Test process

 

An alt-technique for hiring Testers for Team fit

Which tactics do you usually employ to interview and identify great Testers ?

Alignment with Team/Company values ?

Evidence of critical thinking ? 

How did you approach <x…..testing problem> type of questions ?

Examples of application of Tooling knowledge ? 

How much value do they give to sapient skills in Testing ?

Community references ? 

Thought pieces or talks ? 

Track record of mentoring upcoming Testers ?

One technique  that I realized that I have never explicitly used , is peer review of my work during an interview. On the lines of code reviews in Developer interviews

 

Talking about my approach to choosing a Test technique or a Tool  and asking the candidate to provide feedback on the choice and my approach ?

How about bringing  my Test strategy along and getting them to review it ?  Observing their questioning and critiquing techniques ? How do they provide feedback ?  Observe their system thinking skills ?

How about white boarding my approach to risk assessment and ascertaining the level of Regression Testing required and getting them to review it ? What risks do they see with the approach ? Where could it be made better ? Will they do it differently and if yes,how do they convince me about it ? Can they be candid and respectful at the same time ?

I am hopeful that this exercise will provide me insights into the candidate’s –

  • Ability to asking probing questions and work in a Team
  • Intellectual humility and respect for a peer’s work ( especially when it might not be upto their personal standard)
  • Persuasion skills and ability to influence without authority

Have you tried peer review as an interview tool before ?

How was your experience ?

What was good and not so good about it ?

 

 

 

 

 

 

Organisational structure –> The sweet spot of decision making

Why is it so hard to get right and timely decisions in organisations ?

Because organisations are lop-sided with either ::

A) Folks who have the knowledge, insights,access,decision making authority to make those decisions but dont follow that through with a bias towards action or build credibility through execution

Or

B) Folks who really want to fix things, are opinionated on how to do it , have the passion to make change but are not enabled with access,authority,trust to the knowledge,resources and people required to take action

The fundamental duty of organisational leaders is

  • To fine tune their organisational structure in such way that as many as possible people fall structurally in C .
  • To empower,coach and shepherd people from (A-B) & (B-A) to transition to C.

 

 

 

So, you want to be a Test Tooling expert ?

“Hey, I am starting out as a Tester, how can I start learning Selenium ?”

Is the most common question newbie Grad Testers or relatively inexperienced Testers , who aspire to head down the “technical tester” “automator” path , ask. This is a question that I asked as well early on in my career with minimal context around some of the core concepts of taking an automated approach to Testing.

My endeavor as a mentor/coach now is to obviously not to combat this question directly 🙂 , and rather get my mentees/coachees to self-reflect on another set of questions so that they….

  • Focus first on understanding and practicing  their core Testing capabilities ( agnostic of  a tool set )
  • Understand the limitations, cost vs benefits of Automation
  • Do not undermine the analytical,system thinking and sapient skills that are required to deliver effective and valuable Test Automation solutions

I have put together a list of FAQs (as a mindmap below) that each Tester must reflect on and learn before heading down the path of becoming a Test Tooling/Automation expert.

My coaching philosophy is that one must first understand how and what to test before learning what to test with ?

 

P.S. – The mindmap is best viewed by saving the file locally and zooming in , thank you 🙂

Continuing the “Better Leadership” meet up

I facilitated another “Better Leadership” meet up last week , that I started a month or so ago , based on an unconference style , mob learning format ( versus a single speaker and an audience format) .

The format is simple, every attendee brings one Leadership experience/achievement to share (How did I achieve<………>?) and one Leadership challenge that they are currently facing (How can I solve <…….> ? )

And then we dot vote on topics and go around the group to enable fellow Leaders to share their stories

There is no bar of Leadership experience required to attend , from the turnout so far we have an even mix of experienced and aspiring Leaders.

Here are some of my key takeaways from the Meetup on 16th of August

The How can I solve <………….> theme ?

How can I drive accountability with a peer who consistently over promise but under deliver ?

Context –

“My cofounder are unfortunately not delivering to their potential , they are consistently letting the rest of the founding Team down by not delivering on their commitments, how do I confront them on this (ensuring that the working relationship is not impacted)”

Suggestions from the group –

— Set clear expectations on outcomes that each of you (within the founding Team) are accoutable to deliver . Forming a charter of behaviors and values through which everyone will deliver on their comittments

— Provide “impact feedback” to them i.e. 1:1 describe the impact of them not delivering on their commitments has on you as their peer e.g. it demotivates you , brings the Team down, risks the goal that your start up is supposed to achieve

— If the above does not work , dont hold back from asking them to leave the Team , as you only get one shot at making your start up successful and with such a small founding Team everyone needs to have skin in the game

How can I keep my Team motivated in times of prolonged BAU work

Context –

“Our company has gone through an extremely busy phase where we released a major product release earlier this year. Now as the product is already in market, my Team is only working on minor bug fixes and support work. This has recently started impacting the morale of the Team in terms not getting exciting pieces of work, how can I sustain the motivation of my Team during this phase”

 Suggestions from the group –

— Encourage the Team to look for side projects that could benefit the Team e.g. automating your regression tests or paying off your technical debt

— Look for opportunities for your Team members to be temporarily seconded to other functions (e.g. Customer support , Marketing , BA etc) so that they can pick up new insight,skills and develop empathy for other Teams

— The might not necessarily be a one-off phase of lull . analyze the root cause of why your feature pipeline has dried up ? Are there any areas of concern in communication between you & the Product Owners ? Do you as an organisation have a Product road map ? Are you guys following that road map ? Are your POs siloed from the Team ?

The How did I solve <………….> theme ?

How did I lead the Team to move away from Scrum

Context  & story –

Irrespective of how much grooming and prioritization we did , invariably the PO used to disrupt our sprint due to unavoidable changes in priority or customer direction. This was proving to be demotivating and disruptive to be the Team. I facilitated a move away from hard-core Scrum principles of fixed duration sprints and planning cadence, by adopting a more Kanban-esque approach wherein now –

  • We dont have fixed sprint iterations , we plan as & when needed
  • We have weekly cycles of release
  • Once the Team completes something they just pick up the next available item from the groomed and prioritized backlog (and run a planning session only if required)

Sharing our Test practice charter , the North Star for our internal community

One of the “hats” that I wear internally at my current company is the role of a Test Service Lead . The main responsibility of this role is to serve the practice and ensure that the internal Test Practice ( we are a consultancy and dont have  fixed Teams) gels together and flourishes as a community.

The first thing that I proposed we do , when I took up the role , was to have a Team charter . A constitution so to speak that guides the community on the values that we are operate on , the behaviors that we encourage and the outcomes that we are aspiring to achieve.

We had couple of our senior Agile consultants facilitate the charter forming session and I was fortunate enough to have the opportunity to scribe it into a diagram.

Please have a view and leave your thoughts, feedback and own experiences on creating/using Team charters in comments below .