It's Not a Bug, It's a Feature: How to act like an experienced QA engineer

Hello, I have been involved in testing since 2020, growing from an intern to a senior testing engineer and experiencing a lot along the way, from being the only tester on the team to stressful situations where every minute counts. The hardest times were when I didn't even realize I was acting incorrectly.

Today, I will discuss 6 cases that every QA professional encounters from time to time. These cases may seem simple at first glance, but it becomes clear that they lead to unexpected problems, the ignorance of which can greatly complicate testing, and in the worst case, lead to release issues.

Some situations are described in a specific context for mobile testing. It won't be a problem to adapt these cases to your work processes, but I believe it's worth mentioning upfront.

Situation 1 - New Bugs

A fix for a bug has come in for testing. You test it, the main bug is fixed, but you find two or three other bugs that weren't there before. What to do, what status to assign to the main bug, where to put the new ones?

• First of all, in such a situation, it is worth noting that new bugs have appeared. It is better to create separate tasks with the type "issue" rather than writing bugs in the comments.

• After that, depending on the severity of the current bug and any new ones, you make decisions. This depends on the processes adopted in your company, but here are possible solutions:

  
  

  • Remember, product degradation is undesirable, and most likely, the initial bug should be reopened.

    
    

  • It is permissible to accept the current fixes and postpone fixing the new bugs to the next release if the initial bug has high severity and priority, and the new errors are minor.

    
    

  • Sometimes, situations occur where fixing one bug leads to another. This happens when integrating with external systems - in such cases, it is necessary to decide which of the problems has less impact on users and not fix it. Don't forget to also notify the developers of the external system about the problem or raise a discussion about the need for your own solution.

    
    

• Everywhere, when making decisions, rely on the processes in the company and on the responsibility that you can take individually. Most likely, to make a final decision, it will be necessary to discuss this with the product manager and the testing lead.

Situation 2 - It's Not a Bug, It's a Feature.

You've brought a bug to the developer, and they insist that it's not a bug because they intentionally designed it that way.

• First, compare the expected result with the task requirements.

• If there are no requirements, it's worth clarifying the correct behavior with the product manager or the UI/UX designer, depending on the logic of the issue.

• Even if the requirements state that it's not a bug, you can disagree with them for objective reasons. For example, competitors might have different behavior or such behavior may seem illogical or contradict the business logic of the application. In such cases, bring up this issue for discussion with the product manager.

  
  

Remember that bugs are found not only in the code but also in the documentation and design.

Situation 3 - Requesting Permission at Startup.

In the calculator app, a scanner for mathematical formulas is being integrated, so a task has been brought in for testing, stating that now at the start of the application, permission to access the camera will be requested.

• QA should not only test tasks but also ensure quality, and quality also encompasses user experience. It is necessary, at the very least, to show the risks of such a decision, as most likely users will close and uninstall our application upon seeing such a request at startup.

• As a second step, suggest the right solution - move the access request to the functionality activation point, since such a request will be more understandable and expected by the user than the request when starting the application.

• In the guidelines of app stores, there is a requirement to explain to the user why a specific request is needed before making the request, or the request itself should occur within a clear context. If such an explanation is absent, the application is likely to be rejected from release by the app store.

  
  

  • Android Request runtime permissions | Android Developers

  • iOS Privacy | Apple Developer Documentation

    
    

• Even if the product manager has accepted the risks and insists on releasing as is, you need to make sure that A/B testing will be done or suggest A/B testing to reduce the likely negative impact of the new functionality or ensure that it will not happen.

Situation 4 - Dangerous Permissions

The manager realized that permission requests are made where the feature is launched. Now, it has decided to add the ability to install your other applications directly from the calculator, so it adds a permission request to install apps.

• The permission to install applications from Google Play is considered sensitive, and special criteria must be met to add it. Without this, an application with such permission will not be allowed to be released.

  
  

  • Don't miss other sensitive accesses that can be added to the application. Read about sensitive permissions and requirements for them here: Permissions and APIs that Access Sensitive Information - Play Console Help

    
    

  • In iOS, such permission does not exist, however, it is worth studying Apple's policy on other sensitive permissions as well: Protecting the User’s Privacy | Apple Developer Documentation

    
    

• Study the guidelines of the stores where the application is being placed, otherwise, you will undoubtedly encounter problems during release.

• Offer solutions that do not require special permissions from the user. In this case, suggest an alternative - instead of direct installation, provide links to the applications in the official app store.

Situation 5 - Tomorrow's release, but Nothing Is Ready

Your mobile application's release is scheduled for the day after tomorrow, and in just four days, there's a launch that cannot be postponed. The functionality in the application is ready for testing, but the backend will only finish support after the release. What to do to ensure a successful launch?

• Here, remember about mocks, test the functionality by replacing request responses through a traffic sniffer.

• Make sure that the functionality will correctly handle the lack of a valid response from the backend until it is ready. Ideally, close the feature enablement with a switch from the backend.

• Before launching the feature, once the backend is ready, double-check that the new functionality works as expected.

• If there is more time between the release and the launch, consider waiting for the backend and making an unscheduled release. In this case, consider that the review process in the app store takes time, and factor it into your plans.

Situation 6 - Avoid Unnecessary Requests

You've found a bug - extra requests are being sent during actions in the application. You're unsure of how critical this is, but since the application is functioning correctly, you assign a not-high severity to the bug and release the application calmly. The next day, the backend of the application crashes under heavy load from requests.

• Don't turn a blind eye to performance issues, especially if you have a high-load application. Extra requests lead to potential backend and application performance problems.

• Even if the requests aren't unnecessary, if you notice that the same object is requested every time a screen is opened, clarify whether it's necessary, or if it can be cached.

• If there are doubts about the severity of the bug, prioritize it higher than you want. It's better to err on the side of caution and highlight the problem. You can always lower the priority, but missing a serious bug is costlier.

General Recommendations and Conclusions

• In any unclear situation, try to make it clearer - seeking advice, clarifying, coordinating, and arguing with the team is perfectly normal. Communication is the key to resolving complex situations.

• Seek a compromise between product quality and business objectives. Your task is to identify and point out problems. You cannot just say, "I won't test without a backend, and that's final."

• Do not leave bugs unreported. You can change the priority or reject a bug at any time. A seemingly minor bug at first glance may conceal serious issues.

• Know and study platform guidelines. Notice if any areas in your application violate them. Even if your application has passed review in app stores this time, it may not pass next time.

• QA is not just about testing, it's also about ensuring quality at all stages of product development. Product quality itself is not just about the absence of bugs but also about user experience, timely releases, and performance.

Share interesting and challenging situations from your experience and propose other solutions to these problems. Looking forward to your comments!

Thank you for reading through! Let's stay in touch: feel free to message me on LinkedIn and subscribe here.