“5 Ways DevOps complements Agile” – As an industry practitioner who has worked in agile for almost a decade now, I have always seen DevOps as a friend and an extension of agile. Using this article I have tried to put across my view on how this handshake between developers and operations personnel works in favor of bridging the gap from software creation to software delivery.-
It is my pleasure and honor to share that my article on
“Let the Agile Manifesto guide your Software Testing”
published on Techwell Community forum http://www.stickyminds.com in 2017 has now been featured in the list of “Hottest Articles of 2017” , featuring in the Top 10 Most Read articles last year!
My article on the relationship of Agile Manifesto to the efforts and dilemmas of software testing has been published at stickyminds.com
Here are excerpts from the article – Please visit https://www.stickyminds.com/article/let-agile-manifesto-guide-your-software-testing and share your views too!
The Agile Manifesto is the basis of the agile process framework for software development. It sums up the thought process of the agile mind-set over the traditional waterfall methodology, and it’s the first thing we learn about when we set out to embrace an agile transition.
The Agile Manifesto applies to all things agile: Different frameworks like Scrum, DAD (Disciplined Agile Delivery), SAFe (Scaled Agile Framework), and Crystal all stem from the same principles.
Although its values are commonly associated with agile development, they apply to all people and teams following the agile mind-set, including testers. Let’s examine the four main values of the Agile Manifesto and find out how they can bring agility to teams’ test efforts.
Individuals and Interactions over Processes and Tools
Agile as a development process values the team members and their interactions more than elaborate processes and tools.
This value also applies to testers. Agile testing bases itself in testers’ continuous interaction and communication with the rest of the team throughout the software lifecycle, instead of a one-way flow of information from the developers or business analysts on specific milestones on the project. Agile testers are involved in the requirements, design, and development of the project and have constant interaction with the entire team. They are co-owners of the user stories, and their input helps build quality into the product instead of checking for quality in the end. Tools are used on a necessary basis to help support the cause and the processes.
For example, like most test teams, a team I worked on had a test management system in place, and testers added their test cases to the central repository for each user story. But it was left up to the team when in the sprint they wanted testers to do that. While some teams added and wrote their test scenarios directly on the portal, other teams found it easier to write and consolidate test cases in a shared sheet, get them reviewed, and then add them all to the repository portal all at one go.
While we did have a process and a tool in place to have all test cases in a common repository for each sprint, we relied on the team to decide what the best way for them was to do that. All processes and tools are only used to help make life easier for the agile team, rather than to complicate or over formalize the process.
Working Software over Comprehensive Documentation
With this value, the Agile Manifesto states the importance of having functioning software over exhaustively thorough documents for the project.
Similarly, agile testers embrace the importance of spending more time actually testing the system and finding new ways to exercise it, rather than documenting test cases in a detailed fashion.
Different test teams will use different techniques to achieve a balance between testing and documentation, such as using one-liner scenarios, exploratory testing sessions, risk-based testing, or error checklists instead of test cases to cover testing, while creating and working with “just enough” documentation in the project, be it through requirements, designs, or testing-related documents.
I worked on an agile project for a product where we followed Scrum and worked with user stories. Our approach was to create test scenarios (one-liners with just enough information for execution) based on the specified requirements in the user story. These scenarios were easily understood by all testers, and even by the developers to whom they were sent for review.
Execution of test scenarios was typically done by the same person who wrote them, because we had owners for each user story. Senior testers were free to buddy test or review the user story in order to provide their input for improvements before finalizing the tests and adding them into the common repository.
Customer Collaboration over Contract Negotiation
This is the core value that provides the business outlook for agile. Customer satisfaction supersedes all else. Agile values the customer’s needs and constant communication with them for complete transparency, rather than hiding behind contract clauses, to deliver what is best for them.
Agile testing takes the same value to heart, looking out for the customer’s needs and wishes at all points of delivery. What is delivered in a single user story or in a single sprint to an internal release passes under the scrutiny of a tester acting as the advocate for the customer.
Because there is no detailed document for each requirement, agile testers are bound to question everything based on their perception of what needs to be. They have no contract or document to hide behind if the user is not satisfied at the end of the delivery, so they constantly think with their “user glasses” on.
As an agile tester, when I saw a feature working fine, I would question whether it was placed where a user would find it. Even when the user story had no performance-related criteria, I would debate over whether the page load time of six seconds would be acceptable. After I saw that an application was functionally fine, I still explored and found that the open background task threads were not getting closed, leading to the user’s machine getting hung up after few hours of operation. None of these duties were a part of any specification, but they were all valuable to the user and needed correction.
Responding to Change over Following a Plan
Agile welcomes change, even late in development. The whole purpose of agile is to be flexible and able to incorporate change. So, unlike the traditional software development approaches that are resistant to change, agile has to respond to change and teams should expect to replan their plans.
In turn, such is the case for agile testing. Agile testing faces the burden of continuous regression overload, and topped with frequent changes to requirements, rework may double itself, leading to testing and retesting the same functionalities over and over again.
But agile testing teams are built to accommodate that, and they should have the ability to plan in advance for such situations. They can follow approaches like implementing thorough white-box testing, continuously automating tested features, having acceptance test suites in place, and relying on more API-level tests rather than UI tests, especially in the initial stages of development when the user interface may change a lot.
These techniques lighten the testing team’s burden so that they can save their creative energies to find better user scenarios, defects, and new ways to exercise the system under test.
Let the Agile Manifesto Guide Your Testing
When agile testers have dilemmas and practical problems, they can look to the Agile Manifesto for answers. Keep it in mind when designing and implementing test efforts; the Agile Manifesto’s values will guide you to the best choice for your team and your customers.
I am so excited to share that one of my articles published on http://www.stickyminds.com this year – titled “5 Ways Agile Testing Is Different from Traditional Testing” has been recognised as the #1 Most Popular Article in their Top 10 articles of 2016 list.
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.
testwithnishi 