Emotions and feelings in testing software

Software testers generally look at the requirements to figure out how the product must behave. Often these requirements cover the functional and some non-functional attributes including performance, security, some elements of usability, etc. Tests are developed with expected results that align with these product requirements. So far so good. There is a clear line from the written down requirements to the tests.

As testers, as you proceed with executing your tests, there may be instances where you feel irritated or frustrated with aspects of the software under test. You might feel a range of emotions as you test the software. At such times, what do you do ? Do you listen to your feelings or do you go with the script, merely looking for expected behavior as described in the test cases that you are executing. If the test produces the expected behavior, while you have experienced conflicting emotions during testing, what would you do ? 

As a software tester, do you need to give importance to your emotions and feelings that you encounter during testing or do you have to leave these "softer" aspects of your self outside the door before beginning a test campaign ? Is testing purely based on logic and written down requirements alone ? Is there any value to listening to what your inner "voice" and feelings are trying to say as you test the software ?

In my view, testers need to listen to their feelings while testing. That said, some testing may require you to just follow the script and stop at checking what is stated as expected behavior. However, the good news is that most testing will find feelings and emotions to be an useful added aid to the test effort. At this juncture, it helps to remember three basic concepts which are listed below.

1. Plain definition of a bug: A "bug" is something that will "bug" someone who matters . This someone could most likely be users of your software or someone significant enough to have an impact on your organization
2. Not all software requirements are written down or even stated. There is a significant number of requirements that are either left unstated or assumed or implied
3. In many cases customers may not really know all that they need from the software at the outset when requirements are being firmed up. This is especially true in the case of attributes of software such as usability

If your emotions are telling you something, listen to them. If you feel frustrated while using your software; or are feeling confused at the non-intuitive interfaces; or are tired of waiting for your software to respond or process information; or are unhappy with the workflow or any other aspect of the software and if these are not explicitly stated in your requirements, do not ignore them just because your written set of requirements do not say anything about these experiences. If you are bugged by something in your software, it is likely that users of your software could be bugged too and that can have a more serious implication.

Something with the software that frustrates or irritates you can very well irritate or frustrate your product's users. In the interests of making your software more user-friendly and intuitive, allow your feelings to ride along as you test. Report any issues you find or improvements you would like.

The other thing to remember is that issues raised based on what you feel regarding the software may not always go well with your counter-parts in development. Some issues may be accepted and fixed in the current release if these are deemed to cause significant inconvenience or loss of functionality for the users. Some issues may just be deferred to a future release and some issues may be closed as not being bugs. 

If you truly believe that a bug is valid and severe enough (a function of the frequency of occurrence and impact) to merit attention, you should have a discussion with your developers or someone who can make decisions on the bug's status. It can be a great help if you have the ability to compare your software and its behavior or interfaces with a similar application elsewhere - this could be a competitive product or a substitute-able product offering. If such an opportunity for comparison exists and you are able to show how your software is lacking, it can boost your case to have the issues fixed. Also, having a customer representative put their weight behind the issues you raise is a big push for fixing the issue. 

Ultimately, realize that some issues will go unfixed. However, your pursuit to ensure that your customers have the best possible experience while using your organization's product should continue and towards that end, keep an eye open for what your emotions and feelings are telling you as you use and interact with the software you are testing.