The Psychology of Testing!

Introduction

A software tester is any human being who tests the software. So, what do you answer if anybody asks you 'Does software testing need a specialized skill'? It looks very simple to answer this question, isn't it? But ofcourse not. Software Testing is not as easy as you might think of. Needless to say, It's one of the most important and difficult tasks in the entire gamut of software development life cycle process.

Human beings reaction in this complex world of happenings varies widely with respect to situations, surroundings, emotions, need, requirements, time frame, money, visualization, belief, education, knowledge, expertise, intuition and so on. Such complex is the nature of human being and certainly there's no exception at work place too. Therefore it's cynical to say that the job being done (software testing) by a software tester is simple & complete.

Nevertheless, the quality of the job done by the software tester is directly proportional to his or her psychological maturity and profoundness acquired, adopted and developed with age and experience.

"The psychology of the persons carrying out the testing will have an impact on the testing process [Meyer 1979]."

Let's examine the psychology of the person under discussion (tester) by describing the definition of software testing under three circumstances.

1. "Software testing is the process to prove that the software works correctly"

The above definition sounds good. If the person under discussion (software tester) is the one who has developed the software he/she will try to use the above definition. This person's intentions would mostly revolve around the point to prove the software works. He/She will only give those inputs for which correct results are obtained.

This above explanation is the typical psychology of testing by a software developer.

2. "Testing is the process to prove that the software doesn't work"

This definition sounds very good especially if the aim of the tester is to prove that the software doesn't work for what it's supposed to do. This type of psychology would bring out the most of the defects in the software. A software tester should therefore have such a psychology to push the software beyond its boundaries.

Nevertheless, this definition involves a practical difficulty – If you question "how many days does the software should be tested to conclude that the software works perfectly?", perhaps the answer would again recur to be a question in itself.

It's never a right conclusion to infer that there are no bugs in the software if one says that "the software has no bugs even after testing for more than a week or a month or an year" nor it is wise to say that the software is completely reliable.

Testing does not guarantee defect less or zero bug software at all times but can only reduce or minimize known defects because the very nature of a bug can be volatile. If the above definition is to be strictly implemented, then perhaps the most Operating Systems & other Commercial Software packages which we use today would not have been in the market yet. If so, then the above definition would seem to be unrealistic.

3. "Testing is the process to detect the defects and minimize the risks associated with the residual defects"

This definition appears to sound realistic. Practically, if at any point, the software product development starts, the testing process should start and keep in track the number of bugs being detected while correcting them.

At some stage of a planned testing, there would be a stage where no bugs are identified after many days or weeks or sometimes months of testing which statistically allows you to conclude that the software is "good enough" to be released into the market. i.e there may still exist some bugs undetected, but the risk associated with the residual defects is not very high or are tolerable.

The decision to release a software may thus vary based on many other factors like business value, time constraint, client requirements & satisfaction, company's quality policies etc.

From the above three definitions, we can understand that the psychology of a software tester plays a vital role through out the software development cycle & the quality processes of software testing.

"The objective of testing is to uncover as many bugs as possible. The testing has to be done without any emotional attachment to the software. If someone points out the bugs, it is only to improve the quality of the software rather than to find fault with you."

Role & Characteristics of a Software Tester

Software Development & Software Testing go hand in hand. Both aim at meeting the predefined requirements and purpose. Both are highly creative jobs in nature but the general outlook towards these two individuals is psychological rather than distinctive classification.

If success is perceived as achieving something constructive or creative, like the job of developing a software to work, software testing in contrast is perceived as destructive job or negative job by majority of the masses. Nevertheless, software testing itself has to be perceived as an equally creative job on par with the development job, but this perception can only be practically possible with a different outlook and mindset.

Software Testers require technical skills similar to their development counterparts, but software testers need to acquire other skills, as well.

• Keen Observation
• Detective Skills
• Destructive Creativity
• Understanding Product as integration of its parts
• Customer Oriented Perspective
• Cynical but Affable Attitude
• Organized, Flexible & Patience at job
• Objective & Neutral attitude

Keen Observation – The software tester must possess the qualities of an 'eye for detail'. A keen observation is the prime quality any software tester must possess. Not all bugs are visible clearly to the naked eye in a software. With keen observation, the tester can easily identify or detect many critical bugs. Observing the software for established parameters like 'look & feel' of GUI, incorrect data representation, user friendliness etc needs this type of characteristics.

Detective Skills – Ideally the software under development would be documented before, after and throughout the development process. Unfortunately, there is every chance of not updating the documentation (specification, defect reports etc) due to time and resource constraints.

The software under testing would be completely described in a well defined set library of functions and design specifications in documents called specs or SRS etc. which needs constant update. The tester should therefore apply his knowledge of rationalization in knowing about the product from formal system like system specifications, design & functional specifications. From this information, the tester should look for researching more analytical information through other sources called non-formal sources of information like developers, support personnel, bugs and related product documents, reviews of related and (seemingly) unrelated documents.

A tester should therefore possess the quality of a 'detective' to explore the product under test, more rationally.

Destructive Creativity – The Tester need to develop destructive skills – means skills to perturb and crash the software workflow and its functionality. In other words, the tester should 'not hesitate to break the software' fearing to buy it or being empathetic to the creation of developers. In software testing, boundaries are meant to be crossed not obeyed.

A creative oriented but destructive approach is necessary while testing a software by the tester to make the software evolve more robustly and reliably.

"The Software under test should be tested like a Mercedes-Benz car. "

Understanding the Product as an integration of its parts – The software(read as product) is a culmination of lines of code interacting with data through user interface and database.

It is an integration of separate group of code interacting with other groups assembled together to function as a whole product. The developers might be working on a respective piece of code module focusing more on those modules under work, at a time.

It is no wonder if the developer sometimes may not even know the complete workflow of the product and not necessary too. Where as, in the case of a tester, being the rider of the software under test, should understand and know about the complete specifications (operational and workflow requirements) of the product.

The tester may not be the best expert on any one module of the software but definitely he/she should gain expertise on the overall operation of the product. In fact, the tester should possess a 'Systems' view of the product because they are the only people to see and test the complete functionality of interdependent modules and compatibility between the software and hardware specifications laid down by the client before it is sent to the customer.

Customer Oriented Perspective – Testers need to possess a customer oriented perspective. Customers (read as users) need not be as wise as software engineers or testers. As the number of computer users are growing every day (need not be as wise as engineers or testers), the end-users may neither be comfortable nor tolerate any bugs, explanations, or frequent upgrades to fix the bugs. As any customer would simply be interested in consuming the product (software) by deriving its value the software tester must adopt a customer oriented perspective while testing the software product.

Hence the tester must develop his abilities to suffice himself/herself in the place of the customer, testing the product as a mere end-user.

Cynical but Affable Attitude – Irrespective of the nature of the project, the tester need to be tenacious in questioning even the smallest ambiguity until it is proved. In other words ,the tester must chant the words "In God we Trust- Everything Else gets Tested" throughout the testing cycle.

There may arise some situations during the course of testing – large number of bugs might be encountered unusually which might compel to further delay in shipping of the product. This may lead to heat up the relation between the testers and other development teams. The tester should balance this relationship not at the cost of the bugs but by convincing and upholding their intentions to "assault the software but not the software developers".

Organized, Flexible and Patience at Job: Software testers must remember the fact that as the world is shrinking since the advent of internet and web, so, change is very dynamic and no exception for modern software. Not all the tests planned are performed completely and some tests dependent on other tests has to be blocked for later testing.

This needs an organized approach by the tester in attempting to phase out the bugs. Sometimes, significant tests has to be rerun which would change the fundamental functionality of the software. The tester should therefore have patience to retest the planned bugs and any new bugs that may arise.

It is even more important to the testers to be patient and keep prepared in the event of a dynamic development and test model. Development keeps changing continuously as requirements and technology keeps changing rapidly and so should testing. The testers must take these changes into account and plan to perform tests while maintaining the control of test environment to ensure valid test results.

Objective and Neutral Attitude – Nobody would like to hear and believe bad news, right? Well, testers are sometimes viewed as messengers of bad news in a software project team. No wonder, how good the tester is (meaning very negative) and brilliant in doing his job (identifying bugs-no one likes to do it but most human beings are taken for granted to be naturally very good at it, at least from childhood), he/she might always be a messenger of communicating the bad part of the software, which, the creators (developers) doesn't like it.

"Nobody who builds the houses likes to have them burned."

The tester must be able to deal with the situation where he/she is blamed for doing his/her job (detecting bugs) too good. The tester's jobs must be appreciated and the bugs should be welcomed by the development team because every potential bug found by the tester would mean a reduction of one bug that would potentially might have been encountered by the customer.

Irrespective of the negative aspects of doing such a highly skillful job, the role of a tester is to report honestly every known bug encountered in the product with always an objective and a neutral attitude.