3

For an example, In a testing phase if i got a defect which is due to some delayed job restarting,can I raise it as a bug? In our project,devteam merges and deploy their codes into test site. usually there occurs some issues which is due to not restarting a delayed job. We used to log it as a bug. but development team prefer to rectify the issue with out raising it as a bug .In fact they are some what disturbed when QA team raise a bug which is not due to code issue :)

So i need to know whether its a good practice to raise a bug which is not due to code issue

Improve this question
1
  • This is actually a good question. Would you mind giving us a little bit more information, for example; The software you're testing is behaving out of the specification when this job is "down" or "not restarted" ? What's the expected behavior of the code you're testing when the job is in this state ?
    – Machado
    Jan 9, 2017 at 13:23

4 Answers 4

Reset to default
8

On the one hand, the developers want bugs that are in the code that need to be fixed.

On the other hand, how is QA supposed to know whether it's code, data, scripts, or human error? QA knows that it doesn't work. QA reports that it doesn't work. What happens if it appears to be because the delayed job wasn't restarted, but it was in fact a bug in the initializer of the delayed job? QA isn't equipped to figure that out.

It's not QA's job to figure out the problem or solution. QA's job is to find the problem, and find the conditions that cause the problem, then communicate their findings. It's the job of the Product Manager to assign it to the appropriate person to fix it, be it a developer, DBA, systems administrator, or gopher.

So yes, you should raise a bug. It's not working, that is all you know. Whoever is doing the deployment should create a script to automatically restart delayed jobs when deploying. The fact that they don't, or that it isn't working, is the bug here. OTOH, if it's a problem because the job is in the process of restarting, the bug instead is that it isn't providing sensible feedback to the user ("Please Wait...").

Of course, if your boss says that you shouldn't be raising a bug, then don't. Your boss is the ultimate authority, not some random strangers on the internet.

Improve this answer
1

Repeatable processes in/around your system are just as critical as the "code". Your deployments should be repeatable and require minimal manual effort. This helps ensure that your production deployments go safely also. If this process doesn't work, that is just as much a bug as any coding error.

When devs hand over the system to QA, it should just work. No special magic required. I that isn't the case, the deployment needs to be fixed. How else will you have faith that you production deployments are safe?

Dev teams need to be of the mindset that anything outside of the OS that makes the software not work is a bug. Whether that is your own software, config files, start/stop scripts doesn't really matter. Users don't really care where the "bug" lies when the system doesn't work.

So I would recommend that you file bugs until the dev team can deliver a clean running system to QA repeatably.

Improve this answer
0

I think it depends on the quality level you or your company want to accomplish.

It's a good practice to create bug for something is not related to code. I think it's even better to create some other bug 'project' related to these kind if issues.

By this I mean that we often use bugtrackers like Jira or Bugzilla only to manage bugs related to code. So, maybe that's why it feels strange to create a bug that are not related to code.

But we could have different kind of issues in other areas of software development, e.g. Documentation, Requirements, Process.

So we should leverage these trackers to manage these other kind of problems. You can create divisions or 'projects' in these tools to manage bugs in different aspects of the software development process.

So you could create a 'project' in your bug tracker related to that 'delayed job restarting' problems that you had. This way, you wouldn't mix this bug with code bugs in the bug tracker.

Improve this answer
1
  • 1
    Can you elaborate what you mean with your last sentence? I am not sure I understand what you are trying to say.
    – Bart van Ingen Schenau
    Jan 6, 2017 at 16:58
0

Usually, you should raise a some type of ticket. It might not be a bug in your bug tracking system, but a service ticket for the operations team to take some action (like restarting that job).

Another thought, as well. It seems like this same problem happens over and over again. You might want to raise an enhancement to fix the root cause, or put in a monitor/auto-restart. (it's better to fix the root cause)

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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