The world as we have created it is a process of our thinking. It cannot be changed without changing our thinking.

Albert Einstein

In this post, I will explore the use of different perspectives in any testing activity. Here, “perspective” means a tester’s behavior, thinking, or mood while designing the test cases of any software application.

Accept it or not, while the importance of the tester role in any software project has been quite well accepted, the effect of switching between different moods while designing tests is only recently being exercised by companies. This means that the traditional way of designing tests still occupies the biggest slot in any software testing activity.


During the software testing training that I deliver, and as all other lecturers might do, I teach test design techniques such as requirement-based testing, risk-based testing, use-case testing, defect-based testing, structure-based testing, etc. When we analyze these techniques, we observe that there is and should be a basis for any test design activity. While you are designing your test cases, whether you are referring to a requirement specification, a risk charter, a use case, or a control flow diagram, you need to have a solid test basis. In this manner, we can regard test cases as real-life reflections of any software specifications.

Other than that, I always teach people to utilize their experiences while they are designing test cases. Not all companies are keen on preparing requirements, use cases, control flows, or checklists; most of the time they have time-to-market focus, give you a semiworking untested product, and ask you to use that product as your test basis. In other words, your test object becomes your test basis! In such cases, you need to base your test design more on experience than on any other nonexistent/fictitious software specification.

In any case, whether you have strong test basis or solid experiences, I suggest that you think differently (change your mood) while you are designing your cases. Do not limit yourself with any analysis or design-phase work products. Don’t forget that not all test cases should be objectively generated; some should be intuitively written. In my view, a good tester is the one who better and more smoothly blends structural techniques with experiences. In other words, if you want to design better tests, you need to:

–      Think positively

–      Think negatively

–      Think as a novice user

–      Think as an expert user

–      Think objectively

–      Think intuitively

–      Think as a hacker

–      Think as a fan

–      Think process-wise

–      Think creatively

–      Think as a developer

–      Think as a business analyst

–      Think as an upper manager

–      Think as a competitor

–  (You may add some more perspectives here)

Changing your mood and thinking while you are designing your test cases brings numerous benefits such as unbiased testing, better test coverage, and a more enhanced view. It also creates a better environment for testers to improve their testing skills and may end up resulting in better software applications and better software testers.

Do not forget that real testing requires thinking and mental work. If you set many patterns into your test design and impose only structural techniques, your testing may become an autonomous activity like a checker’s daily routine work. Without a creative touch and critical thinking, testing becomes dull and limited. Moreover, you will definitely have undetected bugs if you just do checking.

From this perspective, if you are a tester, thinking matters a lot. It doesn’t matter that much if you are a checker.