TestToTester

We were in the middle of a release. It was late and we had just found a bug, a show stopper for a feature. Ben then said I always wonder - what separates a good tester from an average tester? at most times I feel it's their ability to spot the important bugs at the right time.  These words have struck with me ever since. And this happened at another site. I observed "attack-name": "HEADER_COUNT_EXCEEDED" in an API response when I used postman to poke some of the APIs built. The error was not consistent but I just did not feel right about this. Checked with the team (lets call them teamA) testing the APIs and it appears they had never seen it before. So I checked with another team (lets call this teamB) who were consuming the APIs but building something different. It was the same response. I was aware that both teams used J-meter to test APIs and I was poking it via postman. Could that be a problem? I built a small collection to iterate the API ca...

I found Hypothesis library very intriguing so have started exploring it.  Here are my notes from the first hypothesis exploratory session What is Hypothesis? From their webpage - Hypothesis is a Python library for creating unit tests which are simpler to write and more powerful when run, finding edge cases in your code you wouldn’t have thought to look for. It is stable, powerful and easy to add to any existing test suite. You can read more about it and its claims here -> https://hypothesis.readthedocs.io/en/latest/index.html I am definitely not a fan of tall claims like - "finding edge cases in your code you wouldn’t have thought to look for"! Anyways I will come to that later on. For now I wanted to explore its ability to add to any existing test suite. So I picked pytest What is pytest? Again from their webpage - The pytest framework makes it easy to write small tests, yet scales to support complex functional testing for applications and libraries. More her...

I get extremely irritated when people ask me the toolset I use to test without trying to understand/learn what I am testing and how I intend to use a specific tool. My choice of tool and how I use it very much depends on the testing objective and the context. Below is one such example when I used  Bug Magnet , a chrome/firefox extension to test APIs. Test objective/mission:  Explore the email field added to the JSON payload. I started off the test session with a 5 min brainstorming. I mostly use mind map for this. what regex is used in the code? what inputs can break it? what inputs are business critical? response code when it fails? 400? error message returned on failure? min/max length? multiple email addresses? duplicates? does it matter? do we care if it is a *valid/fake email address?  what about domains such as mailinator? (Context:) Given we are not going gung-ho on validation. What could be useful at this moment? From the brainstorming sess...

Recently, I was not happy with the bug reports on one of my team. The title was generic, there was little or too much information in its description, logs, response was not formatted and the attachments at times made very little sense. My initial thought was to forward 'how to write good bug reports' blog links from the web but something in me did not wanted me to do it. They explored well and the bugs they found were very good. Also, I did not feel a meeting or a workshop targeting only bug writing skills would have the right impact on this team. So instead of direct coaching or sharing blog links I started to reproduce the bugs locally and started editing the bug title/description/code format/attachments, etc in the bug reports. I did not mention anything to the team. After couple of weeks I started noticing a change. The bug reports got better! The title was appropriate, description much improved, code well formatted with screen shots and there was also gifs in attac...

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

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

I have never bothered to write about this or talk about it because I sincerely feel there are enough papers explaining the benefits and drawbacks of each (Just look at the Test Automation?? widget on the blog). But for some reason this discussion keeps coming back in different forms L First it was the winrunners vs manual, and then came the QTP wave now it’s the web drivers, jasmine, cucumber/spec flows, etc etc.  vs manual? Really? It’s amazing how much test automation has moved on from bulky huge licensing structure into light weight, open source collaborative setup. The new set of tools are fantastic and business facing which we as testers always craved for. On the other end manual testing has moved on from writing/running bunch of lines of steps in QC, to planning, testing, learning and interpreting tests in exploratory sessions. Both at least to me have its merits, traps and limitations and I feel identifying and learning how to overcome them is what will...

Want to find out how AST BBST, an online course transformed me? or for that matter what any certification should try to achieve? Published on Testing Circus  http://www.testingcircus.com/how-bbst-transformed-me-as-a-tester/

Inspiration? The magic that transpired at   Skills Matter   on 23-Mar-2011 when   WeekNightTesting went LIVE   with   Markus Gaertner   facilitating from Hamburg,   LisaCrispin   from San Francisco and   Mike   and I from London has inspired us to take WeekNight Testing out of the chat app to LIVE testing sessions. How do we plan to do it? Testers meet at a common location in the evening at around 17:45 UK Time with their laptops and energy to test, question, learn, discuss about testing. At 18:00 the test session facilitator announces a testing challenge that is time boxed for an hour. Testers have the freedom to pair up with other testers or work on their own to meet the challenge. Testers can also use any test tools, strategies, and ideas to accomplish the challenge. At the end of the hour we take a 5 min break and jump into a discussion session (de-briefing) for the n...