TestToTester

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

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.

" A picture is worth a thousand words" - well, who has not heard that before but as with most things simple we might not give it its due because it's easily understood.  In our team we have a pretty straight forward process to deal with bugs. I demo it to the dev, and add a sticky on the board for it to be fixed. Most of the time the fixes take priority, so we can move the stories across. It works well for our context. Today, when working from home I wanted to share a bug with my dev - list view loosing placeholder image data on scroll on android. I typed the steps to reproduce on slack and then followed it with the below image  The team loved it... ( Yea, you read that right! dev's loved the bug report ;) It was fun and made the point clear...  I bet it would look stunning on the kanban board compared to the long list of words on a sticky...

We have delivered over 20 builds to production in the last 12 months. (avg 15 stories per sprint) We have no show stoppers or major issues reported by end users. We have customised sprint + kanban to suit our team dynamics. We believe that a story is Done/Ready for sign-off when it's DEV + Test complete We pair up with Business for Story Kick-offs, grooming cards, demos, etc We pair up with Dev's for tech tasks, API tests & support/bug investigations We pair up with Dev Ops for infrastructure testing, build, deployment process We test functionality, integration, migration, UX, localisation, regression And YES We test most of our cards MANUALLY ( SBTM approach). to be continued...