Tag Info

Hot answers tagged

8

Without being flippant, this sounds like you've got a serious communication problem in the team. Given the limited timeframe, here's a few things to consider: everyone in the team needs to know what a good bug report looks like everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report. This means ...


8

I tend to prefer allowing anyone in any capacity to log defects on any team I am a part of. It helps build a sense of ownership of quality in the entire team, which is as it should be, every team member regardless of role should equally own and care about quality. It is a different story when people outside of the project team are entering defects, I would ...


6

I would report the issue, but describe clearly that I cannot reproduce it. As a tester it is not my call to decide how much effort is put in reproducing the issue. I think we have signaling role. Risks Its nice if the report contains an estimated risk, do real users have problems and is it possible they get stuck and maybe cannot use a certain feature, ...


6

The first thing you want to do here is perform some bug triage. Problems your team finds during feature testing will be one of: something introduced by the changes something that was there before and doesn't have much if any impact on the changes something that was there before and has a major negative impact on the changes The developers in the team ...


6

First, it is absolutely professional to ask for more information when you've made a number of attempts to reproduce the problem and haven't been able to do so. You've effectively eliminated the most obvious potential problems with your attempts to reproduce, so the cause is something less obvious: it could be the customer using a different configuration, it ...


4

Some thoughts here: how healthy is the situation where bugs are logged by project members other than the actual qa member who is the dedicated personnel for quality? This is normal - anyone can log a bug. The team decides which bugs are in scope for the project and which need to go into the main backlog. The team decides which bugs get fixed when ...


3

The problem should be reported, with a note in the report that you can't reproduce it consistently (or at all) and that you will update the report as more information is available. Your next steps should include some mix of the following strategies: If you can increase the level of logging, do so and leave the logging in place until you get a repeat of ...


3

Anyone who has access to the application should be able to file bugs/defects. Defects should be filed in a bug tracker with a status new. New defects should be verified and extended (With at-least a reproduction path) Defect should be added at the top of the backlog (Keep a no defect policy when being Agile) Products Owners should monitor new incoming ...


3

When you say that bug triage is impossible (or improbable), you need to determine the opportunity costs associated with that: In the case where no triage is performed, there is the probability that a single or multiple developers will attempt to fix the same bug. At minimum, there is wasted development time that could be focused on other areas. Worse, the ...


3

If you have specifications that say a confirmation must be displayed, the test fails. If you have user requirements or user expectations that there will be a confirmation dialog, the test fails. In the situation you describe, I would create a bug from the test, but it would have a lower severity rating because it doesn't interfere with functionality. The ...


3

First google Exploratory Testing. Some ideas for testing might be- yours, and your customer's expectations and needs (what is the program used for) similar programs (compare to other knowns) relevant standards, or de-facto and industry standards (from national or international standard bodies e.g. ISO/IEEE/FDA etc. other sources might be known practices) ...


2

When publishing data into the public you should always anonymize the data, not only log-files. Also e-mails, documents, etc... You could try the open-source Python based log-anon. This tool was designed to replace sensitive fields in customer's logs with anonymized values, while generating a lookup table. This is sometimes useful to comply with ...


2

At my company around 150 Full time employees with 15 developers on staff, and a support team who receives all the inbound calls, if the bug is not easily reproducible, it is researched by a tier 3 support team. If they are unable to reproduce the issue, they will normally check with other system experts such as the QA team. If we are still unable to ...


2

This situation does happen occasionally with our application. What we do is to capture as much information as we currently know about the issue and to continue to collect information until we have a reproducible set of steps. It helps if the issue is duplicated at more than one site since we tend to get a little more insight that way. The issue remains an ...


2

Bug triage is very important, especially when time is limited. Bugs have different levels of severity. Examples include very high: someone may die as a result; high: the company may lose business; medium: the customer will be upset; low: there is a minor spelling mistake. The actual outcomes and severities depend upon the organisation. Bug triage is about ...


2

I agree with the others, anyone should be able to enter bugs. One comment on: Especially if they are not well described with steps to reproduce? If the bugs being entered are not productive, I would invest some time those people to train them in the art of great bug writing. You just might make a great tester in the end.


1

Globally, you want to determine the risk and take appropriate action (which may be no action). So you really want to know what the effect of the bug is, and how often and/or likely it occurs. If its rare and results on some minor UI anomaly, its not worth pursuing. If it happens every time on your landing page, or you're losing customer money, then at a ...


1

Report the bug. The developer(s) might not be willing or able to address the problem for one reason or another, but the developer(s) can't address the problem if it goes unreported. Give as much detail as you possibly can. I remember a bug I saw a few months ago which only occurred because the user was running Internet Explorer as a specific account in a ...


1

Apart from what others have suggested, you can also try 'Session Replay' tools. You get to see the exact actions performed by the users at the time when errors were logged in the backend. This has a great effect on developers. When they see this, they instantly believe that something is wrong and drive it to closure. I don't know if there are any ...


1

Raise it anyway and give as much detail as possible (time, date, error log, test evidence, etc.). If it affects something further down the line, this will cover your back if a project manager or stakeholder asks why something wasn't done about it. I've experienced that a few times, where something's not reproducible so the developer just says "I can't fix ...


1

I am unaware of any standard definition for "Software Reliability Report". And an internet search doesn't show anything either. So you have 2 options: Ask management what they want in the report, or if they don't know, ask them what the report is for and use your best judgement. Make something up. List of known defects, supported usage scenarios, ...


1

This is going to be a bit unpopular, but I am going to have to buck the tide on the answers so far. I agree that it is important to allow everyone to submit potential defects and that system should be as clear, helpful, and accessible as possible. However, I have found that it is important to separate the "official" bug list that the team is working from the ...


1

Bug reports should be... ...Clear Bug reports should have: Precise, descriptive summaries. Informative, concise descriptions. A neutral tone, avoiding complaints or conjecture. ...Reproducible Bug reports should contain: The simplest steps to reproduce the issue, or... A failing test fixture for the bug. ...Specific Only publish one bug per ...


1

I would separate the test case into 2: The first one ends with the confirmation message and the second one continues from there on. I would create a bug, link it to the first test case and keep the test case in 'ready', while I would close the second test case. If this is not a major requirement for you, then the test cases can be prioritized, so that ones ...


1

It may depend on the strategy of your project, but i'd say this test is failed. If the confirmation is part of your specifications/functional need, you can't make this test pass. Imagine this is the only issue in your whole test plan, if you pass the test, then your indicators will be all green for this functionality. Thus, there is no reason to do rework, ...



Only top voted, non community-wiki answers of a minimum length are eligible