Tag Info

Hot answers tagged

10

I would always go for opening a new issue and linking it to the old one. The defect might look similar in its behavior, but its possible the cause is totally different. If possible let another developer fix this new issue. The added advantage of having one ticket with all the info is very slim, reducing the defect count is like giving management blindfolds, ...


8

It's not necessary for QA to do root-cause analysis for every defect they found. It's up to circumstances. And for the level of drill-down, I did not drill to the level of source-code when I tested a Unix binary application. But I did html/css root-cause analysis when I tested a website. As a view of user I represent, I access only the information that a ...


7

As others have said, it depends. My usual method works like this: I find something that doesn't seem right: If it's really obvious (a typo in a high-profile part of a site, an error message that gives the line of code that's failed), I'll check with a developer to see if they're working on that code right now (this is often the case in agile or other ...


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, ...


5

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 ...


5

Because there are no requirements, I would say go with your first option. You are relying on normal expectations based on the button text. If the bug is rejected, you can ask why. Better yet though, find someone who should know (PM/BA/Customer or maybe even the dev) and find out what it's supposed to do. The more information you have, the better bug ...


3

As others have said, if there isn't a consistent definition of what constitutes top priority across all teams, there will be disagreement over what constitutes a top priority bug. That said, I have a few thoughts to offer: Will this bug break core functionality if it is introduced to production? If the answer is "yes" then priority should be higher. Does ...


3

You need to take a step back and look at the whole picture- why did the dev lead objected to the P0 setting ? It is not because "it is not in production" (well, it is but there is a higher level reason for that) but because the company doesn't have an agreed and accepted definition for priority levels across all teams.


3

Timebox it and afterwards evaluate. I would say time-box one hour and then see how probable it is the tester will find the steps to reproduce the issue. Often its easier for developers to reproduce the issue, since they understand the code for that part. And they are more proficient in code-debuging.


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 ...


2

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, ...


2

Working with spreadsheets is not bad and strange, it all depends upon the scope and type of tracking you want to do, if you have a limited scope of test cases, issues and requirements, then you can stick to the excel sheets but in long run you will need some tracker which will make your work a lot easier and will itself perform some of your tasks which do in ...


2

One team, one system. Do not create separate spreadsheets, be transparent instead. I would Keep track of your whole project in a single tool. Jira is build to be defect/issue tracker. This is what it was original designed for. Just use it! :) Before development for requirements, during development for defects and communication, after development for ...


2

It depends. I saw acceptable time/effort ranging from 0 (outsourced testing to almost un trained testers) to infinity and beyond (combined engineering team with engineers that know their way through the code and product). YOUR answer will vary according to (just throwing some ideas): Your skills and knowledge e.g. how familiar are you with the product, ...


2

I would open a new bug, and refer to the old one. I would also have a conversation with the development team about the duplication, more than just reporting the bug a second time. They might not have fixed the true root cause the first time, or you are doing something that they don't expect in your testing. A conversation could lead to better learning ...


1

Possible issues with using spreadsheets are that: you are dependent on an external company for software for access to your historic tickets. the only workflows are manual - no enforcement you will eventually run out of space or the sheet will get too big to handle difficult to add attachments such as screenshots of the problem, etc. I would suggest ...


1

We have a smallish engineering team. There is an in-house issue tracker built many years ago that we use for customer and internal bugs; however, for testing of features, I use excel. The excel spreadsheet is uploaded to sharepoint. I log the issues with a hyperlink to my documentation (steps to reproduce). The developer reviews the issues and documentation ...


1

Niels van Reijmersdal and Dhiman already mentioned the most important point. I'd like to give a look into my experience as my situation was quite similar to yours now some years ago. I'm on a small freetime project (a browser game) and in the past years we tried to build up at a QA too which is a bit more problematic with only users who do the "work" in ...


1

Apparently, in your company there are at least two teams. Your team needs some functionality from application, and the other team is responsible to deliver it. Priority is just a meaningless category to prioritize work globally. You can set your own priorities as needed inside your team. You tried to ask for help from other team. Seems that help is not ...


1

Recently, I found a P0 bug in the pre-production environment. I am the lead QA and I refused the deployment in production before correction. The bug made a simple action not work (classical one, used by every single person of my company each day). The priority of a bug is not due to where or how it is found, but the severity and the effect of the bug. In ...


1

To echo others, it depends and I'd say that it largely depends on the culture at your company. It ultimately comes down to a trade-off between developer time and tester time. The more time you spend digging into the root cause of an issue, the less time you'll spend looking for other issues. However, you will save the developer some time because he/she ...


1

Nobody can really answer it since it depends. Depends on your qualifications, your and your team work load, the dev team work load, the complexity of the issue etc. I work now in a combined engineering type team and I still can't give a definite answer to your question, your best bet is to discuss this with your colleagues and managers.


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

I accomplished a similar thing by running the SoapUI tests within the Maven Build http://www.soapui.org/test-automation/maven/maven-2-x.html one of the outputs is "junitReport : Turns on creation of JUnit-reports, (true/false)" which will then let you use any of of the million JUnit graphing tools. Hope that helps in finding your solution


1

The severity is to know the impact of the issue on the health of the software whereas the priority is to order it for fixing. The crashes are always logged at highest severity . However if its in the main flow of the application, its priority will also be high whereas if the crash encounters in a very rare scenario , the priority is set low , generally.


1

Checklist for publishing a good bug report: Look for duplicates Check for accuracy in all elements of the bug report Role play as a different recipient (for example, a Test Manager) and ask if the bug report is really useful to them Make a list of mistakes in the past with bug reporting and run it through the report Check for attachments, their sizes and ...



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