My experience speaking at Testbash Home

The Ministry of Testing (MoT) is definitely the biggest and the most supportive testing community. Having heard so much about their Testbash events conducted world-wide, speaking at one was a long time goal. And I was fortunate enough to be accepted to speak at Testbash Detroit this year. But as things progressed since the beginning of 2020, travels and conferences of any kind were far from possible in light of a the global pandemic of Covid-19. Alas! our dreams were shattered. And though, it was disheartening for sure, the awesome community jumped back from the jolt and got together to bring us all an awesome online event #Testbash Home 2020.

Preparations began and I too got back to preparing my talk, which I had given up on after the cancellations! Took a couple of weekends sorting out the content and slides. Then we had a call to record the talks with the community members Heather and Diana were ever so supportive and so kind with their emails, scheduling and feedback! This was a wonderful idea to have the talks pre-recorded so that we are not hampered by any technical glitches on the event day, while we speakers get to focus on engaging with everyone and answering questions from the community.

As the day of the event approached, I prepared for my live interview. The event had more than 1000 registrations! Definitely making it the biggest audience I have ever presented to. Though the event began late night hours for my timezone, my talk was at a convenient morning hour. So that is when I joined in. Had a wonderful chat with Richard who was the Backstage boss and handling the entire livestream for the entire 24 hours! Checked on my audio & video etc and also had introductions with James who was the host for that part. And then we were live!

The duration of the talk went great. It was surreal listening to myself presenting, and looking at the live chat and questions coming from the participants throughout the talk. Once it ended, I was back live with my video. Me and James continued to discuss the most popular voted questions asked and I answered them the best to my knowledge. It was amazing to see such great comments and kind appreciation by the listeners in the chats once we were done. #Grateful

Once my talk was done, I could now continue to enjoy the rest of the live event! #Testbash Home was an absolute treat with a mix of great content, discussions, community participation, fun hosts and great conversations! It sure has set the bar really high for all online events in the future. I stayed throughout the next 5 parts of the event and only left late at night when it was absolutely impossible to keep my eyes open 😛

It sure felt like a day away from our regular stay-at-home lives, and felt like we had met up with so many people in the virtual world. Some key highlights of the day were-

  • Awesome talks by speakers
  • Black Box puzzles played live with volunteers
  • 99 second talks with many enthusiastic participants, many of whom were presenting for the first time!
  • The breakout room was so much fun – where you could select your avatar, enter a virtual room and just chit chat (and play with Ralph the dogBoss 😛 )
  • The breaks in-between parts had the background noise of an actual conference hall with people chattering and plates clanking. It was so soothing to hear (given the times we are in!) A fantastic idea! 🙂
  • The hosts did an awesome job engaging everyone in informal chats, yoga, discussing shows we are watching, things we are cooking and what not. Considering that it was a 24 hour long event, it sure was a welcome change of pace every few hours.
  • The short intros of all the MoT community bosses was so much fun to watch and made it very relatable. Now we know the faces behind the names.

Overall, TestBash home was an awesome experience, and I was fortunate to get some great feedback for my first ever Testbash Talk! I also loved the sketch-note of my talk created by Louise Gibbs

Sketch note Created by Louise Gibbs

I look forward to taking it further and engaging with this community in a live Testbash event some day! 🙂

Cheers

Nishi

I am speaking at TestBash Home 2020

When life gives you lemons, make lemonade! None better example of this than the zingy, sweet lemonade under preparation by this awesome community at @Ministry Of Testing , bringing the ‘testing’ flavors of the entire world right to your home!

Despite cancellations of a number of events due to the ongoing pandemic, this community has come back together to create an amazing online event. I am super excited to be speaking at TestBash Home 2020 – the first online software testing conference by Ministry Of Testing. It will begin on the 30th of April 2020 and run for a full 24 hours into the 1st of May 2020, traveling all timezones so that everyone in our truly global testing community can get involved. 

I am honored to be a part of such an awesome line-up of speakers. These hours are going to be packed full of interactive sessions including talks, panels, challenges, plus we’ll relive and reflect on some classic TestBash talks.

Speakers List – TestBash Home 2020

The agenda is live now-

Checkout more details about the event and schedule here –https://www.ministryoftesting.com/events/testbash-home-2020

Follow the updates on Twitter—

Register now for loads of fun and learning and engaging with a worldwide community of testers right from your home!

Cheers

Nishi

Read Along- ‘Agile Testing’ Chapter-4

“Team Logistics”

  • Testers on agile teams feel very strongly about their role as customer advocate and also feel they can influence the rest of the team with their quality thinking.
  • Testers also need training on pair testing, working with incomplete and changing requirements, automation and all of the other new skills that are required.
  • Programmers also might need coaching to understand the importance of business-facing tests and the whole-team approach to writing and automating tests.
  • The pairing of programmers and testers can only improve communication about the quality of the product.

“One major advantage of an integrated project team is that there’s only one budget and one schedule.”

The difference between a traditional cross-functional team and an agile team is the approach to the whole-team effort. Members are not just “representing” their functions in the team but are becoming true members of the team for as long as the project or permanent team exists.

  • The best teams are those that have learned to work together and have developed trust with one another.
  • Teams work better when they have ready access to all team members, easy visibility of all progress charts and an environment that fosters communication.
  • Teams make the best progress when they’re empowered to identify and solve their own problems. If you’re a manager, resist the temptation to impose all your good ideas on the team.
  • Make sure testers are involved in all meetings! If you are a tester and someone forgets to invite you to a meeting, invite yourself!

“Courage is especially important. Get up and go talk to people; ask how you can help. Reach out to team members and other teams for direct communication. Notice impediments ad ask the team to help remove them.”

Agile development works because it gets obstacles out of our path and lets us do our best work.

——- On to the next one!

Cheers

Nishi

Read Along- ‘Agile Testing’ Chapter-2

“The Principles for agile testers”

Points to remember and Quotable Quotes

Definition of Agile Tester-

“A professional tester who embraces change, collaborates well with both technical and businesspeople, and understands the concept of using tests to document requirements and drive development.”

  • Skills are important, but attitude counts more
  • An agile tester does not see herself as a quality police officer, protecting her customers from inadequate code.
  • Agile testers don’t limit themselves to solving only testing issues.
  • Creativity, openness to ideas, willingness to take on any task or role, focus on the customer and a constant view of the big picture – are some components of the agile testing mindset.
  • A team that guides itself with agile values and principles will have higher team morale and better velocity than a poorly functioning team of talented individuals.
  • The principles important for agile testers are –
    • Provide continuous feedback
    • Deliver value to customer
    • Enable face-to-face communication
    • Have courage
    • Keep it Simple
    • Practice continuous improvement
    • Respond to change
    • Self-organize
    • Focus on people
    • Enjoy
  • AATD “Agile Attention Deficit Disorder” – Anything not learned quickly might be deemed useless!
  • Automating tests is hard, but it is much easier when you have the whole team working together.
  • Agile development rewards the agile tester’s passion for her work!

I had written an article about differences between Agile and Traditional testing approaches a few years back. Though I had not read this book at the time, I now feel how many of the points were similar and resonate the same even now. You can read my article here – https://testwithnishi.com/2016/10/20/5-ways-agile-testing-is-different-from-traditional-testing/

***Update **About face-to-face communication** during Covid-19 ***

As I am reading this book during this bizarre time of social-distancing, working remotely and entire nations on lockdown, the part about ‘face-to-face’ communication has a new meaning now. As Janet Gregory also pointed out in response to this article, our definition of face-to-face has changed over the last few weeks over the entire world! We are lucky to have technology that helps us continue effective communication within our teams, have conversations, video calls, screen shares, continue learning over webinars and continue working, feeling useful and being productive.

Hoping things change soon and we can go back to having fun, productive discussions with our team mates over coffee. Until then — Happy social distancing!

*************

Read Along- ‘Agile Testing’ Chapter-1

“What is Agile Testing, Anyway?”

Points to remember and Quotable Quotes:

  • “Several core practices used by agile teams relate to testing.”
    • Programmers using TDD, code integration tests being written contribute to a successful project.
  • “Agile Testing just doesn’t mean testing on an agile project.”
    • Some testing approaches like exploratory testing are inherently agile, whether done in an agile project or not.
  • Testers are integral members of the customer team as well as development team
  • The best part of this chapter is Lisa and Janet’s wonderful stories on beginning with their first agile projects, and a realization by Janet’s co-worker, a developer in a team following XP on how they saw Janet’s contribution to the project.
  • “Testers don’t sit & wait for work; they get up and look for ways to contribute throughout the development cycle and beyond.”
  • Traditional vs Agile Testing
    • In Traditional approach – “Testing gets “squished” because coding takes longer than expected, and because teams get into a code-and-fix cycle at the end.
    • In Agile – “As an agile team member, you will need to be adaptive to the team’s needs
    • “Participants, tests, and tools need to be adaptive.”
  • “An Agile team is a wonderful place to be a tester”
  • The Whole-Team Approach –
    • “Everyone on an agile team gets “test-infected.”
    • “An agile team must possess all the skills needed to produce quality code that delivers the features required by the organization.”
    • “The whole team approach involves constant collaboration”
    • “On an agile team, anyone can ask for and receive help”
  • “The fact is, it’s all about quality – and if it’s not, we question whether it’s really an ‘agile’ team.”

Wanna Read along? Get your copy of the book at

https://www.flipkart.com/agile-testing/p/itmdytt85fzashud?pid=9788131730683

OR find a paperback or ebook version!

Read Along- ‘Agile Testing’ by Lisa Crispin & Janet Gregory

Book Read Blogs Series

I used to love books, reading was a fun and satisfying hobby for the introverted teen I was. But lately I may have gotten away from it for known and unknown reasons. I want to pursue the passion again and hold myself accountable too. So, this year I am starting a ‘Read Along’ series on my blog.

“Agile Testing” by Lisa Crispin & Janet Gregory

I will begin by reading the book I had bought last year. “Agile Testing” by Lisa & Janet is a coveted read for all agile enthusiasts & testers and is also featured in the best books for testers at https://continuoustesting.blog/2020/01/17/most-recommended-software-testing-books-to-read-in-2020-and-beyond/

I have learnt agile testing by doing it, learning it hands-on, training & running courses on agile testing for professionals. I wanted to enhance my knowledge by reading the professional work by these awesome ladies.

So, I will be reading the book and will post about learnings, things to remember & quotable quotes from each chapter as I progress. This is to hold myself accountable, as well as to help people looking for good reads or learnings. Hope this helps you. Have you read this book? Do share your thoughts & learnings too!

Here are the links to the Chapter-wise posts for this book-

Chapter-1 What is Agile Testing Anyway

Chapter-2 The Principles for Agile Testers

Chapter-3 Cultural Challenges

Chapter-4 Team Logistics

Chapter-5 Transitioning Typical Processes

Chapter-6. The purpose of Testing

Chapter-7 Technology Facing Tests that support the team

Chapter-8 Business Facing Tests that support the team

Chapter-9 Toolkit for Business facing tests that support the team

Chapter-10 Business facing tests that Critique the product

Chapter-11 Critiquing the product using Technology facing tests

Chapter-12 Summary of Testing Quadrants

Chapter-13 Why we want to automate tests and what holds us back?

Chapter-14 An Agile Test Automation Strategy

Chapter-15 An Iteration in the Life of a Tester

Chapter-16 Hit the Ground Running

Chapter-17 Iteration Kickoff

Chapter-18 Coding & Testing

Chapter-19 Wrap up the Iteration

Chapter-20 Successful Delivery

Chapter-21 Key Success Factors

Hope this Read Along Series offers some meaningful insights into this wonderful book and some quick pointers for those looking to get started or get more proficient in their agile testing ways!

Happy Testing!

Nishi

The Art of Bug Advocacy

Testers find defects and raise awareness about quality. What happens after the bugs are found can be any tester’s guess, though. Bugs may get delayed, postponed, go unnoticed or linger on due to lack of information.

In my article for Ranorex blog, I talk about how Testers need to champion the cause of their bugs in order to avoid unneeded delays in fixing defects that are important. At the same time, testers should maintain a distance to make it an impersonal and impartial experience. Testers need to master the art of bug advocacy!

Why is advocacy important?

Advocacy is basically pleading the case for a bug to be fixed. The testers who find the bugs are the ones who need to advocate for their bugs. It is important that they take a stand and voice their opinions.

Some bugs may not be deemed important from a business perspective, as they seem too small. But in reality, they may be blocking an important feature for a particular user group. On the other hand, some bugs may seem more critical than they truly are, and while fixing them may be important, it may not be the highest of priority.

Whatever the case, testers must aim to present the facts and data in such a way that decision-makers are able to make well-informed resolutions about the issue.

Communication is key

Advocating for anything is not a one-way street. It takes discussion, debate and reaching a consensus on key points to make a collective decision. This is where testers’ communication skill plays a key role. Testers need to have good communication, both verbal and written.

Read More »

Upcoming Talks and Events 2020

The year 2020 has started on a good note. I am excited to have been invited to speak at amazing events. Here is a list of my upcoming talks and events–

The details of each of these events and my talks can be found at their respective websites at->

Selenium Day : https://seleniumday.com/

DevopsCon Singapore: https://devopscon.io/singapore/program-singapore/

TestBash Detroit: https://www.ministryoftesting.com/events/testbash-detroit-2020

Looking forward to each of these!

*********UPDATE********

Things changes drastically as 2020 progressed.

Events have been postponsed / cancelled / moved online due to lockdowns due to COVID-19 Pandemic

You will find new details of the events , schedule and my talks in later posts.

**************************

Defining Exit Criteria for different phases of your Agile project

Exit criteria are a list of items to check off that define the end of any activity. Exit criteria can be defined for any activity you want to undertake: You can have exit criteria for cooking veggies to the desired doneness, or for a city tour to be sure you see all the sights, or for a meeting to assign action items for everyone! Exit criteria are helpful to tell you (and others involved) when to stop the activity. Specifically, for an agile project, having clear and concise exit criteria makes it easier to understand the scope and avoid going overboard while keeping a tab on your quality. 

In my article published at Gurock https://blog.gurock.com/agile-exit-criteria/ , I have discussed some ways to structure your exit criteria at the sprint, user story, and task levels in an agile project.

The first rule for exit criteria is to have them defined up front, before beginning the activity.

For an agile project, let’s say we want to have exit criteria in place for the end of the sprint. We will need to work on defining them at the beginning of the sprint, or at the release-planning stage. Once the activity begins, the goal is to achieve all exit criteria by the end. We cannot have people defining or changing the planned exit criteria during execution of the activity, since that will not be upholding the quality standards set in the beginning.

The second rule is to have standard exit criteria for all similar activities. So, exit criteria defined for the sprint level apply to all sprints in that release, and exit criteria defined for the user story level apply to all user stories in all sprints. This upholds the same standard of quality and expectation of work required for each of these work units.

In the article, I have discussed sample Exit Criteria for Sprint, User Story or Task level and also shown how to create your own exit criteria based on your project’s and team’s context.

The important things to focus on are having the exit criteria defined up front and ensuring follow-through by sticking to the criteria throughout your release cycle. Being consistent with checking off everything on your exit criteria list ensures a smooth flow of high-quality work.

Check out the complete article here – >

Metrics your Agile team should & should not be tracking!

Agile teams are constantly running toward goals, requiring constant planning, monitoring, and re-planning. Metrics can help support these efforts by providing useful information about the health and progress of the project.

There are a few common metrics we use in agile teams: sprint burndown charts, release burnup charts, team velocity. They’re common because they communicate practical information, but they’re not the only metrics we can employ.

In my recent articles for TestRail blog, I described 3 Uncommon metrics you can easily create that will be very useful for your agile team. I also wrote about 3 Metrics that are not useful and you must stop using now!

Here are the posts–>

Three Uncommon Metrics Your Agile Team Should Be Tracking

Here I described 3 most useful metrics –

Defect Health

Defect Health Chart

Test Progress

Metric for weekly test progress

Build Failures

Sprint-wise metric for No of Build Failures

Click here to read the complete article —>

Three Metrics Your Agile Team Should Stop Using

Metrics are supposed to help and support an agile team by providing useful information about the health and progress of their project. But not all metrics are always beneficial. Going overboard with them can sometimes cause more harm than good.

In this post I have described three metrics that can impede your agile team instead of motivating you.

  • Defect Counts
  • Hours
  • Lines of Code or Defect Fixes per Developer

Click here to read the complete article–>

Please share your experiences with metrics and how they helped or impeded your progress!

Cheers

Nishi