Posted in Manual Testing

What is defect triaging?

Defect Triaging is a formal meeting where all the defects of the current Sprint are discussed and triaged i.e. Prioritized based on its severity, frequency, risk, etc.

The defect triage meeting discuss about if defect is valid or user error. If the defect is considered as valid defect then the next question will be is this defect reproducible? If it is inconsistent then that will be assigned for thorough analysis.  If bug is reproducible then comes next question is this defect worth of a fix? i.e., how much it impacts the business of the client. If the impact is low then it will be deferred to next releases or bug can be closed. If the impact is high then that will planned for the immediate releases and assigns to the developer to provide fix with defect status as “Assigned”

Posted in Manual Testing

How do you analyze the root cause of a defect?

Root cause analysis is used in software testing to identify defects. That means you can find the cause of software defects before your customers find bugs. 

You’ll usually find three basic types of causes Physical, Human, Organizational. The Root Cause Analysis Process has 5 steps

1.       Define the Problem

  • What do you see happening?
    • What are the specific symptoms?

2.       Collect Data

  •  What proof do you have that the problem exists?
    • How long has the problem existed?
    • What is the impact of the problem?

3.       Identify Possible Causal Factors

  • What sequence of events leads to the problem?
  • What conditions allow the problem to occur?
  • What other problems surround the occurrence of the central problem?

4.       Identify the Root Cause(s) – During this stage, identify as many causal factors as possible

  • Why does the causal factor exist?
    • What is the real reason the problem occurred?

5.       Recommend and Implement Solutions

  • What can you do to prevent the problem from happening again?
    • How will the solution be implemented?
    • Who will be responsible for it?
    • What are the risks of implementing the solution?
Posted in Manual Testing

What is a change request and how does a change request get handled?

If your company is using Trello for project management

  1. Try creating Change Request Flow(plan, protocol). Agree with the client on the steps which are going to happen each time they request a new change. E.g. if they request a new feature, the feature will be included into the next iteration/sprint.
  2. Try to systematise their requests. If they want to add a new button to the existing page, create it as a separate card, not as a comment. If they ask for numerous copy updates, put down these requests to a separate “Copy updates” card.
Posted in Manual Testing

When does a defect gets rejected by the developer?

The mains reasons for bug rejection are

Non-reproducible bugsdefect has not reproduced on developer pc, i.e a defect coming on your pc does not happen in developer pc’s

Test environment – mismatch of browsers, devices, or configuration of your application with developer.

Duplicate bug – Someone else has already reported the same bug 

Misunderstanding the requirements – For any reason, if you did not understand the requirement properly, you would definitely look out for the misinterpreted requirement in actual implementation and when you would not find it, it would be a bug according to you, which will finally get rejected

Change in requirement – When testers are not communicated about requirement changes, more bugs will be reported and ultimately rejected.

Test data used – Test data used for testing was mismatching with a requirement

Improper bug description – If developer does not find proper description and required details in bug report, no matter how critical the bug is, it is expected to be marked as Rejected.

Posted in Manual Testing

How do you deal with an inconsistent defect?

Inconsistency defect is nothing but the defect which is not stable, a bug which is not reproducible while retesting i.e. the defect is valid but it’s not reproducible always. For example, observing an issue whole day and at the end of the day when you reported that defect, you find it’s no more reproducible.

Here are the steps to reproduce defect

  1. Include exact data used during testing for easy reference
  2. The steps have to be in the exact order
  3. Mention pre-requisites when applicable
  4. Always recheck your steps to reproduce on a new system, clearing all cookies and cache memory