Read Along- ‘Agile Testing’ Chapter-19

“Wrap Up the Iteration”

  • Agile team delivers working software at the end of the iteration – demonstrate to the customers and get their feedback.
  • Having testers conduct the ’Iteration Review’ is a common practice as they’ve usually worked on all the stories. The Scrum Master, programmers or testers could demonstrate the new features – It is recommended to rotate this honor.
  • Retrospectives are an excellent place to start identifying what and how you can do better.
    • Start, Stop, Continue technique – Discussing What went well, What did not go well and what we can start doing to help.
    • Write task cards for actions to be undertaken to implement the steps
    • At the end of the next iteration, take a checkpoint to see if you improved

Retrospectives are a simple and highly effective way for teams to identify & address issues. The retrospective meeting is a perfect opportunity to raise testing-related issues. Bring up issues in an objective, non-blaming way.

Celebrate Successes

Make sure your team takes at least a little time to pat itself on the back and recognise its achievements.

Even Small Successes deserve a Reward.

Many agile teams have trouble taking time to celebrate success.

Have a weekly fun gathering or team games.

  • For big milestones such a big release or achieving a test coverage goal, the whole company can have a party to celebrate, bringing in catered food or go out.
  • It is also important to celebrate individual successes. A ‘Shout-Out Shoebox’ – is a great idea to recognize the value different team members contribute.
  • Taking time to celebrate successes lets your team take a step back, get a fresh perspective, and renew its energy so it can keep improving your product, giving team members a chance to appreciate each other’s contributions. Don’t fall into a routine where everyone has their head down working all the time!
  • Take advantage of the opportunity after each iteration to identify testing- related obstacles, and think of ways to overcome them.

Read Along- ‘Agile Testing’ Chapter-7

“Technology-Facing Tests that Support the Team”

A look at tests in Quadrant-1 – Technology Facing tests

Agile Testing Quadrants
  • Unit tests and component tests ensure quality by helping the programmers understand exactly what the code needs to do and providing guidance in the right design
  • The term ‘Test-Driven Development’ misleads practitioners who do not understand that its more about design than testing. Code developed test-first is naturally designed for Testability.
  • When teams practice TDD, they minimize the number of bugs that must be caught later.

The more bugs that leak out of our coding process, the slower our delivery will be, and in the end, it is the quality that will suffer. That’s why programmer tests in Quadrant-1 are so critical. A team without these core agile practices is unlikely to benefit much from agile values and principles.

  • Source Code Control, Configuration Management and Continuous Integration are essential to getting value from programmer tests that guide development.
  • CI saves time and motivates each programmer to run the tests before checking in the new code.
  • An advantage of driving development with tests is that code is written with the express intention of making tests pass.
  • A common approach in designing a testable architecture is to separate the different layers that perform different functions in the application.

Teams should take time to consider how they can take time to create an architecture that will make automated tests easier to create, inexpensive to maintain and long-lived. Don’t be afraid to revisit the architecture is automated tests don’t return value for the investment in them.

“The biggest value of unit tests is in the speed of their feedback.”

  • Each unit test is different and tests one dimension at a time
  • Learning to write Quadrant-1 tests is hard.
  • Because TDD is really more of a design activity, it is essential that the person writing the code also writes the tests, before writing the code.
  • To Managers—
    • If a delivery date is in jeopardy, push to reduce the scope, not the quality.
    • Give the team time to learn and provide expert, hands-on training.
  • Technology-facing tests cannot be done without the right tools and infrastructure

Read Along- ‘Agile Testing’ Chapter-5

“Transitioning Typical Processes”

  • There are many processes in a typical project that don’t transition well to agile because they require heavyweight documentation or are an inherent part of the phased and gated process & require signoffs at the end of each stage.

“Metrics can be controversial”

  • Measurements such as cycle time that involve the whole team are more likely to drive you toward success than measures confined to isolated roles or groups.
  • Lean development looks for ways to delight customers, which ought to be the goal for all software development.
  • Metrics that measure milestones along a journey to achieve team goals are useful.

When you are trying to figure out what to measure, first understand what problem you are trying to solve. If your goals are measurable, the measurements you need to gather to track the metrics will be obvious.

  • Figure each metrics Return on Investment and decide whether to track or maintain it. Does the effort spent collecting it justify the value it delivers? Can it be easily communicated and understood? Do what works for your situation. Experiment with keeping a particular metric for a few sprints and evaluate whether it is paying off.

“Projects succeed when people are allowed to do their best work”

  • Defects tracking systems (DTS) are too often used as communication tools & entering unnecessary bugs can be wasteful. Focus on using DTS for the right reasons.
  • Whether your team decides to create a test plan or not, the planning should be done. Each project is different, so don’t expect that the same solution will fit all.
  • Regarding Audits, Processes & Models
    • Traditional quality processes & process improvement models like SAS 70 and CMMI standards can co-exist with agile.
    • Quality assurance teams in traditional development organisations are often tasked with providing information for auditors and ensuring compliance with audit requirements.
    • Examples include what testing has been performed on given software release or proving that different accounts reconcile.
    • Testers can be tasked with writing test plans to evaluate the effectiveness of control activities.
    • Work together with the compliance and internal audit teams to understand your team’s responsibilities.
  • If your organisation is using some kind of process model or quality standard, educate yourself about it and work with the appropriate specialists in your organisation.
  • Process improvement models and frameworks emphasize discipline and conformance to process.

“Standards simply enable you to measure your progress towards your goal”

  • Working with existing quality processes and models is one of the biggest cultural issues you may face as you transition to agile development. All of these changes are hard, but when your whole team gets involves, none are insurmountable.

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