A look at tests in Quadrant-2 – Business-Facing tests
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.
A look at tests in Quadrant-1 – Technology Facing tests
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.
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
Communication is the foundation of success for an agile team. Agile teams need to set up effective communication channels and have a culture of constant communication for complete transparency.
However, there are often several challenges that act as barriers to productive communication and may lead to people problems as well as delayed or failed projects. In my article for TestRail https://blog.gurock.com/agile-barrier-communication/ , I have discussed some of the most common barriers to effective communication for agile teams, as well as how you can overcome them.
Agile teams require constant communication, so it immensely benefits the team to recognize their barriers to effective communication and take some measures to overcome these barriers. Every step taken in this regard leads the team farther down their path to true agility.
Agile transformations can be a challenging undertaking, and many organizations struggle with what is probably the hardest part of the transition: adopting an agile mindset. It is imperative that teams embrace the agile culture before they can fully embrace agile.
As I always like to say, agile is more a mindset than a process. It guides you to a better way of working and collaborating in order to deliver the most value to your users. But how you choose to implement those guidelines is up to you, and most teams coming from a traditional style of software development find this aspect the most challenging.
Teams are left to find ways to work together rather than having a process forcing them to do certain actions, follow certain processes, or organize specific meetings. There are no templates or techniques to adhere to and no rules to follow strictly.
This may come as a surprise and leave teams guessing since they are used to being told what to do and how. Agile drives them to think on their feet as they plan and replan their way through the development process. Read More–>
Being Comfortable with Visibility & Exposure
Agile gives everyone a voice and values every person’s opinion. Many teams have been used to only the manager speaking for them or having one representative in most meetings. As a result, some team members may feel flustered now that they’ll occasionally be in the spotlight. People who are not used to voicing their opinion are expected to speak in all forums. Hiding behind the team is no longer an option in agile.
This also means team members are valued as individuals and everyone’s contribution is recognized. Agile treats all team members as equals, whatever their role or designation. They are expected to estimate their own tasks, pick things to work on, collaborate with other team members, and provide value by the end of each iteration. Continue Reading–>