TestToTester

I have always believed that testers should actively play a part on the left side of the scrum board in preventing defects and not just the right side of it where we find them. Gojko Adzic , one of my favourite agilist introduces 'TOO BIG' heuristic that can help us with that in his latest post. You can read the full post here https://gojko.net/2017/01/05/user-stories-too-big.html  I have created a mindmap [. PDF | . MUP | . MM ] of it for my reference. Hope you find it useful too.

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

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 wou...

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 towar...

source:twitter 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. O...

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 H ire, U ncage, K eep - HUK heuristic This is not new and is repeated in many books and blogposts but lost because ‘management’ cannot be that easy?

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