Are you testing with the sole purpose of finding defects? What if you don’t find any? Your testing should deliver more value than just finding bugs. In my article published at https://blog.gurock.com/, I examined the true goals of testing and how we can aim at achieving all four of them for the quality benefits of our software.
Gaining knowledge about defects
While there is more to testing than pinpointing bugs, finding defects and problems is the first instinctive goal. Looking for places where the functionality breaks or does not work as expected is key.
Testers can adopt a number of approaches, test techniques and strategies to find these problems before users do. This helps the team keep updated on the status of product quality, fix the problems, and improve the software for the users.
If you have been testing diligently and going through a bunch of test cases and various scenarios but haven’t yet found a defect, it doesn’t mean it was all for nothing! If a test doesn’t fail, that means it passed, and that is useful information, too.
Another major goal of testing is to prove that the functionality works fine, and it is that proof that helps us make decisions about its future. Without this proof, we would never have a clear picture of the software’s quality, its intended functionality or whether it’s fit for use. Many teams would also get into problems with regulations, audits, and compliance without this proof of functionality.
Testing also generates a lot more information than just passing or failing tests. Testers generally have loads of questions occur to them while testing. They may be about the need, implementation or design of the features, their related integrations with existing features, or actual usage scenarios. The answers to these questions are paramount in making the feature assimilate well within the software.
The Ministry of Testing (MoT) is definitely the biggest and the most supportive testing community. Having heard so much about their Testbash events conducted world-wide, speaking at one was a long time goal. And I was fortunate enough to be accepted to speak at Testbash Detroit this year. But as things progressed since the beginning of 2020, travels and conferences of any kind were far from possible in light of a the global pandemic of Covid-19. Alas! our dreams were shattered. And though, it was disheartening for sure, the awesome community jumped back from the jolt and got together to bring us all an awesome online event #Testbash Home 2020.
Preparations began and I too got back to preparing my talk, which I had given up on after the cancellations! Took a couple of weekends sorting out the content and slides. Then we had a call to record the talks with the community members Heather and Diana were ever so supportive and so kind with their emails, scheduling and feedback! This was a wonderful idea to have the talks pre-recorded so that we are not hampered by any technical glitches on the event day, while we speakers get to focus on engaging with everyone and answering questions from the community.
As the day of the event approached, I prepared for my live interview. The event had more than 1000 registrations! Definitely making it the biggest audience I have ever presented to. Though the event began late night hours for my timezone, my talk was at a convenient morning hour. So that is when I joined in. Had a wonderful chat with Richard who was the Backstage boss and handling the entire livestream for the entire 24 hours! Checked on my audio & video etc and also had introductions with James who was the host for that part. And then we were live!
The duration of the talk went great. It was surreal listening to myself presenting, and looking at the live chat and questions coming from the participants throughout the talk. Once it ended, I was back live with my video. Me and James continued to discuss the most popular voted questions asked and I answered them the best to my knowledge. It was amazing to see such great comments and kind appreciation by the listeners in the chats once we were done. #Grateful
Once my talk was done, I could now continue to enjoy the rest of the live event! #Testbash Home was an absolute treat with a mix of great content, discussions, community participation, fun hosts and great conversations! It sure has set the bar really high for all online events in the future. I stayed throughout the next 5 parts of the event and only left late at night when it was absolutely impossible to keep my eyes open 😛
It sure felt like a day away from our regular stay-at-home lives, and felt like we had met up with so many people in the virtual world. Some key highlights of the day were-
Awesome talks by speakers
Black Box puzzles played live with volunteers
99 second talks with many enthusiastic participants, many of whom were presenting for the first time!
The breakout room was so much fun – where you could select your avatar, enter a virtual room and just chit chat (and play with Ralph the dogBoss 😛 )
The breaks in-between parts had the background noise of an actual conference hall with people chattering and plates clanking. It was so soothing to hear (given the times we are in!) A fantastic idea! 🙂
The hosts did an awesome job engaging everyone in informal chats, yoga, discussing shows we are watching, things we are cooking and what not. Considering that it was a 24 hour long event, it sure was a welcome change of pace every few hours.
The short intros of all the MoT community bosses was so much fun to watch and made it very relatable. Now we know the faces behind the names.
Overall, TestBash home was an awesome experience, and I was fortunate to get some great feedback for my first ever Testbash Talk! I also loved the sketch-note of my talk created by Louise Gibbs
I look forward to taking it further and engaging with this community in a live Testbash event some day! 🙂
Testers on agile teams feel very strongly about their role as customer advocate and also feel they can influence the rest of the team with their quality thinking.
Testers also need training on pair testing, working with incomplete and changing requirements, automation and all of the other new skills that are required.
Programmers also might need coaching to understand the importance of business-facing tests and the whole-team approach to writing and automating tests.
The pairing of programmers and testers can only improve communication about the quality of the product.
“One major advantage of an integrated project team is that there’s only one budget and one schedule.”
The difference between a traditional cross-functional team and an agile team is the approach to the whole-team effort. Members are not just “representing” their functions in the team but are becoming true members of the team for as long as the project or permanent team exists.
The best teams are those that have learned to work together and have developed trust with one another.
Teams work better when they have ready access to all team members, easy visibility of all progress charts and an environment that fosters communication.
Teams make the best progress when they’re empowered to identify and solve their own problems. If you’re a manager, resist the temptation to impose all your good ideas on the team.
Make sure testers are involved in all meetings! If you are a tester and someone forgets to invite you to a meeting, invite yourself!
“Courage is especially important. Get up and go talk to people; ask how you can help. Reach out to team members and other teams for direct communication. Notice impediments ad ask the team to help remove them.”
Agile development works because it gets obstacles out of our path and lets us do our best work.
This chapter is dedicated to talking about organisational problems with agile adoption, mostly from a cultural point of view- how people perceive changes, how they work, giving up control and also taking charge. It is a very comprehensive description of many problems we see on a daily basis at our work and in teams struggling with agile transformation.
Points to remember and Quotable Quotes
Agile teams are best suites for organisations that allow independent thinking.
Fear is a powerful emotion, and if not addressed, it can jeopardize the transition into agile
Testers who don’t change their approach to testing have a hard time working closely with the rest of the development team
If the organisation culture is to push towards release without caring for quality, the teams will face an uphill battle in working in agile
Companies where testers assume the role of ‘Quality Police’ will also have a challenge since teams will not buy-into the idea of building quality in, as they are accustomed to badgering it in later.
If your organisation focuses on learning, it will encourage continuous process improvement and will likely adopt agile much more quickly.
Testers need time and training, like everyone else learning to work in agile
To help testers adjust, you may need to bring in an experienced agile testing coach to act as a mentor and a teacher.
Agile focuses on working at a sustainable pace, all the time. In contrast to the ‘fast and furious’ testing done at the end of release cycles in traditional projects (often amounting to overtime). In agile, if overtime is required, it is an exception, and that too for the whole team and not just the testers.
In agile, the relationship between the customer and the development team is more a partnership than a vendor-supplier relationship.
Even if an entire company adopts agile, some teams make the transition more successfully than others.
About Introducing Change-
“Expect and Accept Chaos as you implement Agile Processes.”
Find the areas of most pain, determine what practices will solve the problem so that you can get some immediate progress out of the chaos.
The critical success factor is whether the team takes ownership and has the ability to customise its approach
Celebrate success- Acknowledgement is important if you want a change to stick.
Rather than managing the team’s activities at a low level, managers of agile teams focus on removing obstacles so that team members can do their best work
“Agile development might seem fast-paced, but the change can seem glacial”
“Beware of the Quality Police mentality— Be a collaborator, not an enforcer“
The highlight of this chapter for me was reading the ‘Testers Bill of Rights’
I had not heard about this before , so reading this was pretty cool, and for sure fundamental to any tester’s life. Check it out-
***Update **About face-to-face communication** during Covid-19 ***
As I am reading this book during this bizarre time of social-distancing, working remotely and entire nations on lockdown, the part about ‘face-to-face’ communication has a new meaning now. As Janet Gregory also pointed out in response to this article, our definition of face-to-face has changed over the last few weeks over the entire world! We are lucky to have technology that helps us continue effective communication within our teams, have conversations, video calls, screen shares, continue learning over webinars and continue working, feeling useful and being productive.
Hoping things change soon and we can go back to having fun, productive discussions with our team mates over coffee. Until then — Happy social distancing!
Reduced awareness or unintended ignorance of certain aspects can lead to inattentional blindness, or the failure to notice something that should have been visible because our attention was engaged elsewhere. As a human psychological concept, inattentional blindness also plagues testers and their mindset when testing. In my latest article for Testrail blog, I look at some steps we can take to overcome this challenge and avoid blind spots in our testing work.
It is a natural response of our brain to avoid getting overloaded with information. It automatically focuses on information that is most important while avoiding unnecessary details and noise.
In many situations, this manifests in our focus on the task at hand and its context so much that we neglect surrounding details. This is true for day-to-day activities like bumping into a pillar while looking at our phones, failing to see a swerving car when watching the road ahead… or not noticing a takeaway coffee cup in the middle of a popular television show set in ancient times!
Let’s say you are browsing through a website with the intention of looking at the layouts that must match provided mockups. While you are doing that, you may miss the following:
The homepage of the website has an older logo of the company that should have been replaced by the newer version.
The login box has username and password fields but the login button is missing.
The URL structure of the website is all wonky and the individual page URLs are not named correctly.
Testers often execute tests that have defined steps and expected results, so we frequently overlook anything that is not defined and only check for the results we’re looking for. The tester’s mind is attuned to looking for specified errors, while other information or defects may tend to get missed, even though they may be right in front of our eyes. Pick up any passed test case and try to re-execute it, but this time keep an open eye and an open mind for any new information surrounding the test. More often than not, you will find that many more defects, risk areas or questions can be found in the same area, despite the test having passed.
“Several core practices used by agile teams relate to testing.”
Programmers using TDD, code integration tests being written contribute to a successful project.
“Agile Testing just doesn’t mean testing on an agile project.”
Some testing approaches like exploratory testing are inherently agile, whether done in an agile project or not.
Testers are integral members of the customer team as well as development team
The best part of this chapter is Lisa and Janet’s wonderful stories on beginning with their first agile projects, and a realization by Janet’s co-worker, a developer in a team following XP on how they saw Janet’s contribution to the project.
“Testers don’t sit & wait for work; they get up and look for ways to contribute throughout the development cycle and beyond.”
Traditional vs Agile Testing
In Traditional approach – “Testing gets “squished” because coding takes longer than expected, and because teams get into a code-and-fix cycle at the end.
In Agile – “As an agile team member, you will need to be adaptive to the team’s needs
“Participants, tests, and tools need to be adaptive.”
“An Agile team is a wonderful place to be a tester”
The Whole-Team Approach –
“Everyone on an agile team gets “test-infected.”
“An agile team must possess all the skills needed to produce quality code that delivers the features required by the organization.”
“The whole team approach involves constant collaboration”
“On an agile team, anyone can ask for and receive help”
“The fact is, it’s all about quality – and if it’s not, we question whether it’s really an ‘agile’ team.”
I used to love books, reading was a fun and satisfying hobby for the introverted teen I was. But lately I may have gotten away from it for known and unknown reasons. I want to pursue the passion again and hold myself accountable too. So, this year I am starting a ‘Read Along’ series on my blog.
I have learnt agile testing by doing it, learning it hands-on, training & running courses on agile testing for professionals. I wanted to enhance my knowledge by reading the professional work by these awesome ladies.
So, I will be reading the book and will post about learnings, things to remember & quotable quotes from each chapter as I progress. This is to hold myself accountable, as well as to help people looking for good reads or learnings. Hope this helps you. Have you read this book? Do share your thoughts & learnings too!
Learning is an ongoing process, and hopefully a lifelong one. Being a professional in any field requires you to constantly update your knowledge and continue to learn.
Software testing is a very in-demand role, so many people aspire to get into this line of work — but they may not know where to begin.
If you are fresh out of college or looking to switch careers, even if you are not from a computing or engineering background at all, you can jump-start your career in testing. In my article published at TestRail blog, I have given some tips and advice on how to become a self-taught software tester this year.
Books provide a world of knowledge, and despite shifting trends, books can never be outdated, as older ideas can give you a foundation for new information. Reading a book allows you to delve deeper into a topic of your choice at your own pace.
Begin by searching for books on software testing, quality assurance practices, and industry leaders.
Then seek books that can help you start applying the knowledge.
If picking up a physical book is not your cup of tea, read online — there are many great portals with awesome content, articles, and ideas.
Diversify Your Knowledge
Software testing is not a singular skill; it requires a number of skills, both technical and non-technical. When beginning your quest to learn about software testing, delve into various areas of the domain and look for what interests you the most.
Testers find defects and raise awareness about quality. What happens after the bugs are found can be any tester’s guess, though. Bugs may get delayed, postponed, go unnoticed or linger on due to lack of information.
In my article for Ranorex blog, I talk about how Testers need to champion the cause of their bugs in order to avoid unneeded delays in fixing defects that are important. At the same time, testers should maintain a distance to make it an impersonal and impartial experience. Testers need to master the art of bug advocacy!
Why is advocacy important?
Advocacy is basically pleading the case for a bug to be fixed. The testers who find the bugs are the ones who need to advocate for their bugs. It is important that they take a stand and voice their opinions.
Some bugs may not be deemed important from a business perspective, as they seem too small. But in reality, they may be blocking an important feature for a particular user group. On the other hand, some bugs may seem more critical than they truly are, and while fixing them may be important, it may not be the highest of priority.
Whatever the case, testers must aim to present the facts and data in such a way that decision-makers are able to make well-informed resolutions about the issue.
Communication is key
Advocating for anything is not a one-way street. It takes discussion, debate and reaching a consensus on key points to make a collective decision. This is where testers’ communication skill plays a key role. Testers need to have good communication, both verbal and written.