My association with Verity Trainings recently led me to assist on and experience some great advanced level testing and ISTQB workshops by industry leaders! A great corporate team in Bangalore had invited experienced trainers as the likes of Mr Tarun Banga for their workshop on ISTQB Advanced Level Test Analyst which I happened to assist on as a co-trainer. It was an awesome experience and great learnings came from the interaction with a leader in trainings domain as well as the interaction with the team of candidates, having some proactive discussions, hands-on exercises and fun with learning environment.
Another great experience was hosting some hands-on public workshops on ISTQB Advanced test levels with Mr. Gaurav Pandey , where we met some excellent, self-driven individuals with keen sense of learning and quest for excellence in their careers.
With these interactions, I experienced that every trainer has their own style of delivery and conduct , even with similar content and exercises.And every candidate is bound to have their own experience with the training depending upon their agenda , quest and initiative!
Like everyone of us , many teams struggle with test creation due to miscommunication or a lack of requirements, testers not being present during design phases or discussions, a shortage of time, or incomplete information. But that doesn’t mean you should turn to guesswork. Your tests will suffer in quality and completeness. We must always strive to get the desired requirements.
“Don’t Guess Your Tests—Strive for Complete Requirements”
Here are some excerpts from the article –
Test creation is perhaps the most important aspect of software testing. Though most of our focus is on test execution and reports generation because that is the most visible output testing has, the backbone of the entire process lies in the creation of accurate and meaningful tests.
Many teams struggle with test creation during their agile journey, and they often seem to be doing a lot of guessing during test design or creation. This can be due to miscommunication or a lack of requirements, testers not being present during design phases or discussions, a shortage of time, incomplete information about which test environment or tools to use, or unknowns such as relevant positive and negative scenarios to test or overall purpose and scope of the application.
Hurried guesswork during test creation leads to bigger problems later in the project and poses a risk to the overall quality of the product.
Say your team has to test a webpage. Apart from some functional specifications about controls on the page, they do not have much information. But they have so many things to decide on before starting to test, such as what browsers to test on, which tool to use for automation based on the types of controls to be identified, what workflows to execute as part of integration testing of this page with the entire website, and so on.
It is also very important that those functional specifications about the webpage, its controls, and validations on each control are complete and thorough. When the team is designing and creating the test plans and test scenarios, ambiguous or missing requirements would lead them to assume a lot of parameters and guess some cases according to personal perceptions. For instance, a tester may assume Chrome should be the web browser under test and start using his installed version as the default without asking for customer preferences and all the versions that need support.
Suppose a username field on the webpage does not specify its upper limit and allowed characters validation in the specification. The tester may assume it to be a standard ten-character limit with only letters allowed and start testing accordingly, without asking relevant questions about regional and domain specific requirements. If the website has French users whose names contain special characters, or Indian users whose names frequently exceed ten characters, these inputs would fail from the tester’s assumptions and guesswork applied during testing.
Another problem teams may face is guessing test data. Are you using proper techniques to derive test data values, or just guessing random values to input? Suppose you are testing the function of addition. Are you randomly sending inputs of numbers and verifying the output? We should be using proper design techniques such as equivalence class partitions or boundary value analysis to derive a proper set of test values.
This is how poor communication or a lack of direction results in bad test design. We need to minimize this guesswork and make informed decisions before we begin the actual testing.
Getting Testers Involved in the Requirements Phases
My team was quick to realize this when we faced missing and vague requirements in one of our agile projects. We noted that due to a lot of factors mentioned above, we were subconsciously assuming things when designing tests and later on realizing our assumptions were incorrect, meaning many of our defects were marked invalid and we had to redo a lot of work. We decided to fight this problem.
The testing team started to request that we be allowed to participate during requirements phases, in user story fabrication as well as design discussions. This led to better clarity on a lot of requirements and functionalities, but it also ended up helping the entire team because we raised questions on the requirements and designs from a testing perspective and helped make better documents from the user stories, which later formed the basis of our tests.
The role of communication cannot be stressed enough here. We encouraged our teammates to ask the development team for more information—what to test, which environments to use, what could impact our testing, etc.—and our tests based on these solid facts and details were much more useful and successful.
Another good idea was involving the entire testing team, instead of having one or two team members create tests while the others just worked on executing them. We shared the details of the functionality to be tested with all the testers involved, and everyone collaborated on creating tests. With everybody giving their perspectives and opinions and challenging each other’s assumptions, our tests were bound to be more elaborate and exhaustive.
Reviews formed an important aspect to unbind the scope of our tests. We got peer testers, developers, test managers, and product owners to do some buddy reviews on our tests to ensure that we were not limited in our imagination and perspective. This opened up a lot of untouched areas and left no room for guesswork! It also gave us confidence that everybody had signed off on the designed tests, so it was unlikely that later on our defects would be valid.
If you don’t have enough information or communication to create your tests, that doesn’t mean you should turn to guesswork. Your tests will suffer in quality and completeness. We must always strive to get the desired details and only then create our tests based on solid grounds. This will eventually result in a lot less rework and much more valuable testing.
—
Please share your thoughts and follow the blog for more such interesting reads!
I am glad to share that my latest article found its way to agileconnection.com !
Here are some excerpts from the article –
Many organizations have issues during the transition to an agile workflow. Some teams never quite recover from that transformation stage; they say they tried agile but it didn’t work for them, or they are still struggling to get it going. If we look for the real reason behind all these troubles, I bet the majority fo the time, it would be communication.
Agile is designed for smaller that want to get more done with fewer formal processes. Iteratively building and demonstrating the desired products for more immediate feedback is the goal.
Think about the common practices of an agile team: daily stand-up meetings, retrospectives after every sprint, pair programming and buddy reviews, collaborating with customers, and more face-to-face time instead of mountains of documentation.
What is the agenda behind all these operations? Frequent and open communication.
Agile teams are designed so that everybody is aware of everyone’s tasks, progress, strengths, and output each day. The difficulty is communicating all this information.
Let’s say a team was working on a sprint with some defined user stories. The team started working on their assigned stories, using what little was specified in the requirements and assuming the rest. Nothing much was brought up in the daily stand-up meetings, which were short and missed often. The developers worked on their stuff, and in the last few days of the sprint passed their code on to the testers, who began their test design parallel to the test execution. Most of the testing was done in an exploratory fashion, owing to the lack of information and time.
Of course, problems arose. Testers blamed faulty designs and the lack of information provided to them. In turn, the developers blamed the specifications. The manager—who was missing for most of the sprint—now appears and questions the team about the quality issues. Most of the user stories become spill-over items to work on during the next sprint due to the design changes needed.
Unfortunately, this is probably not an unfamiliar situation for many of you. An agile team can’t succeed if communication is lacking.
The team in the example earlier could have done much better if they had nurtured their communication skills. The developers should have discussed the specifications and pointed out missing or ambiguous aspects to the manager, who then would have talked to the clients to get clarifications. The test team should have been involved in all these communications, building their tests in parallel and getting them reviewed. Developers and testers should have coordinated their user stories to buddy test the features and get maximum issues resolved in advance. And everyone should have been participating in stand-up meetings to communicate progress and risks. If this had happened, by the end of the sprint the user stories would have been resolved, and the team could have delivered a better-quality product.
Naturally, it’s easier to look at a failed project afterward and point out what should have been done differently. How can you set your team up for success from the beginning? Before even seriously considering the logistics of agile adoption, you should start looking at all aspects of communication in your teams.
The assigned ScrumMasters must have the ability to communicate and manage the team well, as well as encourage teammates to speak their minds. The agile team may need some verbal or written skills training if they are not used to informal communications via chats, email, or short documents.
All communication within the agile team must be addressed to the complete team, including sharing any documents, release plans or schedules, review requests and feedback, risks or concerns, and even leave updates. This builds a complete sense of oneness within the team and maintains complete transparency at all times.
The managers and leads must ensure open communication and healthy feedback during all meetings and also encourage team members individually to share their ideas and opinions. Likewise, the team must be receptive to constructive criticism and ready to learn from their mistakes.
Only in such an environment will the real agile spirit thrive and teams will be able to find success in their endeavors.
Pages
Read the complete article and do share your thoughts!
Working with fresh minds is always refreshing and so much fun! I got the chance to interact with some such enthusiastic and energetic people in my latest training at Misys, Bangalore. I led the QA Induction Bootcamp for the testers who were a pleasure to work with. We covered all the fundamentals of software testing, various testing techniques and practiced with some live exercises and applications. The agenda was not only getting them familiarized with the world of a software tester , but to get them to explore the amazing opportunities that lie ahead and basically start enjoying this wonderful profession. The best part was that we received some great feedback from the candidates at the end, they enjoyed the training and found it very relevant to the real experience within their teams.
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! 🙂
testwithnishi 