I am working on this ticket created by a fellow QA Tester. The ticket requires a notification message with a link to be created. Our developer worked on it and acceptance test was met. However, upon checking I noticed a UI issue concerning the text alignment of the notification message.

Now I am confused if I should pass or fail the ticket. I came up with two options:

First, fail the ticket altogether even though it has passed the acceptance test since the new UI issue is part of the notification message created.

Second, pass the ticket and create another ticket for the new UI issue.

I am thinking of going with my first option since it can be easily fixed by the developer who initially worked on it. But I am not sure if that would be okay because the original acceptance test passed.

Can you advise how to handle this issue?

Thank you.

  • 1
    Maybe fixing that issue would take just a second... Maybe effort required to update ticket or create a new one is too high comparing just contacting that developer and asking him to fix that?
    – dzieciou
    Jan 11 '13 at 6:42
  • unfortunately, i work offshore and have to wait one whole day to get a response from out development team. we might lose track of this minor issue if I don't make a record in our bug tracking tool. In this case, do you think I should just fail it? Jan 11 '13 at 6:46
  • 1
    Since it is you who will be keeping track of this minor issue, then contacting the developer and waiting the 24 hrs for the reply should be fine. If you email, make sure you say that if you don't hear from them by a certain time, you will report a new bug (for example). That way you don't need to keep chasing for an answer.
    – SheyMouse
    Jan 11 '13 at 8:36

What does "acceptance test was met" imply in your shop?

In some shops "acceptance" means the owner/end user/relevant stakeholder has deemed the software sufficient (not perfect, but good enough). Further, in some shops this implies that no further funding is authorized for the project. If this is the case in your shop, then your only option may be to "close" the ticket.

If I were verifying the ticket, I'd likely choose the second option ("pass the ticket and create another ticket for the new UI issue.") Clearly the change met someone's acceptance criteria, yet you still see a potential issue worth pointing out. That issue may be fixed now, deferred to a later date, or simply rejected as "good enough", depending on the stakeholders' view of the issue.


There are several possible outcomes:

It's a QA process for you, not you're for the QA process. As @dzieciou noticed, if you think that solving the problem would be faster by just picking up the phone and speaking to the developer, it worth trying. In case if the developer says, oh yes, I'll do it at once - the problem is solved. However, the developer may be busy right now, and you have to follow the common defect lifecycle.
(update) Since you are working remotely, by all means, it's much better to follow the standard QA process in a written form.

Testing is actually a process of comparison between the actual functioning of the program and the formal documentation. It is possible that the specification is incomplete and should be improved. Depending on your mutual agreement, it may be either the same issue updated or a new one created, and it also may affect other project-related artifacts.

Often, creating UI-specific defect may be preferable since issue tracking systems have extra fields that are specific for UI problems, e.g., screen resolution, Web browser (for Web apps), zoom level, and so on.


It often happens that notification popups/balloons/components are reused across whole application. Hence, a defect you have found may appear in other part of the application. I would try to confirm that first (e.g., by checking other pages and talking to your developers how components are used), and if so then the issue may need a separate defect.

However, if the issue manifests only in this place, then probably the effort to fix it and re-test, and the impact it has, might be little comparing to the effort of creating a separate ticket. If so, you may consider (e.g. if you work together with developers) asking a developer to fix it without reporting the issue.

Still, if similar issue occurs in one place and does not occur in another, I would be more suspicious about similar issues for UI components, since it might look like components were not styled by developers with re-usability in mind. You may consider discuss/signalize this too to your developers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.