The Concept of the Functional Bug: Differences, the Most Common Examples

The Concept of the Functional Bug: Differences, the Most Common Examples

As we know, all bugs during the software testing are discovered when the tester responsible for the project quality begins comparing actual results with expected results.

Taking into account the classification of testing types, all bugs can be divided into different kinds according to the type of their origin. In general, they can be divided into non-functional and functional.

For qualified testing, it’s very important to differentiate functional errors from other bugs. Hence, we can give such recommendations:

  • You need to define if the system behavior of the developed function is correct under different conditions; to test function’s work in the context of the individual application and during interaction with other systems for detecting the group of potential differences;
  • We should define potential options of system application by a target group, which can say its personal preferences about the correct functioning of the developed system;
  • To test the front-end and content part of the site, because there it’s easy to find a functional defect, which somehow effects a correct work of the whole web-structure;
  • After agreeing with the client, you can add a security test to the check-list;
  • To test a system’s interaction with third-party utilities and antiviruses (they can easily block the functioning of some content part).

Consequently, we can conclude, that the functional bug is an error, which is straightly connected with software malfunction. It can be a subject to the logic of app work, separate function or the whole system in general.

Functional bug
Functional bug

According to the final aim, the functional testing can be:

  1. Based on functional recommendations, mentioned in the specification. So-called test cases are created for the maximum covering the developed product with tests. During their designing, the priority of tested functions is certainly taken into account. Such an approach allows software testing with positive and negative scripts: valid information input; invalid data input, usage of different combinations and actions;
  2. Based on business processes for which the developed product is intended. It’s very important that internal software functionality will provide the maximum correct operating from the perspective of the system appliance script (so-called “use cases”)

QA specialist has to deal with a large amount of information and data, search for the most correct variations of tasks solutions, and create new logic chains of solution search.

When you’re working on several projects at the same time, it’s very hard to keep track of all potential tests. It means that for optimization of the functional bugs search, you can follow some rules, such as:

1. You can dive into the testing on that stage when among the documentation of the project there’re first requirements about its realization. At this stage, it’s possible to build an original testing strategy, to make an extended check-lists and test-cases. Such an approach allows dealing with a lot of inconsistencies to optimize and set the test environment. Tests in the checklist should be grouped in reference to software functional logic, according to the order of created system modules. It’s better to build tests structure on the basis of the multilevel hierarchy. Such an approach in testing allows missing the least number of defects. It’s very important to avoid doubling (it often happens that because of different formulations, almost identical tests are created).

Before making a check-list for functional bugs search, you need to ask yourself such questions:

  • What exactly should be tested? – it’s important to understand what system you face on the project: to know well its functioning specifics and goal destination;
  • What group of customers is it designed for? – the answer to this question provides correct planning of tests scripts for software maintenance;
  • How will this product be used? – it’s recommended to divide the product into its components in order to have the opportunity to make quality checks in positive testing;
  • How to break a tested product? – a striking decomposition of basic tasks for negative testing aims.

2. All difficult systems should pass a hard functional decomposition. Divide it into small subtasks, which will be easy to do, in order to remember more information about future testing;

3. During the development of the testing strategy, write down all deficiencies, that you found. All issues, accumulated for some time, should be clarified by the colleagues, who are responsible for the creation or interpretation of one or another functionality;

4. Firstly, you need to do only positive tests of the most important system modules. A gradual increase in test complexity allows the proceeding to the negative uses-cases;

5. Usage of boundary conditions and equivalence classes allows overcoming the practice of test doubling.

6. You can combine positive tests. The negative test-cases combining is considered as a very bad practice;

7. Working on optimization of the first testing strategy will help to decrease costs on its implementation in future practice.

Processes of finding bugs
Processes of finding bugs

Consequently, we’ll analyze an example of a simple check-list of functional testing. We’ll test a registration module on a website.

For the registration form, you can do the next tests:

  • Correct validation of all fields mentioned in a specification;
  • Non-acceptance of special characters input in the fields;
  • Words input in the number fields – the system should let the user know about the error in filling the form;
  • Leap year validation;
  • Showing the message about symbols input limit (doesn’t the system allow inputting of 60 symbols instead of 30 ones accepted);
  • Ability to download the terms of Data Processing Agreement;
  • Ability to open a downloaded file on a local PC or portable device;
  • Cookies deleting, while being on a website;
  • Cookies deleting after visiting a website;
  • The logic of redirecting the user to the page with the bug if the form was filled incorrectly.

How Can You Know That the Found Bug Belongs to the Functional Defects?

In order to understand that the bug, you found in the system of tested software, belongs to functional defects, you should pay your attention to such recommendations:

  • You need to clarify if a created function is working as it should, or its productivity is wrong. Its work should be tested separately and when combined with another functionality of a tested product, in order to see potential differences;
  • To do the analysis of the client’s intentions, the way how developed product can work and how it works for now;
  • To find absolute evidence of the fact that a tested product functions in a wrong way. To substantiate your supervisions with the evidence, succeeded by including in a bug report;
  • An example: the logic of some online store’s work is not the same you face on a regular basis. Of course, it doesn’t mean that functionality is developed incorrectly. Probably, the client asked to program logic in this way (as he/she wanted to) on purpose;
  • Layout bugs or errors of content type are the sources of functional defect creation, and they should be reported in the context of functional bug finding;
  • Does the created functionality work in the same way with different user scripts? This means, it was so intended, and you may ask to put some changes in the product (for example, for the next users’ comfort).

Criteria for Functional Bug Severity Evaluation

During the evaluation of “hardness” level and functional bug importance, you need to take into account some factors:

  • Functional interaction of tested logic with other systems;
  • The extent of the problem from a perspective of the whole project;
  • Potential losses, that can be in the case if this error stays unfixed;
  • Comparing the bug with the defects, found before, with the same hierarchy substructure.

In practice, there’re 3 levels of functional bug criticality.

Gradation og the severity of functional bugs
Gradation og the severity of functional bugs

Low:

  • Minimal influence on the developed product’s viability;
  • The product functions not properly but it isn’t visible during its usage;
  • The bug affects only some subsystems or logical chains of programmed functionality;
  • A part of the logic is disrupted, but an easy workaround solution allows fixing such a defect

Medium:

  • Serious influence on the product functioning, but it doesn’t affect its basic functionality;
  • Make a negative effect on the interaction with a product for the huge number of users;
  • Some functionality is broken and there’s no way to fix it quickly.

Critical:

  • Found bug interferes with basic product functionality;
  • Broken logic doesn’t allow doing basic functionality, for example, to buy some goods by adding them to the cart;
  • The defect led to the company’s time losses because such bug fixing requires a number of connected seamless processes, which thwart the next product development.

All, described above, allows making a simple but at the same time a smart conclusion – the more tests are developed and released, the more chances are to find hidden functional defects in the software execution.

Leave a Reply

Close Menu