Finding Bugs through Psychoanalysis

Faisal Qureshi, QA Engineer, Amazon, reveals how testers can leverage developer psychology.

A developer’s psychology can play a large role in finding defects. A tester can leverage the developer’s persona, mood, current circumstances, environment, relationships with others, and intelligence, to help guide him or her as to where in the code there is a likelihood that bugs exist. If multiple developers are working with the same code base, the tester can use such information to select certain parts of the code to scrutinise more closely depending which developer was involved, based on his or her psychology and current state of mind. These factors can also allude to what type of defect the developers’ have the potential to introduce.

The method

To take advantage of the developers’ psychology and circumstances while they are coding, the tester must be highly observant of the developers during development. This is also a function of time, which means to take note of these factors each day of development and associate it with the code that was written during that day. For example, a developer may be sick one day causing lethargy, which may increase the likelihood of finding a bug in the section of code that was written by the developer during that time. Developer psychology and circumstances vary from developer to developer, so the tester must create a model for the respective developers on a daily basis. It is integral that a mapping is created for the developer on that day to the code produced by such developer. Creating a mapping table will aid for both long or short projects, in both agile or waterfall methodologies.

Figure 1. An example of a mapping table.
Figure 1. An example of a mapping table.

Scenarios

The overconfident developer

By determining that a developer is overconfident, a tester can find bugs in his or her code, as the flaws of being overconfident can be transmitted to code. The developer may think “there can be nothing wrong with my code”. As a result, the developer may neglect to test or double check the code. The tester should take advantage of this. The tester should also review the history of the developer introducing defects in previous code. Since the developer may not have tested the code before checking it in, the tester should perform full and comprehensive testing in the new code modules. Furthermore, because the developer thinks he or she is always right, he or she may also neglect to consider edge case scenarios.

The happy‑go‑lucky developer

A happy‑go‑lucky developer can be heedless, thus introducing careless errors. Due to this disposition, the developer is likely to be less critical, internally or externally. Even if all the code is functionally correct, he or she may overlook other aspects of software such as performance or security. Thus, the tester should perform various types of testing including penetration testing, performance and load testing, and compatibility testing. From the developer’s perspective, just because the code is functional, they may think everything then must be “OK”.

The unhappy developer

Whether the developer is generally unhappy, or has come out of a poor performance review with code still to write, an unhappy developer is likely to be unmotivated. 
First, this means the amount of code the developer writes will not be large. Second, it means that he or she will not care too much if the code has errors. Thus, as the developer extends his or her code base, this could be a bug farm. Even when defects are found, and the same developer fixes them, regression testing is vital.

The introverted developer

An introverted developer will hesitate to communicate with other team members. If this developer has failed to properly review the requirements, and due to his or her nature will not clarify the requirements with the other developers, functional defects can be found due to not correctly understanding what the code is supposed to do. Furthermore, by potentially not knowing the specifications, other types of defects can be manifested such as not meeting service level agreements.

The innovative developer

An innovative developer likes taking risks. He or she will attempt to implement new or bleeding‑edge algorithms. Such algorithms, due to their immaturity, may have inherit defects not yet resolved in early designs or versions. Therefore, the tester must comprehensively test against the
expected results in various conditions
as well as integration with other components. Integration testing in this scenario is
vital as the integration of new algorithms
with the existing code base may not be seamless.

Next steps

As a quality owner, it is incumbent for the tester to relay the defect information to the developer to attempt to mitigate further similar defects from the respective developers. The tester cannot change the developers’ personalities or control daily events that occur that could impact quality, but has the responsibility to put in place processes that can help avoid similar defect introduction. There may be various processes put in place to address the different developers’ psychology. In addition the tester must maintain keen awareness of the developers behaviour and the environment, and analyse what kind of code is being produced each day by the factors mentioned herein.

 

This article was first published in the July 2016 issue of TEST Magazine. Edited for web by Cecilia Rehn.

More
articles