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 links to the posts for this book-

Chapter-1

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!

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