Software Quality Gifts
gift - noun
Definition:
- something voluntarily transferred by one person to another without compensation
- something bestowed or acquired without any particular effort by the recipient
I frequently find myself surprised by happenings in the world of software development. New technologies find their way out of the limelight and become old technologies. Old technologies somehow become the latest and greatest thing again. We find a new way to implement our processes in order to make them more useful. We learn better ways to manage teams or be part of a team.
My most recent surprise came in the form of what we, as software testers, receive from the world around us for free that helps us do our job better. The things we receive intentionally and formally (not for free) are requirements, feature branches for early testing, test files, wireframes, and prototypes…to name only a few. We have so many formal ways of obtaining information on a feature or a change, but the informal ways are where we learn the unexpected.
What has been gifted upon us that has a valuable impact on our testing process?
The first gift is bugs. Software bugs are clearly undesirable, but also they are inevitable. We never want to see a bug, but given that they will occur, let’s make something of them.
The most obvious benefit we can take from a bug is that is demonstrates something we missed in our testing and planning. We can take this missed validation and ensure we have future test coverage for it, but also to determine if there is a commonality in other tests where this type of bug could occur. We can now not only inject that information into our testing and planning but also into our requirements discussions and development implementations.
Bugs can also uncover if something was designed differently than how it was expected to be used. An intentional design or implementation decision can be interpreted by a user as a bug if it prevents them from doing something a certain way, or at all. These bug reports are extremely useful in helping testers do more exploratory testing in order to branch out in our expectations of how something should behave.
Bugs spark interest in a tester and help us think outside of what we already know.
The second gift is seeing others use the product.
We can become quite habitual in how we use a familiar software tool. I myself am a “keyboard person.” Give me all of those keyboard shortcuts! Even when I branch out to using the mouse, I still find myself using muscle memory for each action I take in our software. We have testers who we know are more keyboard-focused or more mouse focused, and we capitalize on that for test coverage.
However, these are the things that we know. And if we have our habits, then our users certainly do, too…only we don’t know what those habits are.
How a user gets to the end of what they are trying to achieve in our software is infinite. Users could be methodical and direct or very scattered. They could be very heavily focused on one feature or area of the product. They may have their screen configured in a totally unique way. All of these different elements of use are great inputs into use cases, usability, and general testing.
Most of these things are not and cannot be documented because they are nuanced and may be combined differently from one time to the next. The key is to see these actions as they happen and to watch the user and see this uniqueness in real-time.
There are infinite takeaways from watching how users physically interact with our software, and these takeaways have a clear and positive impact on our testing, planning, and automation.
The third and final gift is experts.
We have at our disposal an array of product experts in our Designers, Product Managers, and Developers. These internal experts are the people who are the most closely involved in our products, with our users, and in our market. These are the individuals who can answer our questions and can go further in-depth about how something is intended to be used or not used. These are the people we can discuss and debate UX with, who can help us develop more effective test cases, and who can explain the minutia of each feature and its functionality. These are also our most trusted team mates who want to ensure that our test coverage is as effective as it should be.
Product Managers and Designers are the closest individuals to our users. They have the most experience with what the market wants, and they add so much more to the creative process than simply requirements and prototypes. There is no substitute for real-world feedback because we are creating our products for the real world. We should be taking full advantage of their knowledge and expertise by integrating them into test plan reviews and by enabling a clear and open feedback loop on our testing.
Developers deal with features and functionality at the micro level. Every day they dig deep into features and their implementation and can provide technical direction for how we test and automate along the way. Developers want their work to be bug-free and thoroughly tested, so their input is well-intended and highly useful. Here as with Product Managers and Designers, the feedback loop should be clear, open, and transparent.
We have so many intentional inputs into software development such as requirements, user stories, and designs. These inputs are common to virtually every development organization. We will extend our means to effectively test and plan by taking in and utilizing the unexpected and free gifts that we have available to us on a regular basis.
The beauty of these gifts is that each one can spark new ideas which in turn can lead to more effective exploratory testing and better test coverage. All of this will help us create better software with excellent quality, and better experiences for our users.
