Defect prediction as a test design technique

Each human being is unique and has a different personality, behaviour, and mindset. Therefore, defects and imperfections will always arise inevitably in the process of development.

Defect prediction is something that a tester performs while creating test-cases. This expression you can use to describe all test design techniques. After all, the main goal of this process is to identify the place and circumstances of the error possibility. Not less important part is to check it in the process of the testing. This particular skill is a great help to the quality assurance engineer. It is, however, not necessary to have experience in software development to predict errors. What is needed to be understood are the basic logic of coding and the requirements applying to the end product. It is also worth mentioning that having experience in similar projects will be helpful. If there is no such experience, the alternative way is to use the help from the colleges who apply this technique to daily work. Nevertheless, the best thing is to focus on those known techniques which help to achieve reliable results.

Software defect prediction as a test design technique.

Generally, not only one technique is used in the test-case creation because every method has different ways of detecting errors. Various techniques are designed for a specific task and help to find new bugs.

In addition to the rest, the predicting errors technique is also frequently used. It is the case when the tester thinks about what kinds of errors could appear in the developing process and where they come from by using intuition and experience. Therefore, this method is for the testers who have work experience and know the specific details of a particular project or even the developer. For example, when there is a developer, who is responsible for the function, is well-known for making mistakes in the sorting. Creating test cases with checking the order of the elements would be the priority in this case.

The predicting defects method is helpful in conditions where there are no requirements or not enough number of them. As well it is used when there are strict deadlines. However, this method has its own positive and negative sides.

Advantages to the predicting errors method include:

1. There is the possibility of using it on different developing levels.
2. The test-case creation is not necessary as having access to the finished product is enough for testing.
3. The method is applied when there is a lack of sufficient time.

The main disadvantage is the test coverage. It is impossible to guarantee the complete test coverage of the product functionality, even though a tester finds a particular amount of defects during the testing. For example, there might be a design bug after reducing the size of the browser. However, it does not mean that all the defects regarding the design are known. Consequently, predicting defects is usually used in combination with other test-design techniques due to a lack of complete test coverage of the product.

 Using the method on real projects

The defect prediction looks differently depending on the nature and specificity of the product. The simplest example of website testing is to find errors after disabling Javascript in the browser. Below is mentioned only a small amount of common defects found during the testing process.

Sorting. Testing this function, quality assurance engineers must consider a common mistake among the developers when the numbers «10», «11», «12»… «19» appear between the numbers «1» and «2». In this way, the array takes form like this:

1

10

11

12

...

19

2

20

That is why during the testing of the arrays like this one, the tester must avoid limiting the data range introduced by one dozen.

In keeping with the topic of arrays, should not forget that there is size sorting during the testing of online stores. It is the commonly found error where the universal sizes sorting may be performed in alphabetical order.

L, M, S, XL, …

When there is supposed to be the results in ascending order:

 XXS, XS, S, M, L, XL, …

«Everything works in my browser». Commonly the developers use only one browser due to the lack of time. This browser is also not always the priority browser's version of the project. In addition, the development usually takes place on MacOC, with the Safari browser as a standard, while the Chrome updates with a slight delay. Due to this fact, there may be errors as the various browsers process the same code differently. The best decision is to clarify the priority of every browser and perform the test-cases for all of them. It is a good idea to test the site in several browsers at the same time. In this case, it would be easier to notice the difference between them.

Neglecting the invalid data processing. It is not uncommon when the developers don't waste their time thinking through and implementing states that are impossible in their opinion on purpose. There is a need to consider people with various mindsets who will be using the end product. These people may fill in unexpectable data in the system, and that will be processed incorrectly. The main task of the tester is to predict all the actions of the user to check them in the testing process.

For example, the Ukrainian telephone numbers consist of 12 symbols, considering that the developer limits the length of the text field to 12.  However, if the text field doesn't have the prior layout (brackets, dashes), the user can fill it in diverse ways.

• 380yyxxxxxxx: The example is accepted as it was provided by the developers;
• +380yyxxxxxxx:  Because of the «+»symbol, the number does not pass the verification. The length of the field exceeds the expected one;
• 380 yy xxxxxxx: if the spaces count as symbols, there are already 14 symbols instead of 12;
• 380-yy-xxxxxxx/380(99)xxxxxxx: the same situation as the one listed above.

In connection with the number of products and approaches to software development, there can be a large variety of defects. It is worth noticing that the main advantage of the defect prediction technique is the absence of necessity to create high-level test scenarios. It is why we can use this method in the very early development stages or if there are time constraints, or even when there is a lack of the requirements.  However, the success of applying it depends directly on the tester's level of professional training.