The success of your team and the release depends on everyone getting their individual parts done in time. But how do you define being “done”? What indicates a finished task and differentiates it from a half-baked one?
It is all about having a clear definition of done established and agreed upon within the team from the onset of the project. Check out my article published at https://blog.gurock.com/definition-of-done/ – Here I talk about some good ways to define your Definition-Of-Done
Brainstorm with your team
The person who is going to work on each task is obviously the best person to comment on how and when it will be closed. So, the first step would be to discuss and list the obvious things these people deem would need to be done in order to be able to say that their task is done. Sometimes, you may be surprised how different these “obvious” points may be for different team members.
For instance, Tester 1 may say that after executing tests on their user story, they also spend an hour doing exploratory testing before completing their testing tasks, while Tester 2 did not consider that as part of the task. They completed the test execution task once done with scripted tests and later, if time permitted, would perform some exploratory tests.
By doing this exercise you are baselining your expectations from each task, independent of its owners.
Consider quality goals
If you are seeking to come up with a definition of done, there is probably an area you are trying to improve and some quality goals you are trying to achieve, so consider them now. Think of what seem to be your team’s problem areas, or the source of their delays at the end. Now add a part of those quality goals in the relevant tasks.
For example, let’s say your builds seem to fail too often, and that leads to a lot of rework and retesting within the sprint. After some analysis, you found that the build failed because of developers checking in buggy code, mostly lacking integration tests.
Outlining some Key success factors for Agile Testing –
Success Factor -1 Use the Whole Team Approach
When the whole development team takes responsibility for testing & quality, you have a large variety of skills sets and experience levels taking on whatever testing issues might arrive.
Success Factor -2 Adopt an Agile Testing Mind-Set
Use agile principles and values to guide you. Always try the simplest approach first. Experiment with new practices, tools, and techniques.
Success Factor -3 Automate Regression Testing
Use Agile Testing Quadrants and test automation pyramid to help you automate different types of tests effectively. Experiment with different ways of getting support from management and from team members to start some tiny automation effort.
Success Factor-4 Provide and Obtain Feedback
One of the most valuable skills you can learn is how to ask for feedback on your own work. Feedback is imperative for agile teams.
Success Factor -5 Build a Foundation of Core Practices
Continuous Integration process needs to be implemented, setup test environments and manage technical debt
Success Factor -6 Collaborate with Customers
Help customers clarify and prioritize requirements, illustrating requirements with concrete examples and turning those examples into executable tests.
Success Factor -7 Look at the Big Picture
Testers tend to look at the big picture, and usually from a customer point of view, which is a big contribution to the team. Plan testing to cover all angles. Use Exploratory testing to learn more about how the application should work, and what direction your testing needs to take.
And here ends my ‘Read Along’ Series for ‘Agile Testing’ by Lisa Crispin and Janet Gregory. It sure was a fun and informative read and I learnt a lot from it! I hope this series helps someone read along chapter-wise or even someone looking for quick introduction to agile testing.
It’s not enough to just code, test and say it’s done. Our goal is to deliver value to the business in a timely manner.
It is helpful to have a “Fit and Finish” checklist. Sometimes fit and finish items aren’t ready to be included in the product until close to the end. It may be necessary to rebuild parts of the product to include items such as new artwork, license or legal arrangements, digital signatures for executables, copyright dates, trademarks and logos.
It is helpful to assemble these during the last full development iteration and incorporate then into the product while continuous integration build cycles are running so that extra builds are not needed later.
Agile testers can serve as a conduit or facilitator when it comes to physical delivery of the software.
Most teams accumulate some technical debt, despite the best intentions, especially if they’re working with legacy code. To maintain velocity, your team may need to plan a refactoring iteration at regular intervals to add tests, upgrade tools and reduce technical debt.
Some teams resort to ‘hardening’ iterations, where they spend time only finding and fixing bugs, and they don’t introduce any new functionality. This is a last resort for keeping he application and its infrastructure solid. New teams may need an extra iteration to complete testing tasks, and if so, they budget time for that in the release plan.
It is the time when the team applies the finishing touches to the product.
It is not meant to be a bug-fix cycle, because you shouldn’t have any outstanding bugs by then, but that doesn’t mean you might not have one or two to fix.
Use the end game to do some final exploratory testing. Step back and look at the whole system and do some end-to-end scenarios.
As a part of the end game, your application should be deployed to staging just like you would deploy it to production.
Staging environments can also be used for load and performance testing, mock deploys, fail-over testing, and manual regression tests and exploratory functional testing.
Automating data migrations enhances your ability to test them and reduces the chance for human error.
Last minute disasters can happen. The team should cut the release scope if the delivery date is fixed and in jeopardy.
Work to prevent a “no go” situation with good planning, close collaboration, driving coding with tests, and testing as you code.
As a tester, it is important to understand how customers view the product, because it may affect how you test. Alpha and Beta testing may be the only time you get to interact with end users, so take advantage of the chance to learn how well the product meets their needs.
Learn from each release and take actions to make the next one to go more smoothly.
Conferences, events and meetups are all things I enjoy. I have been an organizer, speaker & presenter, host and volunteer at many events. When 2020 started, I had big hopes and plans of travelling to speak at multiple international events and also had a few local Bangalore events lined up. But the world had to face a pandemic and everything came to a screeching halt.
As many of you, I was disheartened too. But I still hoped for things to get better, thinking we might get to some of the events at least. Things are different now. We now know that this lifestyle is here to stay. We have been working, learning, recruiting, networking and meeting remotely and might have to continue to do so for a while.
But where does this put the life of a ‘speaker’ – someone who enjoys speaking, being invited to attend and talk at events?
Well, I would like to highlight how I have been pleasantly surprised by the state of our events and their emergence from all the cancellations, losses and hearbreaks!
In the past 6 months, I have spoken at more events I would have normally! I have had the chance to connect with multiple events in various ways and all of them have shown me the resilience of our community.
TribalQonf , STeP-In Summit, Test Leadership Congress 2020
I was invited by Mahesh Chikane to speak at the TribalQonf which was a great opportunity. I presented about Adopting a Risk Based Test Approach and my talk was appreciated for which I am always #grateful !
The event was organised well and I am glad to be a part of this superb round up video along with some awesome speakers!
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.
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.
The beginning of coding is a good time to start writing detailed tests.
As testers think of new scenarios to validate with executable tests, they also think about potential scenarios for manual exploratory testing. Make a note of these for later pursuit.
Some quick risk analysis can help you decide what testing to do first and where to focus your efforts.
The Power of Three Rule – When unexpected problems arise, you may need to pull in more people or even the entire team. Tester, Developer and Customer (or businesspeople) can together decide on correct behavior and solutions.
As soon as testable chunks of code are available, and the automated tests that guided their coding pass, take time to explore the functionality more deeply. Try different scenarios and learn more about the code’s behavior. You should have task cards for tests that critique the product both business and technology-facing. The story is not ‘done’ until all of these test types are done.
If your exploratory tests lead the team to realise that significant functionality was not covered by the stories, write new stories for future iterations. Keep a tight reign on “Scope Creep” or your team won’t have time to deliver the value you originally planned.
Technology-facing tests that critique the product are often done best during coding. This is the time to know if the design doesn’t scale or if there are security holes.
Leaving bugs festering n the code base has a negative effect on code quality, system intuitiveness, system flexibility, team morale and velocity.
Strive for “zero tolerance” towards bug counts.
Teams have solved the problem of how to handle defects in different ways.
Some teams put all their bugs on task cards
Some teams chose to write a cared, estimate it & schedule it as a story.
Some teams suggest adding a test for every bug
The more bugs you can fix immediately, the less technical debt your application generates and the less ‘defect’ inventory you have.
Try making the estimate for each story to include (atleast) two hours or half a day for fixing associated bugs.
If a bug is really missed functionality, choose to write a card for the bug and schedule it as a story.
Code produced test-first is fairly free of bugs by the time it is checked-in.
The Daily Stand-Up helps teams maintain the close communication they need.
Use Big, visible charts such as story boards, Burndown charts and other visual cues to help keep focus and know your status.
Having story boards gives your team focus suring the stand-ups or when you are talking to someone outside the team about your progress.
Testers can help keep the iteration progressing smoothly by helping make sure everyone is communicating enough. They can help programmers and customers find a common language.
Use retrospectives to evaluate whether collaboration & communication need improving and brainstorm ways to improve.
Teams in different locations have to make a special effort to keep each other informed.
Teams take different approaches to make sure their build stays ‘green’.
The build needs to provide immediate feedback, so Keep It Short.
Tests that take too long, such as tests that update the database, functional tests above Unit level or GUI test scripts, should run in a separate build process.
Having a separate, continual ‘Full’ build with all of the regression suites is worth the investment.
During the iteration, you are automating new tests. As soon as these pass, add them to the Regression Suite.
As you start the iteration, make sure that test environments, test data, and test tools are in place to accommodate testing.
You may have brought in outside resources for the iteration to help with performance, security, usability or other forms of testing. Include them in stand-ups and discussions. Pair with them to help them understand the team’s objectives. This is an opportunity to pick up new skills!!
Consider what metrics you need during the iteration – Progress and Defect Metrics are 2 examples.
Whatever metrics you choose to measure – Go for Simplicity!
Most teams kickoff their new iteration with a planning session. – where they discuss one story at a time, writing & estimating all of the tasks needed to implement it.
Task cards need to be written along with development task cards and estimated realistically.
When writing programming task cards, make sure that coding task estimates include time for writing unit tests and for all necessary testing by programmers.
Testers should help make sure that all necessary cards are written and they have reasonable estimates.
Your job as a tester is to make sure enough time is allocated to testing and to remind the team that testing & quality are the responsibility of the whole team. When the team decides how many stories they can deliver in an iteration, the question isn’t “How much coding can we finish?” but “How much coding and testing can we complete?”
Commit Conservatively – It is always better to bring in another story later than to drop a picked story.
Working closely with customers or customer proxies is one of the most important activities as an agile tester. Good communication usually takes work.
We want “big-picture” tests to help the programmers get started in the right direction on a story. High level tests should convey the main purpose behind the story.
Don’t forget to ask the programmers what they think you might have missed. What are the high-risk areas of the code? Where do they think testing should be focused?
When Testability is an issue, make it the team’s problem to solve.
One beneficial side-effect of reviewing the tests with programmers is the cross-learning that happens.
High level test cases along with executable tests you’ll write during the iteration will form the core of the application’s documentation.
People unfamiliar with agile development often have the misconception that there’s no documentation. In fact, agile projects produce usable documentation that contains executable tests and thus, is always up to date.
Testers in agile must be proactive. Instead of waiting for work to come to them, they get up and go look for ways to contribute.
Working on stories in advance of the iteration may be useful for teams that are split across different geographic locations. By working ahead, there’s time to get information to everyone and give them a chance to give their input.
If we make our iteration planning go faster and reduce the risk of the stories we’re going to undertake, it’s worth doing some research and brainstorming before we start the iteration.
The Pre-Planning Meeting
Go Over stories for the next iteration
The Product owner explains the purpose of each story – business conditions of satisfaction.
Team brainstorms about potential risks and dependencies, asks questions and figures out the simplest path.
Pull in customers to answer questions, get a better idea.
Experiment with short Pre-Iteration discussions and Test-Writing sessions
Invest preparation time when it’s appropriate. There is a risk to ‘working ahead’.
To go Fast – We need to Slow Down First!
Teams that are distributed in multiple locations may do their iteration planning by conference call, online meeting or teleconference. ( And Cut to 2020 – Coronian Times – Every one of us is doing that!! )
One practice that Lisa’s team used was to assign each team a subset of the upcoming stories and have them write task cards in advance.
(I, too, have used this practice – only the Task Cards were in fact story Sub-tasks being created in JIRA for our user story items created by the PO)
If the customers aren’t readily available to answer questions and make decisions, other domain experts who are accessible at all times should be empowered to guide the team by determining priorities and expressing desired system behavior with examples.
(I have experienced that – our Product Owners essentially did this job for us)
Examples are an effective way to learn about and illustrate desired functionality. Using Examples, you can write high level tests to flesh out the story a bit more.
Mock-ups are essential for stories involving UI or a report. Ask your customers to draw up their ideas about how the page should look.
Before the next iteration – triage the outstanding issues with the customer. Those deemed necessary should be scheduled into the next iteration.
Testers bring a different viewpoint to planning and estimation meetings. They need to be a part of the story sizing process.
The team needs to develop in small, testable chunks in order to help decide what stories are tentatively planned for which iteration. They keyword being ‘testable’.
If there are stories that present a big testing challenge, it might be good to do those early on.
Release Planning is the time to start asking for examples and use cases of how the features will be used, and what value they’ll provide. Drawing flowcharts or sample calculations on white board can help pinpoint the core functionality.
The agile tester thinks about how each story might affect the system as a whole or other systems that ours has to work with.
In agile development, Test Plan must be concise and lightweight., assessing testing issues, including risk analysis and identifying assumptions. The biggest benefit of test planning is the Planning itself.
This chapter shows examples of lightweight agile Test Plans created by Lisa and Janet that are very useful! Here is my take on creating a simplistic agile test plan using a mind-map-
The chapter discusses about Task Boards and how they can be leveraged. Here is my take on using task boards by agile teams that I wrote a few months back –
Agile metrics are key to measuring the team’s progress. Plan for what metrics you want to capture for the life of the release, think about what problem you are trying to sove and capture only those metrics that are meaningful for your team.
Here is something I wrote about useful and not-so-useful Agile metrics-
Don’t get caught up with committing to your plans- the situation is bound to change. Instead, prepare for doing the right activities and getting the right resources in time to meet the customer’s priorities!
Use the Agile Test Quadrants to help you identify the different types of test automation tools you might need for each project, even each iteration.
Test Automation Pyramid (introduced by Mike Cohn)
Lowest Layer- Bulk of automated unit , technology facing tests. Quickest feedback, code much more quickly using xUnit family of tools
Middle layer – Automated business-facing tests that help the team. “Are we building the right thing” Tests operate at the API, behind the GUI level. Bypass the presentation layer – less expensive to write & maintain these tests. Fit & FitNesse are good examples, written in domain language
Top Tier – Should be the smallest automation effort as they have the lowest ROI. Done through GUI, operating on the presentation layer. More expensive to write, more brittle and need more maintenance.
Any tedious or repetitive task involved in developing software is a candidate for automation.
AN automated deployment process is imperative – getting automated build emails listing every change made is a big help to testers. It speeds up testing & reduces errors.
A fast running continuous integration and build process gives the greatest ROI of any automation effort.
Another useful area for automation is data creation or setup. Cleaning up test data is as important as generating it. You data creation toolkit should include ways to tear down the test data so it doesn’t affect a different test or prevent rerunning the same test.
What we shouldn’t automate
Tests that will never fail
Plan-in plenty of time for evaluating tools, setting up build processes, and experimenting with different test approaches in the initial iterations.
If management is reluctant to give the team time to implement automation, explain the trade-offs clearly. Work towards a compromise.
We will always have deadlines, and we always feel pressed for time. There is never enough time to go back and fix things. During your next planning meeting, budget time to make meaningful progress on your automation efforts.
Good test management ensures that tests can provide effective documentation of the system and of the development progress