Tag: readers

Read Along- ‘Agile Testing’ Chapter-10

Nishi Grover Garg1 Comment

“Business-Facing Tests that Critique the Product”

  • Critiquing or evaluating the product is what business users or tester do when they assess and make judgement about the product.
  • These are the tests performed in Quadrant 3 of our Agile Testing Quadrants
  • It is difficult to automate Business facing tests that critique the product, because such testing relies on human intellect, experience, and insight.
  • You won’t have time to do any Quadrant 3 tests if you haven’t automated tests in Quadrants 1 and 2.
  • Evaluating or critiquing the product is about manipulating the system and trying to recreate the actual experience of end users.

Demonstrations

  • Show customers what you are developing early & often.
  • End-of-iteration demos are important to see what has been delivered and revise priorities
  • Rather than just waiting for end of sprint demos, use any opportunity to demonstrate changes as you go.
  • Choose a frequency of demos that works for your team. Informal demos can be more productive

Scenario Testing – Business users can help define plausible scenarios & workflows that can mimic end user behavior

Soap Opera Testing – Term coined by Hans Buwalsa (2003) can help the team understand business & user needs. Ask “What’s the worst thing that can happen, and how did it happen?”

Exploratory Testing

  • As an investigative tool, it is a critical supplement to the story tests and our automated regression suite.
  • Sophisticated, thoughtful approach to testing without a script, combining learning, test design and test execution

Usability Testing

There are 2 types of usability testing. The first is done up front by user experience folks, using tools such as wire frames to drive programming. These are part of Quadrant 2.

The second type talks about the kind of usability testing that critiques the product. We use tools such as User Personas and our Intuition to help us look at the product with the end user in mind.

API Testing

Instead of just thinking about testing interfaces, we can also look at APIs and consider attacking the problem in other ways and consider tools like simulators & emulators.

Testing Documentation

User manuals & online help need validation just as much as software. Your team may employ specialists like technical writers who create & verify documentation. The entire team is responsible for the quality of documentation.

Read Along- ‘Agile Testing’ Chapter-8

Nishi Grover Garg2 Comments

“Business-Facing Tests that Support the Team”

A look at tests in Quadrant-2 – Business-Facing tests

Agile Testing Quadrants
  • On an agile project, the customer team and the development team strike up a conversation based on a user story.
  • Business-facing tests address business requirements. They express requirements based on examples and use a language and format that both the customer and development teams can understand. Examples form the basis of learning the desired behavior of each feature and we use those examples as the basis of our story tests in Quadrant-2
  • Business-facing tests are also called “customer-facing”,”story”,”customer” and “acceptance” tests. The term ‘acceptance tests’ should not be confused with ‘user acceptance tests’ from Quadrant-3.
  • The business-facing tests in Q-2 are written for each story before coding started, because they help the team understand what code to write.
    • Quadrant-1 activities ensure internal quality, maximize team productivity, and minimize technical debt.
    • Quadrant-2 tests define and verify external quality and help us know when we are done.

The customer tests to drive coding are generally written in executable format, and automated, so that team members can run the tests as often as they like to see if functionality works as desired.

  • Tests need to include more than the customer’s stated requirements. We need to test for post-conditions, impact on the system as a whole, and integration with other systems. We identify risks and mitigate those with our tests. All of these factors then guide our coding.
  • The tests need to be written in a way that is comprehensible to a business user yet still executable by the technical team.
  • Getting requirements right is an area where team members in many different roles can jump in to help.
  • We often forget about non-functional requirements. Testing for them may be a part of Quadrants 3 and 4, but we still need to write tests to make sure they get done.

There are conditions of satisfaction for the whole team as well as for each feature or story. They generally come out of conversations with the customer about high-level acceptance criteria for each story. They also help identify risky assumptions and increases team’s confidence in writing & correctly estimating tasks needed to complete the story.

  • A smart incremental approach to writing customer tests that guide development is to start with a “thing-slice” that follows a happy path from one end to the other. (also called a “steel-thread” or “tracer-bullet”). This ‘steel-thread’ connects all of the components together and after it’s solid, more functionality can be added.
  • After the thin slice is working, we can write customer tests for the next chunk.
    • It’s a process of  “write tests — write code— run tests — learn”
  • Another goal of customer tests is to identify high-risk areas and make sure code is written to solidify those.
  • Experiment & find ways your team can balance using up-front detail and keeping focused on the big picture.

Quadrant-2 contains a lot of different types of tests and activities. We need the right tools to facilitate gathering, discussing, and communicating examples and tests.

>>Simple tools such as Paper or Whiteboard work well for gathering examples if the team is co-located.

>>More sophisticated tools help teams write business-facing tests that guide development in an executable, automatable format.

Read Along- ‘Agile Testing’ Chapter-7

Nishi Grover Garg1 Comment

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

Nishi Grover Garg1 Comment

“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

Nishi Grover GargLeave a comment

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