44

I would operate under the assumption that your developers are documenting this somewhere, since I would also assume that they are good developers who care about good development practices. As a developer myself, I strongly believe that developers should be expected to describe what they've done in a language other than code. It doesn't have to be ...


36

In my personal opinion, I think this theory is flawed. As you stated, there are so many variables that come into play: % of escaped defects treat all bugs as equal, but they are not. Some bugs are more critical and some are merely cosmetic. If they really want to go with % of escaped defects, they had better find a way to properly and accurately weight a ...


25

If request sounds reasonable (which includes taking into account my other priorities), I would spend some more time researching. If not reasonable, I will respond "sorry this is the best I can", and if my polite refusal to spend more time researching is not enough for the developer, I will ask my manager to make the decision. I would also mention to ...


19

"there is nothing to test" That is a strong statement. I like to use James Bach's definition of testing: Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc. So, unless there is nothing new to learn about ...


14

Let's put aside all defensiveness for a moment. Why in fact was the defect not found? Sometimes, "because I have too many other things to do" is in reality "because the self-set priority of tasks wasn't appropriate" or "because my testing isn't deep enough to find that problem", or something else within your control. Be careful when arguing that you have ...


14

It depends. As Joe Strazzere explained, it is a matter of discussion between devs and testers. The question is what factors to consider in such a discussion. I think Danny R. Faught explained that pretty well in How to Make your Bugs Lonely: Tips on Bug Isolation. There is no clear dividing line between the bug isolation and reporting that the tester ...


14

Request a meeting between upper management of QA and DEV and explain the goals of what you are asking. I think the description you provided in the question is a good start at explaining the why of the ask. This additional information, for instance, may help a tester to find similar issues in other parts of the application or can provide ideas for ...


13

The short, simple answer: No The slightly more nuanced answer: It can be, but you have to be very careful The real explanation: Like most other candidates for tester performance KPIs, escaped defects is dependent on the activities of too many other people to be viable as a simple measure. Unlike something like words per minute or accuracy on a standard ...


12

If the product is at the MVP stage and your QA is just getting started, there's a problem. As a BA I saw this time and time again with dev vs QA where the dev team only got the BA to do testing when they felt the product was "ready to deliver to QA" which is a notion all developers should aim to dispel. Most developers went to university and took some ...


10

There has to be some sort of pain point to make Management and front-line employees aware of the need for testing. How your company does that depends on how mission or life-critical the software truly is. The typical Developer/Tester ratio in an unregulated development shop is anywhere from 4:1 to 8:1. NASA uses a ratio of 1:8. That's right, each Developer ...


10

In addition to some of the other suggestions, you could consider a few other options: Build/run load tests for new/recent work (given the maturity of your test automation you may already have this under control) Review existing test automation for obsolete or ineffective tests (You have no idea how much I wish I could reach this point) Review and refactor ...


9

Most other answers suggest that requirement to be better in testing is understanding the code - but that requires skills what most QA testers do not possess. Deep understanding the code is not required. In most cases, code changes are way too complicated and obscure for QA to be able to glimpse anything relevant from just reading the code in detail. What IS ...


9

Are you aware that “Most of the bugs in software are due to incomplete or inaccurate functional requirements?” What would be the best use of QA engineer's time while the project is in an early stage? Test the requirements itself, not the product... by asking the right questions to uncover & challenge implicit assumptions in the requirements....


8

I will answer this question with Agile iterations in mind. (An iteration could be a full Sprint or a single-user-story-cycle if you do Kanban or swarming.) The QA department is understaffed when: Not every cross-functional Agile team has a someone with QA knowledge The ratio defects versus released features is getting out of control Test automation is not ...


8

Many companies I've worked for shared a policy... ...and that policy is: Testers are free to consult with developers while attempting to characterize, isolate or reproduce anomalous behavior. Once a tester can document the steps necessary to faithfully recreate the behavior, the developer should be able to take it from there. Developers are free to ...


8

Great Question As per my experience, it's very difficult to get a right employee who has very good judgment, sharp focus, attention & great observation skills. Earlier it was very difficult to filter right candidate but our team come with some solution for that We made some minor changes in our interview process as follows:- Now before conducting F2F ...


7

Given infinite time and infinite resources you could never find all the defects within a feature or product, there may be some combination of keystrokes or conditions that can cause issues but are not always reproducible. If Management is expecting you to find any and all defects in a feature then they are giving you unrealistic goals, if they allow that ...


7

To expand on the other answers: Note that something is a corner case - don't be afraid to note that an issue is a corner case and is being documented so that when a customer does encounter it, it's on record as a known issue and any workarounds are available. Resist temptation - When you advocate for a corner case and are rejected, it can be very tempting ...


7

But, what are the general ways to avoid having or deal with such conflicts keeping the relationship between the teams healthy and productive? Both QA management and Development management must come to an agreement regarding the ground rules of bug reports. In some shops, more detail is required before the bug report is sufficient to hand off to ...


7

It seems that this question has two answers depending on the qualities of your QA team. If your QA team can read code, they can look at the commit(s) where the bugs are fixed - if you use a version control system. In this way your team can analyse the changes themselves, meaning you don't need any information or time from someone else. If your QA team ...


7

Oh boy! There is an interesting one. Well apart from checking all the technical skills and blah blah, I always make sure to ask or observe two things about a candidate I am about to interview. And in my opinion someone who lacks this or are weaker in these skills, blows up his/her interview or rather, reduce their chances of getting hired. As a tester, ...


6

First of all, whether a team member works part-time is irrelevant. Your team has a sprint backlog based on its velocity, which is variable for each sprint (dependent on team capacity for that sprint). If someone works only four hours a day, the workload for that person should be planned accordingly. Within the time allotted, everyone must do a proper job. ...


6

I'm a developer, and I do add additional information in our bug/feature tracking system on completing an item whenever I think it might be useful. I target this mainly to testers, but much of the same information might also be useful to another developer who comes across some code I touched and wants to know more (after reading source comments) about why it ...


6

I don't think your team is ridiculously understaffed. We run our operation more lean than you do. In real life, ratio of developers to integration/system/functional automation testers is as low as 10:1. How is possible to maintain quality? By focusing more on unit tests (written and maintained by developers). Unit tests should be your first line of ...


6

Although all observations are valid, from a project point of view, I am missing the motivational and learning point of view. Starting some automation now can also be part of the learning of that engineer, and the team. He will be motivated as he can do something he wants to do. Yes, the product will change. But he can also grow along with the development of ...


6

Use tests to drive code design. This is the difference between using tests as quality checks, post development instead of using tests to uncover and drive the design up-front. "Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Managing the Unmanageable. Steve ...


5

You didn't mention anything about automated testing of your applications or the DB. For that additional headcount you mentioned, you could get a QA developer who's sole job is to write tests for your applications and the underlying DB. Even if the applications weren't written by you, they must have some kind of communication interface that you can point a ...


5

Assuming one cannot start as a "calm and relaxed horse", and we have only these two options, I would focus on starting to deliver as quickly as possible - at the end this is what you were hired to do. If there are factors that prevent you from starting to work, this is not your problem - this means that there is something wrong in the company's onboarding ...


5

To add to Rsf's excellent answer: You can't "make" management accept anything. You may be able to convince management that migrating your test codebase is a good idea. If you can demonstrate that a migration stands to improve ROI by enabling any of the following advantages you stand a better chance of management approving the change: The proposed new ...


5

As a counterpoint to the many answers saying that testers can review the changes in source, I have worked in more than one place where testers have no access to source code. Their only source of information on what has changed is whatever information is in the ticket. In this situation, developers absolutely must provide testers with information on what ...


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