I recently got connected to Edista Testing Institute – an initiative of STC-QAI in Bangalore, which led me to an opportunity to train a group of fresh minds for a career in software testing.
The 10-day long training included a detailed course on Software Testing , methodologies, STLC , Agile Testing , various testing techniques with practical hands-on exercises and some great quizzes and interactive sessions. It was an amazing experience coaching the young minds and driving them towards this great . The students also responded really well to the practical sessions and exercises conducted, and we had a great feedback for the complete batch. I wish them all the very best for all their future endeavors.
When I heard about the ATA-Global Gathering event happening in Bangalore , I was super-excited to be a part of it! So, I sent my proposal to Nitesh from UNICOM and Tushar from ATA who are both great at organizing such great events. They liked it and voila! I was in the Speakers list on the site 🙂 check it out –
My session went great and was very well received by the audience. We talked about Gamification of Agile teams and had some awesome volunteers playing fun games with us. The audience was totally engaged in the session and we got great feedback! 🙂 🙂 Here is a peek into the highlights of the day –
Testers who analyze quality in every aspect of the team’s deliverable also have a responsibility to mitigate risks and practical issues that are bound to come up, and help the team succeed in their product as well as at being agile. Here are five such issues that testers can help the team alleviate or avoid.
SAMPLE SCENARIO:
Let’s say an agile team has a user story to develop a webpage in a sprint. The product manager mentions only the mandatory fields of the webpage in the story’s description while scoping it in the sprint. The developer works on the story for a couple of days and adds the listed fields on the page, but because he going on leave for a few days, he only provides the basic form fields without any input validations or error messages on the page.
Once back from his vacation, he checks in the code and shares it for testing a day before the sprint ends. The tester tests it for a day and raises some minor severity issues. In the final sprint demo, the product manager points out that a number of fields are missing on the webpage. Because testing is not complete yet, the story is tagged as a spill-over item to the next sprint. Few UI changes are added in the next sprint’s scope, along with the pending validations and error messages.
What do you think went wrong in this story?
Agile is all about controlling and minimizing the typical risks of conventional software development techniques. When working with agile, we have the flexibility to control our direction and steer our path based on unforeseen and unplanned changes and events.
But it is the same flexibility and dynamic nature that makes agile prone to many risks during the project.
These risks are the practical issues that any agile team is bound to face eventually and that, if not handled quickly, may lead to failure of the sprint or the agile process as a whole. Testers who analyze quality in every aspect of the team’s deliverables also have a responsibility to mitigate these risks and help the team succeed in their product as well as at being agile.
Here are five such issues that testers can help the team alleviate or avoid.
The power of Five!
Risk 1: Ambiguous User Stories
Agile assumes that each user story is a unit of work to be achieved in a sprint. The user story needs to be granular enough and have all relevant details and context when scoped. But because agile also recognizes changing requirements as likely, this gets used as an excuse to not list the requirements for each user story or give details early on. This leads to ambiguous requirements, often resulting in low-quality outcomes and rework on the feature.
The actual aim of agile is to work on a feature based on the best knowledge of its requirements at the given time. The sprint format in the Scrum process leaves scope to work on a feature again if enhancement is needed. But that is based on collecting all available information for one story and only then scoping it in a sprint. If that is not ready yet, the story should not be scoped in the current sprint.
Testers in an agile team have the responsibility of reviewing user stories when they are being planned for the sprint and requesting clarification from the product management. Similarly, developers can raise questions about technical and design details they feel are missing and get them defined during planning sessions. Based on these details, testers will create their test scenarios around that user story, and developers will create their implementation design and keep asking more questions if needed over the next few days of the sprint.
In the example at the beginning, the tester could have raised the concern that the user story did not have complete details for the webpage to be developed while scoping it in the sprint. The developer should have asked about relevant validations and error messages needed, as well as some broad layout details to work with.
Risk 2: Not Delivering the Highest Business Value
When a sprint is in progress, developers may dig into their assigned stories and, in trying to get the more complicated things done, digress from the priority of each story. As testers, we constantly need to question the delivery of the most valuable features in the sprint so that we are sure to test and deliver them as early as possible.
During the sprint planning discussion, we must assign business priorities to each story being scoped in. The sequence in which the stories will be delivered will depend on that.
Testers may also raise concerns when more time will be needed to test a feature, and request for it to be delivered early so that the testing can be completed well within the sprint deadline.
At all times we must assume that only the stories that are done from both development and testing perspectives are the ones that are designated as delivered in the sprint final build.
In the example, the developer could have shown the developed page to the product manager and asked for feedback during the sprint to avoid multiple iterations. The tester should have asked for a buddy build for the story before the developer left for vacation to provide more testing time and get maximum issues within the sprint. This would have avoided the task needing to spill over to the next sprint.
Risk 3: Quality Concerns
During the sprint testing cycles, all issues found pertaining to a feature must be tagged with the relevant user story. This can be done easily by linking the issues together in the issue-tracking tool being used.
The testing team must decide on a tolerance threshold for the number of issues for each user story based on their severity, beyond which they would raise a quality concern against that story. Testers should then request these issues to be fixed before any further development is done on that story. This helps immensely in avoiding delivery of half-baked features with too many known issues yet to be fixed at the end of the sprint. This way, at the end of the sprint, all user stories are at a minimum quality benchmark with no obvious or critical issues. Of course, improvements and enhancements are always welcome and may be taken in further sprints.
In the example story,the tester should have raised maximum issues against the user story within the sprint and brought them to the product manager’s attention, along with missing or undelivered functionalities.
Risk 4: Resource and Time Conflicts
When working in a sprint format, the process is bound to be very fast-paced, with each team member being relied on heavily for the assigned user stories.
There may be parallel tracks or other activities, like performance improvements, code refactoring, white box tests, or documentation and reviews, that team members may be expected to handle, which, if they go beyond a number of hours per sprint, may hinder the sprint deliverables. It is the team members’ responsibility to bring any such activities to the ScrumMaster’s notice as risks during the daily stand-up meeting.
The testing team may raise any planned resource or time conflicts during the sprint planning session itself, so that estimation may account for these time losses. Team members also are expected to bring up any planned vacations or leave during the planning session so that their absence may be accounted for during estimation.
In the example story,the developer’s leave plan should have been taken into account when assigning the user story, and consequently, there could have been a co-owner of the story to take up the additional parts, such as implementing validations and UI improvements to the page while the developer was away.
Risk 5: Failures in Collaboration and Communication
Scrum ceremonies, such as the sprint planning sessions, daily stand-ups, triage meetings, and sprint retrospectives meetings, rely heavily on the team’s self-drive and total involvement. Without these factors, the ceremonies become mere formalities, adding little value to the process.
Testers in an agile team must be involved in every phase of the agile development process and raise concern if the team is not performing any of the ceremonies in the correct fashion. Only with full participation and regular communication can we actually achieve success as an agile team.
In the example, the team could have communicated more over the user story, talked to the product manager, and proactively gotten more information, details, and feedback during development. The tester could have initiated more discussions around the requirements and worked closely with the developer to highlight issues instead of waiting for the final build at the end of the sprint.
A tester’s role in an agile team is to provide assistance and support in all areas, so they may need to switch hats frequently, depending on the team’s needs. The success of this endeavor, though, also depends on an open, communicative, and receptive environment fostered within the team. Following these basic pointers can make testing a fun and collaborative part of the agile environment and add a lot more value.
Agile needs continuous improvement and innovation , and we are striving for the same at my new workplace MetricStream, Bangalore. As a part of that, I was invited to conduct a session on some practical and easily adoptable agile practices.
Well what better than Innovation Games for that !
So we went ahead and did a 3-part practical training exercise session wherein not only did we learn about the Agile workflow , the basics on innovation games and how they fit into Agile , but also conducted practical group exercises with sample scenarios and user stories.
It was a great experience and received quite well. The participants were encouraged to take back the learning to their own scrum teams and try out the fun and quick games for conducting various Agile ceremonies.
Here is a glimpse into the training room :
Playing Innovation GamesPlaying Innovation GamesPlaying Innovation GamesPlaying Innovation Games
Here we have for you another Innovation Game centered around prioritization. It is a visual and crisp way to chart out and understand priorities of upcoming tasks , features or stories.
Game : 20/20 Vision
Aim : To chart out the RELATIVE priorities of the tasks at hand
Method: The 20/20 game elaborates the prioritization of each task in relation to a benchmark task of medium priority and complexity.
Just like a visit to the Optometrist, where he makes you compare the various lenses to find the best suitable for your sight, in this game we make the team compare all stories / requirements / tasks and find the right place for them on the chart of priority in relation to the one benchmark level.
Description: Write down all stories on post-its. With the team’s consensus and decision, decide on one story which is of medium level and put in on the board in the middle.
Now the team goes through each story one by one, and places the story on the board as higher or lower priority in relation to the benchmark story. At the end of the exercise, we arrive at a visual representation of the story or task prioritization, giving us a clear road-map for future!
This game takes almost 15-30 minutes only depending on the number of tasks at hand, as compared to long planning meetings.
Hope you are enjoying our series on Innovation Games, and learning some new techniques to engage your Agile team. In Part 1 and Part 2 we discussed some really fun and interesting Agile Innovation games.
In this part we shall discuss a really unique Innovation Game which helps the team and stakeholders to gather a broader perspective on the product or project they are working on. While working on small components and intricacies of the project, it is possible for us to loose perspective and be confined in a narrow zone.Our game helps us to ‘Zoom-Out’ periodically and get a bird’s eye view of the project, its future and the road-map ahead. It is called –
Prune The Product Tree –
Objective:
To identify the most important features, aspects of the product as per the stakeholders and to elicit feedback from the customers.
Method :
Draw a big tree on the chart and draw its branches. The thick branches represent the major functionalities of your system. The smaller branches are the functionalities within each branch.
Participants place the index cards in their respective branches after writing the new expected features.
We may also add apples for functionalities that will be very useful for next releases, and flowers for the good-to-have features that may wow customers!
Prune The Product Tree
Analysis:
This will give an overview of the future direction of the product and gives visual representation on which branch of the product tree is expanding the most.
Try this out with your team , and you shall see the benefits soon! 🙂
Hope you enjoyed the first part of our series on “Innovation Games”!
The next Innovation Game in our series is “Speed Boat”. This is a fun way to do retrospectives and feedback meetings where there is need for all team members to voice their opinions in an open and anonymous way. This method reduces the duration of the meeting to almost one half and gets better results which may indeed be very useful for the improvement of the agile team.
Game Objective:
To find the impeding and the helping factors in achieving any goal. It can be used as a fun way of doing retrospectives, as it engages the team and brings out the concern areas.
Method:
Let’s take one iteration or sprint for retrospective. Draw a boat with a Sail on front end and Anchors pulling it down at the back end.
All participants are given post-its to write down the factors that they think helped them move faster and post them on the sails; the factors that impeded their speed in that iteration and post them on the anchors.
We may also look for the desired factors which may help more in future and label them as the wind.
Analysis:
This feedback may be saved by just keeping a picture of this chart for revisit in the next sprint , or by saving the post-its as notes.The take-away would be to keep checking in the next sprints that we—
Minimize the anchors
Maximize the Sailing factors
Try and bring in the wind factors in the next iterations
This is a very useful tool to bring in better results from our retrospective meetings , give it a try in your agile team and let us know how it worked out!
As promised, I am now beginning the series on learning the most popular Innovation Games, some of which I also featured in my Session at UNICOM World Business Summit.
The first one we take up is “Mitch Lacey Team Prioritization”
Objective: The objective of this game is to prioritize the items in our ever-increasing backlog, which if not tracked can prove paralyzing for the agile team.
Method:Draw a chart with x axis as Size (small to Large) and y axis as the priority (lower to higher). The graph is divided into three columns for easier segregation.
Start out by handing out post-its having each backlog item listed, and the team places each item in the corresponding area as per their perception and discussion.
This is how your chart must look like:
The Mitch Lacey Chart
Analysis:
Top-left corner of the graph will be the items with high priority and low effort, so automatically be the first items to be picked.
Top-right corner, on the other hand, will be items with high priority and high complexity, so will be picked next.
By placing the ideas in the 2D space, it gives a clear visual representation of the next logical steps for the team, and also answers the vital question —“What should we do that will generate maximum value with minimum effort and complexity?”
I recently had the honor of Speaking at the World Business Summit 2015 by UNICOM at Bangalore.
It was a great experience where I not only had the chance to express my views and interact with a great audience, but also had the opportunity to meet some great leaders and like-minded professionals.
Here are a few excerpts from my session:
Topic – “Gamify your Agile Workplace – using Innovation Games”
Innovation Games are a set of directed games played by customers or the teams as a means of generating feedback about a product or a service.
They are being adopted widely across the agile world because of their visual, fun and effective nature.
Various Innovation games have been coined and described which can be used for various aspects and processes of the software development life cycle.
We also had an interactive session wherein we played an Innovation Game with the audience volunteers.
Speaking at World Business ConferenceConducting an interactive Innovation Game with audience volunteersReceiving the honor
Please follow this space for details on Innovation Games and how to effectively use them in an Agile team.
As is a well-known fact, Testing is a never-ending activity and is never 100% complete. No software can be called totally defect-free and hence there is always the scope for more testing.
The problem with today’s competitive software industry is the over-whelming demand for highest quality at lowest possible prices and time. The pressure of quick delivery leads to time and resource crunch and the testing phase being the last of the development cycle bears the brunt. At this stage, practicality demands to make use of Risk-based analysis to find the most important and impacted areas to be tested thoroughly, while smoke-level focus on the rest.
Though this approach is accepted by all in the team as well as the management, but still the risk of running into issues later with other parts of software is never acceptable. So, the onus is still set on the testing team, who are left with no time but with full responsibility in case anything breaks down!
Also, when each hour counts to the maximum in such critical times, there is increasing pressure within the testing team to perform the best. Managers find ways to quantify each hour and minute by ways of matrices and charts counting the number of issues found, hours logged and number of builds failed by each team member.
Solution: Weigh Quality over Quantity
It is important for an organization to understand the testing activities and the bent of mind that it requires. It is suggested to always weigh Quality of work delivered over the Quantity of issues / hours or tasks. Specially with manual testing, it is not possible to ever quantify the efforts.
Automated testing offers some scope of quantification in terms of Coverage of code, no. of environments and locales etc. But overall testing remains a creative profile.
So instead of pitching team members against each other by comparing their statistics, they should be encouraged to sit together and brainstorm their ideas, share their knowledge, review each other’s test scenarios and buddy test different stories.
Have you faced the pressure of quantification at your work?
testwithnishi 