I am proud to announce another one of my contributions made its way to the eBook titled ‘21st Century Skills for Software Testers‘. This initiative was started by Emna Ayadi and Ard Kramer asking for contributions from various testers on their thoughts about the essential pivotal skill sets that benefit software testers.
🚀 This bilingual book made by software testers is all about: How we apply 21st-century skills: 🔸 Critical thinking 🔹 Communication 🔸 Collaboration 🔹 Creativity and also how we are going to use these skills in the future.
This was a great initiative to bring together thoughts of many great testers from around the globe. There are some great pieces featured and a number of things to learn. I am super excited to feature in not one but Two sections in there –
Check out what I wrote in the First section of ‘Critical Thinking’ – Section 1.1.15 ‘Stories of Testers from the Present’ and Section 1.2.8 ‘Imaginations and Thoughts of Testers’
Defects tend to cluster in some areas of the software under test. It may happen due to higher complexity, algorithms, or a higher number of integrations in a few constrained segments of the software.
These defect clusters can be tricky, both to find and to deal with. Testers need to be on constant alert for ways to isolate defect clusters and devise ways to overcome them, fight those defects and move on to new clusters.
In my article for Gurock blog, I discussed some ways to fight Defect Clusters in Software Testing:
Locating Defect Clusters
Most defects tend to cluster in certain areas of your software. It is one of the seven testing principles. Many testers intuitively know of these defect-prone areas, but we can still strive to be on the lookout for clusters of defects in a number of ways, like utilizing
Using metrics like defect density charts or module-wise defect counts, we can examine the history of defects that have been found and look for areas, modules, or features with higher defect density. This is where we should begin our search for defect clusters. Spending more time testing these areas may lead us to more defects or more complex use cases to try out.
For example, the chart below shows that Module 4 has the most defects, so it would be smart to continue concentrating on that module in the future.
Use the defect management system and the history of the software to go through older defects, and try to replicate them in the system. You will get to know the system’s history, where it broke and how it works now. You may learn a lot about the software and find many new areas to test.
A tester’s intuition, experience and history with the product is by far the best way to find defect clusters. Lessons learned by experienced teammates should be shared with new coworkers so that the knowledge can be passed on, utilized and improved upon by exercising these defect-prone areas with new perspectives.
Fighting Defect Clusters
Defect clustering follows the Pareto rule that 80% of the defects are caused by 20% of the modules in the software. It’s imperative for a tester to know which 20% of modules have the most defects so that the maximum amount of effort can be spent there. That way, even if you don’t have a lot of time to test, hopefully, you can still find the majority of defects.
Once you know the defect cluster areas, testers can focus on containing the defects in their product in a number of ways. Continue Reading—>
***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.
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.
>>>Agile testing leaves very little time for documentation. It relies on quick and innovative test case design rather than elaborate test case documents with detailed steps or results. This mirrors the values of Exploratory Testing. When executed right, it needs only lightweight planning with the focus on fluidity without comprehensive documentation or test cases.
From a QA viewpoint, we can learn from the Agile Manifesto key goals; communication, efficiency, collaboration and flexibility. If you improve your QA team in these areas, it will have a positive effect on your QA strategy and company growth.
>>>The Manifesto for Agile Software Development forms the golden rules for all Agile teams today. It gives us four basic values, which assure Agilists a clearer mindset and success in their Agile testing.
Although these values are mostly associated with Agile development, they equally apply to all phases, roles and people within the Agile framework, including Agile testing. As we know, Agile testers’ lives are different, challenging and quite busy. They have a lot to achieve and contribute within the short Agile sprints or iterations, and are frequently faced with dilemmas about what to do and how to prioritise, add value and contribute more to the team.
As testers, we all worked with Excel at some point in our career. If you are using
excel now this article is for you 🙂 Excel is used as test management, documentation
and reporting tool by many test teams. At early stages, most teams rely on excel
spreadsheets for planning and documenting tests, as well as reporting test
results. As teams grow, sharing information using excel sheets becomes problematic.
What used to be easy and intuitive, becomes very challenging. Encountering
difficult work scenarios like the below, becomes a day-to-day reality:
The simple task of figuring out which excel has the test cases you need to run, takes longer and longer.
Gathering the status of the testing tasks and your project can only be done by going to each desk one by one and asking them.
A tester mistakenly spent 6 hours running wrong tests in the wrong environment because of an incorrect excel sheet which was not the updated copy.
Tester’s routinely lose their work or test results because of saving/ overwriting or losing their excel sheets.
Most test activities are not being documented or accounted for because writing tests is considered a luxury.
If one or more of these scenarios sound familiar to you, you are being held back in
your testing efforts by excel!
In my latest guest post for PractiTest, I have written about how excel can be a roadblock instead of a useful tool for your testing. To read the complete article, click here—->
In here I talk about issues related with use of excel in relation to
I will be presenting a 90 minute- hands-on workshop on:
“Selenium with Cucumber for an extended BDD Framework”
Are you interested in looking into the trend of Behavior Driven Development? Would you like to see it in action using Cucumber? Would you like to integrate your functional tests in such a framework using integration of Selenium within Cucumber? Then this is the workshop for you!
This workshop will cover
Practical issues faced by most testing teams
Behavior Driven Development – the definition and need
Extending the Agile User stories and acceptance criteria in BDD scenarios
Cucumber as a BDD tool
Integration of Cucumber with Selenium in order to perform functional tests
Demo using Cucumber with Selenium with a real use case