New answers tagged

0

I'll try to put it in the simplest words I can, Severity: It is the measure of serioursness/danger of the issue. Something that may cause you software to crash or a security breach or basic functionality not working are all kind of very high severity issues. Priority: It defines how quickly the issue needs to be fixed. A high priority issue means that it ...


-1

You can can understand the deference using following URL, http://learningclue.blogspot.com/2016/01/differences-between-severity-priority.html Above URL mentioned the differences of severity, priority and Status clearly.


0

Firstly, don't be put off by committing your code, you should continue to do this early and often. Any code that goes into the master branch I feel should be ready to be tested straight away and all of the automated tests should be passing at this point. QA should be aiming to test your work as soon as possible and not leaving everything until the end of ...


1

As a tester, I love exploring partially developed code, and giving early feedback to the developer. The key thing, as others have mentioned, is strong communication between developer and tester. I need to know what areas are likely to still be incomplete, so I don't waste time trying to isolate an issue. The developer needs to be prepared to outline what's ...


0

In fact this is, to an extent, quite normal if you are using test driven development, TDD - you can expect near 100% of your tests to fail at the beginning of development and things to improve as you go on. Possibly you need to work on your companies workflow so that failing tests are logged as failing tests until you attempt to mark a feature complete - ...


0

I think my previous answer also applies here. In my opinion, the best possible bug report (assuming that the person that sends the error report does not know the causes of the observed failure) is a bug report with reproducibility information, so that the developers are capable of reproducing the problem. In several bug tracking sites, for example MySQL, ...


-1

click on element first then do sendkeys, and if .click() is not working you can click on the element through taking coordinates of the element on the page or click on it using robot


2

You wish to check your code in to keep it save. The testers test everything they can see, maybe because it is not clear what is not finished, or maybe just for another reason. There are a few actions you can take to stop this problem. You could use Feature branches You only merge the code into “main” when it is finished Other developers can see what ...


0

Why do you care about what we are doing ? If for example I work for the NSA I would need 5 different authorizations to publish even a single line (or not, I don't work for them). On the other hand if your employer is working with open source software then there is nothing wrong with publishing it, one of my previous employers explicitly allowed this as ...


1

If the failure is induced by large inputs, you may want to take a look at delta-debugging: http://pag-www.gtisc.gatech.edu/courses/common/zeller-tse02.pdf In short, it takes a failure-inducing input and it tests its subsets, with the goal of finding a (substantially smaller) one that still induces the failure.


0

As a first step, I would recommend doing an analysis of the source code to determine which are the sources of non-determinism of the application (i.e. anything that has the potential to make the application execute differently). Generally there are two types (with a lot of subtypes each): -input; -memory interleaving you can find more details about ...


1

Regarding bug-reports: In my opinion, the best possible bug report (assuming that the person that sends the error report does not know the causes of the observed failure) is a bug report with reproducibility information, so that the developers are capable of reproducing the problem. In several bug tracking sites, for example MySQL, we find literally ...


1

Regarding privacy protection in error logs/reports, you may find the following research papers to be interesting, as they present the state-of-the-art of error report obfuscation and minimization: 2008: http://research.microsoft.com/en-us/projects/betterbug/castro08better.pdf 2011: http://www.cercs.gatech.edu/tech-reports/tr2009/git-cercs-09-14.pdf 2014: ...


1

Is it normal? Yes and no. I would say that first and foremost if you are in an AGILE environment, the product owner or someone else should be scrubbing duplicate defect reports before committing them. Also, testing tasks should be presenting to QA once a feature is working, not typically before. That just wastes precious QA time and makes the backlog messy. ...


0

Yes, A developer would be able to advise how to do further testing. The important thing is that it is before you write the report. Not instead. The developer is not responsible for deciding if a bug has been removed.


3

The fact that multiple testers test the same thing without even talking to each other shows very clearly that the process is broken. You shouldn't have 2 developers develop the same feature independently and you shouldn't have 2 testers test the same feature independently . It sounds obvious, but if 2 people work on the same thing, they need to know about ...


0

As "Joern Boegeholz" said; It Depends. Usually I prefer to ask my clients (dev team, management, analysts, designers, the client) how much details they want in the bug report. Many a times people don't really read a whole lot and hence they ask for fewer details, yet if the testers can do Impact Analysis of the Bug and report it in the Bug Report, that's a ...


0

I think it's fair for QA to enter a bug with what they think the impact/severity of it is. This can easily be updated and over-ridden by someone else downstream (e.g. the person triaging issues, project manager, whatever), but a good tester should have some idea if an issue is a show stopper, if it's going to be a big issue for end users, maybe it's just ...


4

No, it doesn't make sense to test code that you know is incomplete and not ready for testing. But rather than blaming your QA folks... I suggest that you take a closer look at your software development process. It sounds like there is a failure of communication between developers and QA, and a mismatch of expectations. For instance, it sounds like you are ...


1

To stay simple, and echo what others have said- (20 years experience here)... Find the steps to reproduce Take your screen shots or grab logs, etc. Find the root cause if you can Report the bug. Get it in the system. Perhaps do some limited searching to make sure it isn't a duplicate. speak to the developer at this point or when first able <-fin-> :)


5

It makes zero sense to waste time on testing a feature (and reporting bugs, and triaging them) if development is not finished yet. All this work will have to be redone again when code is finished. Something is strange in your process, if testers have so much time that they create extra work for themselves like that, which has no benefits to the project. Do ...


1

I'd say the issue is in the complete process. In your process, you should have a delivery document which explains the SQA team what have been developed, and what is still in development. Using this document, the SQA won't test anything not developed yet. If they absolutely must (due to management constraints) test in advance, you could cut your ...


1

The PM, the designer, the QA, the developer and other stakeholders; each of them have different perspectives and expectations from the product, even when working with a perfect analysis. An objective look really matters. So, sometimes, especially when I am about to release a new feature or unsure of the requirements of my task, I ask for QA's time and ask ...


17

It is always a very good practice to start testing as early as possible. By not fully implemented if you mean still under development, then I suppose that is not such a great idea. Yes, you can go for incremental build releases for testing, that might be helpful. When you say that your testers all log the same bugs, well there's your problem! Do you ...


6

Most of the companies I've worked for over the last 10 years are using an Agile approach. In this approach there are several factors to pay attention to such as: favor direct communication over formal processes encourage a team approach sit together I find that in such environments you want to seek out practices such as: pairing on test plans before ...


16

I think the problem arrives from how you use your VCS: You want to commit your code because you have finished a sub task and want to have it backed up in case of e.g. a hdd crash on your workstation. Your testers see changes in the repo or get an automated build which they test. One solution could be a separate working branch which is work in progress. No ...


13

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality. To me this is wrong KPI and there is been at least two discussions here why is so: ...


0

A classic answer: "It depends" It depends on how strongly the tester is involved into the development process. If he knows that the issue affects two different products which are delivered from two separate branches relying on the same implementation, he can state that in his bug report. A more practical approach would be simply trying to reproduce the ...


0

Just repeating some of what has already been said, but as another voice with 15+ years of combined QA & Dev experience, I would agree mostly with those who say that it all depends on what works best for your company/teams. However that said, I'm a fan of open dialog between Dev & QA, and I personally think teams that have that in place will fare ...


0

I think you should absolutely discuss it with the developer. I work in an environment where we have a mainframe connected via MQ and other middleware to various front ends (web apps, POS machines, smartphone apps). Just because a scenario fails doesn't mean the code is bad. Maybe the middleware developer isn't passing the correct data to the front end. Maybe ...


2

Report the bug. A QA person's role is to be an independent verification authority. Someone who understands the products requirements and who is focused on quality. Make sure you document your problem scenario/reproduction steps so that your bug report stands up to scrutiny. The problem with discussing bugs ahead of logging them is that it introduces ...


5

I think, it is always good to discuss things in person. You are lucky you have that things going on at your work place. In many companies all communication happens only via a system and that at times creates lot of confusion. What you write and what the other person understands may be completely different. For things like developers don't consider the bugs, ...


2

Since I work at a team that doesn't have specific requirements for projects, I always communicate it with the developers and showing them how I reproduced the issue. They will acknowledge it. Sometimes they would say, let me check on that.. Coming back, they would say, oh I have fixed that please test it. Before they can fix it, I have already documented the ...


3

If my dev counterpart is available I try to talk with them first. That gives them the chance to request extra information that I might not have thought of. If my dev counterpart tells me that that area is not ready for testing, I tell them I will enter a bug just to remind myself to come back and look at the area once they believe it is ready. If I hear ...


4

It depends. Some of the factors I've found impact whether or not I report something formally or not: Development Methodology - If I'm working in an agile environment I'm more likely to work informally with the developer at first. In a waterfall environment, I'm more likely to report the issue because the developer has probably moved on to something else, ...


4

My view as a developer is that even if you are unsure it is a bug then report it. The upshot of this is (some of this has been mentioned by others) If you are unsure if it is a bug then you do not have enough product knowledge to perform the testing. This could be for several reasons, including partial training, poor documentation and insufficiently ...


4

If it is a clear and obvious breach against uncomplicated acceptance criteria, then report bug as soon as possible. Feel free to bypass the developer, BA or product owner. Otherwise, do not report the bug unless you first talk to the author of acceptance criteria (eg: BA or product owner), and the developer. If you do not: it is possible that you will ...


6

As a corollary to what David said, testers have the same memory limitations that developers do. If you don't log the bug, chances are very good it won't get fixed. This is especially true if it's not a severe bug, as chances are very good that the developer(s) are working on fixing severe problems first, and won't fix less severe ones for a while. And by ...


11

Do not discuss defects immediately with developers. Mainly because context switching is bad for their focus and could take up to 5-30 minutes to recover from. How to communicate a defect depends in which stage of development the defect is found. When I find a defects during testing of a task of the current iteration then I document the defect in the ...


5

It depends... What is the overhead associated with reporting a problem? Some organization have big enterprisy processes, that requires lots of clicking, mandatory fields and multiple actors between the time a problem is open and the time everyone is done with it. You might also loose sight of important problems if they're drowning in a sea of minor (or ...


7

Should Testers first discuss the bug with the developers before reporting it? From my experience in several different organizations I think the answer given the current question details is "it depends" It will depend on general factors such as: size of company size of development group current deadlines location of developers industry development ...


4

Definitely make a ticket. If the bug is "don't fix", you can refer another tester or developer who finds the same bug to the existing one, and save the developer some time. If the bug is a quick 5 minute fix, it still takes 5 minutes to do, and you have to remember to properly re-test. If these little distractions add up and are not documented, things ...


45

As a developer with 15+ years experience, I'd say: please report the bug. I'd much rather have a ticket in the tracking system than a vague memory of a hallway conversation, or an interruption of what I'm working on. As Joel Spolsky put it: At any given time, I can only remember two bugs. If you ask me to remember three, one of them will fall on the ...


4

If the tester thinks that it is a defect, most likely it is a defect. The developer may be correct that the process is working as intended, in that case the defect is possibly in the documentation, user interface or testing plan. It should be logged, even if is testing error. This will lead to better determining where documentation deficiencies exist.


4

If there is possibility to discuss the bug, it could be valuable, for example you will have direct information of the cause and who will be the assignee of the bug. But generally it is not mandatory. It could be done as well after the bug is reported. Does not matter if you discuss the bug with developer or not, probably you will have to report the bug ...


7

I imagine this would depend on the bug being raised. If it's a glaringly obvious bug (pages not loading, basic function not working, etc.) then I wouldn't waste a developer's time confirming it and do a write-up. However if I come across something that may be considered an edge case or I'm unsure of the intended functionality (mostly found during negative ...


11

We prefer to talk to developers first. Then, we together decide if detected error is a result of some quirk in processing and not even worth of bug, or, if it is worth a bug, we negotiate who will enter it to Bugzilla (we call if "buggify the feedback"). Often, developers prefer to write the bug description, because that way they can better describe the ...


14

In my own experience, I've found that this really depends on the culture of the team or company that you're working with. On a team with good communication skills, and where everyone works together well, you may very well be able to just tell the developer about it, they take a look at it, and say it'll be fixed in 5 minutes. If it's longer, maybe ...



Top 50 recent answers are included