Lecture
The psychology of software testing refers to the study and application of psychological principles and methods in the software testing process. It focuses on the psychological aspects of the interaction between testers and software, as well as the influence of psychological factors on testing quality.
Here are some key aspects of the psychology of software testing:
Perception of errors: Psychology studies how people perceive and interpret errors during testing. For example, some errors can be easily detected and fixed, while others may be more hidden and require deeper analysis.
The human factor: People who do software testing can experience various psychological factors, such as fatigue, habituation, motivation, and level of concentration. Psychology studies how these factors can affect testing results and how to manage them in order to achieve optimal results.
User experience testing: The psychology of software testing also studies how users interact with software and how their psychological aspects, such as expectations, preferences, and reactions, can affect the testing process and the product's final quality.
Emotional reaction to errors: Sometimes testers may experience an emotional reaction upon discovering errors in software, especially if those errors are critical or could lead to negative consequences. Psychology studies how to manage this emotional reaction and maintain a positive and productive approach to testing.
Stress and stress management: Software testing can be a stressful process, especially when working with tight deadlines or complex tasks. Psychology studies the stress factors associated with testing and offers methods for managing stress to improve efficiency and the quality of work.
A testing specialist should have a mindset different from a developer's. Although programmers can test their own code and the functionality of the system themselves, independent testers carry out testing because people tend to misjudge their own work. Thus, a tester who possesses a certain degree of independence is usually more effective at finding defects and failures in the system than the programmer. It's important to note that independence does not replace knowledge — certain tasks, such as unit testing, which requires an understanding of a program's internal structure, are easier and faster for programmers to perform.
There are a total of four levels of independence – from low to high:
1. the tests for a program are developed and run by the person who is its author;
2. the tests are developed and run by other people (for example, by another developer);
3. the tests are developed by representatives of another organizational group (for example, from a testing department) or by specialized testers (for example, performance or security testing specialists);
4. the tests are developed and run by specialists from another organization (for example, an outsourcing or auditing firm).
By the very nature of their work, testers evaluate other people's work and find shortcomings in it, which is often perceived as a destructive activity, despite the fact that its result is the correction of errors and the improvement of the product's overall quality. A good tester needs to have a number of personal and professional qualities: they should be curious, critical, attentive to detail, communicative, maintain professional pessimism, and have enough experience to build hypotheses about possible sources of errors
A tester, unlike a programmer, whose main goal is to create a working product, must be able to find all the shortcomings built into that product. And to do this, we must, first and foremost, concentrate on what can go wrong. Studies have shown that if the person testing a program perceives it as working correctly, they will find fewer bugs than someone who is convinced it contains a multitude of shortcomings. That's why a tester should always remember that “Software has bugs”.
And lastly, one more important point: when writing a defect report, be objective and never, under any circumstances, point — explicitly or implicitly — to who is at fault, even if they fully deserve it. Remember, you still have to work with the programmers, so it's not worth spoiling the relationship.
Here are a few simple tips for improving communication with colleagues:
The psychology of software testing helps to gain a deeper understanding of the interaction between people and software in the context of testing. This allows developers and testers to take psychological factors into account in order to improve the testing process and software quality.
Few people outside the IT industry have a clear idea of what software testers actually do. But even among those directly involved in software development, misconceptions about the work of quality assurance specialists are common.
There are several common myths and facts about software testing. Here are some of them:
Myth 1: Testing guarantees error-free software.
Fact: Testing helps to detect errors and defects in software, but it cannot guarantee that all errors will be found. Testing is an iterative process, and some errors may go unnoticed or only show up under certain conditions of use.
Myth 2: Testing is a simple task that anyone can do.
Fact: Quality testing requires certain skills, knowledge, and experience. A tester must have an understanding of the technical aspects of software, testing methodologies, and the use of the appropriate tools. Testing also requires analytical thinking, a creative approach, and the ability to search out hidden errors.
Myth 3: Testing can be carried out at the very end of development.
Fact: The earlier testing begins in the software development life cycle, the easier it is to detect and fix errors. Testing should be integrated into the development process starting from the early stages, in order to reduce risks and improve product quality.
Myth 4: Automated testing completely replaces manual testing.
Fact: Automated testing is a powerful tool, but it cannot completely replace manual testing. Manual testing involves expert judgment, intuition, and the ability to spot problems that automated tools might miss. A combination of automated and manual testing is usually the most effective approach.
Myth 5: The goal of testing is to prove that the software works correctly.
Fact: The goal of testing is to find errors and defects in the software, not to prove its correctness. Testing helps identify problems and improve product quality. Software can be considered successfully tested when certain quality criteria have been met and risks have been reduced to an acceptable level.
Myth 6: Testing is too expensive
Fact: As the saying goes: «If you don't want to pay for testing during development, you'll have to pay for tech support and fixes after release». Early testing helps save money, while refusing or neglecting testing can have the most unfortunate effect on the quality of your product.
Myth 7. Testing takes a lot of time
Fact: Testing itself (provided the production processes are organized competently) runs in parallel with development, so talking about time spent specifically on testing is a bit of a stretch. The truth is that fixing errors found during testing takes time and effort – but the result of that effort will be an improvement in product quality.
Myth 8: Only finished products are tested
Fact: Of course, testing depends on the code that's been written. But there's also requirements testing and the creation of test artifacts, which can be carried out even before a finished version of the product exists. What's more, in the iterative development model, the testing and code-writing processes are fairly independent of each other.
Myth 9: A program can be tested completely
Fact: The problem arises when the client or project manager thinks this way. This claim directly contradicts the second principle of testing, so yes, you can run a great many tests and provide full functional coverage, but that still won't mean the software has been tested completely. There can always be a bug you missed. That's why exhaustive testing is impossible – we can only bring the quality of the system up to an acceptable level.
Myth 10: Testers are to blame for missed bugs
Fact: It's wrong to blame testers for bugs that remain in an application even after a full testing cycle has been carried out. The problem here lies in tight deadlines, development costs, and frequently changing requirements. Testers, like other participants in the development process, are often limited in time and resources, which affects the quality of their work. That's why priorities need to be set here.
Myth 11: Testers are responsible for product quality
Fact: This is a very common misconception. Testers' responsibilities include finding bugs and passing information about them on to the people involved in the development process who have a stake in it, after which the latter decide what to do with these bugs – whether they'll be fixed or postponed.
Myth 12: A tester's only job is finding bugs
Fact: From the previous sections, you should already understand that this is far from true. While developers, as a rule, work within a fairly narrow functional area, testers need to understand the organization of the system as a whole. Moreover, in modern conditions testers often take part not only in testing as such, but also in quality assurance processes.
Myth 13: Anyone can test software
Fact: People outside the IT industry often think that anyone without special training can test programs, and that testing is work that doesn't require any particular knowledge or creative approach. Be that as it may, testers know perfectly well that this is a myth. Today, to become an in-demand specialist in the field of software testing, you need to have a sufficient level of training, be familiar with current trends in the development of information technology, and possess the personal qualities the profession requires. A good tester, besides the testing field itself, should know the basics of programming and have command of English at a level of at least Intermediate.
Myth 13. Product testing, software reliability assurance, product quality control, and product quality management are all the same thing.
There are significant differences between them
Conclusions
It's important to have a correct understanding of testing in order to use it effectively and achieve optimal results in software development. But even if you're missing something from the list above, don't worry. This can easily be fixed by taking courses and independently and comprehensively studying the necessary material while practicing. Beyond thorough theoretical preparation, from the very first weeks of study you also need to take part in real projects and gain genuine work experience.
Comments