ET. My Way

Here is the link to my talk 'ET. My Way' at the London Tester Gathering.

Using git ‘pull' ‘merge' principle to exploratory testing

I am a huge fan of git. I like its speed, ease of branching, offline capability, undo, and many many more features. But the one I love the most is its ability to bring the team together. I see it as an amazing collaboratory tool.

The ability to tag others in the team to review a pull request before it's merged into master by the reviewer is so simple yet so powerful. (a quick summary to those new to this approach - dev's create a new branch when they start working on a story, continuously update it, testers can pull code off this branch and test it to provide quick feedback and when the code is ready to be merged, the dev can tag members in the team to review the code and the reviewer can merge the branch to master if he\she is happy with the code)

We have extended this to feature files too. When we can't get hold of our product owners for a three amigos session. We raise a pull request with our scenarios and tag them for review. They add comments. We would work on the changes and eventually when the product owner and most of the team are happy the branch is merged to master.

So, how does any of this fit with exploratory testing? 

Our approach to testing is exploratory. We test in time bound sessions as in SBTM. The notes from test sessions get tagged to the specific jira stories. All sounds good?

Yes, but we strive on getting better and so with a bit of digging we realised that we do not pair much in test sessions and from what I have observed we do not de-brief test sessions.
To me, from my past experience interpretation of a test session is very important. This is when we learn from one another, share, challenge tests and is an enabler that makes the following test sessions better.

So how can we sort this with minimum overhead?

A proposal - What if we tag team members, to review the test session notes at the end of a session (similar to a git pull request). He/she can now do a debrief of the session or if physically cannot be present can review the session sheet, provide feedback, recommend tests or if happy with the session notes close the session (similar to a git merge)

I am hoping this simple, minor change can help us drive debriefs and bring the benefits with it. 

I will follow up with an update in couple of month’s time if this change helped us get better or not. In the meantime do let me know what you think of the idea.

How to build AWESOME Teams - Part 1

Attitude towards Quality

I love exploring and observing team dynamics. There are a lot of knowns and unknowns that affect it. Individual personalities, their roles, who sits next to who, how you communicate, office space, tools, technologies, company culture, processes and many more. All of it have an impact at different levels for different teams. There are no silver bullets, no best practises, no certifications that can guarantee an awesome team.

I guess I am one of the lucky few to have worked with not just one but many awesome teams. To me awesome teams are those who - do whatever it takes to get the task complete, are high in morale, self-organised, trust one another, have a sense of owning the product, display a bit of we-are-awesome and more importantly have loads of fun.

At my last client site I consciously observed and noted what traits in us set us different to others and one thing that stood out from rest of the teams in the company was our "attitude towards quality" of the product.

We as a team cared about quality all the time, backlog refinement with PO's, story kick-offs, during dev, pairing when we tested, we constantly kept an eye on crashlytics, logs, support beta channels, what interest groups say, etc

We hated defect tracking tools because it hid bugs, we made the bugs visible on our wall, we would never let the bug count grow more than 5, every bug we find in any stage would be discussed and appropriate action was taken rather than parking it to visit later.

Our testing strategy and attention to quality soon started paying dividends, PO's, users, analysts, and others in the company started noticing it. This also, set us apart from the rest. We were a proud bunch, we were keen to demo our features, any chance of pushing the build to production we would do it, we constantly pushed ourselves to get better.

So in case if you want your team to be awesome give this a try.

Encourage good quality. I understand quality does not come cheap. There will always be a temptation to deliver a new feature over fixing some bugs. I also, understand if managers reading this feel a bit uneasy about such teams and the investment towards quality. I get it but never tell the team that the quality of their work doesn't have to be awesome.

Without awesomeness you don't get awesome teams.

Staying agile

I love 'agile'. I think it's one of the best things ever happened to software delivery. Now before I proceed further -  to me 'agile' still is 

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Agile software development at least to me isn't scrum or kanban or safe or less or more or short or fast or pace or... I am open to any framework that fits the context and can adapt to change. 

Last week Friday one of our dev thought of a feature that could enhance the experience in our app (Friday Morning). The 6 of us in the team voted if we all found it useful. We recokend it could take us about 40 min to bring it to life. 
Friday afternoon we picked the stuff required to demo the feature in action. It did mean we had to eat katsu curry two day in a row. Build more stores Maplin. Over lunch built, tested, setup demo data and practised our secret gig. We were very careful to not share it on any channel not even a mention of it.
Friday evening demoed all our prioratised delivered cards from the board and followed it with our usual ... One more thing ....

Product owner and other senior members in the company now want to roll it out at the next event.

So did we do anything different? The way I see it - we stayed agile.

Get the basics right - management heuristic #1

Like all things ‘simple' not receiving its due. Here is the single most simple formula to build good teams.

  • Hire the right people
  • Uncage them
  • Keep them happy

I call it the Hire, Uncage, Keep - HUK heuristic

This is not new and is repeated in many books and blogposts but lost because ‘management’ cannot be that easy?

Make developers responsible for checking

This chapter Make developers responsible for checking from Fifty Quick Ideas to Improve Your Tests book is exactly how I feel about checking. 

Awesome book and a brilliant chapter.

Many thanks to the authors Gojko Adzic, David Evans and Tom Roden

Intermittent Bugs? make them visible

Next time when you come across those pesky intermittent bugs try adding them to a wall or a board instead of logging them in JIRA. The wall can be next to your standup wall or a separate wall. The key is to choose a space that will catch your teams attention. 

This can help...
  • notice a pattern with intermittent issues. You can then start grouping them under race conditions or corrupted data or specific state of the environment or performing tasks in a specific order, etc
  • team is constantly aware of the random problems and so any related or similar issue found could help in investigating the root cause
  • because the bugs are no longer hidden under a label in the bug database they have a higher probability of being fixed.

Test with me @