Tag Info

Hot answers tagged

13

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


6

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


6

This has got to be one of the most common situations a developer faces in a company without QA. Since I'm a QA professional, and not a developer, let me try to explain it from the QA standpoint. First off, QA productivity is very hard to measure. There isn't really an industry standard for how to do it, and it is very likely impossible. The ...


5

I like posting results online, and then emailing stakeholders only for failures. No email means everything went smoothly. If someone isn't sure or just wants to see what was run, then the full set of results is available online. As TristaanOgre points out in the comments, testers need more frequent communication to be sure the tests ran. I would add that ...


4

Unless there's a bug to report, test results are meaningless to anyone outside of the testers themselves. At least, that's my experience. Why do I need to know that we found zero bugs every morning? That's not useful to me as a business analyst, developer, etc., on a daily basis. So, the fact that it is ignored by the stakeholders is actually expected ...


4

One of my favourites is Parkcalc ... Parkcalc is a real world application for calculating how much your parking is going to cost at the Gerald R. Ford international airport. It is also full of bugs, yet it works mostly. The requirements come in the form of the parking brochure. So you don't pound the real one into the gound there are a couple of self hosted ...


4

The deliverable is information about the system. The purpose is to help people make better decisions, based on information about the system.


4

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


3

In addition to what everyone else has said, here are some other factors to consider: Is your manager aware of the complexity level of your software? Given that your team is assigned to areas of the product, it sounds like you have a highly complex piece of software to support, which means that it's physically impossible to catch everything. If management ...


3

I like to take reporting back to a couple of fundamental questions. Who are you reporting to? What do they need to know? The answer to those questions is not constant, so it doesn't make sense to me to rely only on a constant reporting style. If you're emailing the same report to the same people week after week regardless of the work being done, then ...


3

A bug report containing the below could be meaningful: 1. Number of test cases passed, failed and pass percentage 2. Analysis and classification of failures : This is very important. A brief failure classification helps understand whether it is an automation issue, application code bug or environment issue. If a large % of test cases fail due to ...


3

Use facts and data to backup your claim as to why you need a QA department. One thing on your side is the fact that you release every 2 weeks. One thing to begin tracking is the number of defects that occur per release, and also how many other releases/fixes do you have to deploy if you do find a bug. When you can factually explain faster development ...


3

How much of the developer time is currently being spent on maintenance activities? Skilled QA doesn't just find bugs, but also helps increase other aspects of code and development quality, so that developers are often freed from mundane, low-level activities that eat away at productivity. The result can be a huge increase in actual production (the word ...


2

I have worked in product development and quality assurance in three different industries. Justifying QA is an education and organizational maturity issue. The value of dedicated QA varies depending on the size of the team (specialization of roles) and the risk associated with problems in the software. Some teams cannot justify it. Every project is unique. ...


2

Have you thought about expressing your desire/request in terms of quality and costs to the business, i.e. how much it costs (time+money) to set up the large number of projects versus the costs for having a dedicated Q.A. team? Also is it possible you can collaborate with the B.A. team to publish the costs (time+effort) needed to rework the requirements once ...


2

Central questions here, i believe are "How many bugs do users find after final release?" "How serious are bugs in final release?". It seems that management just does not see the point of dedicated QA since they don't see lot of serious bugs in the final release. Exposing these bugs, showing basic bug statistics, conducting end-user satisfaction survey ...


2

Bryce, If you go to Alan's blog you'll find a small application there that he deliberately seeded with a couple of errors. That's probably a good starting point for functional black-box testing, although it will be rather time-consuming if you're looking at manual functional testing. Another good option for training purposes is to check things like any ...


2

It is fine to ask others for best practices, but ultimately you must tune your own practices to the needs of your organization. You have at least two audiences: testers and developers. Their interests, attention span, and tolerance of interruptions will vary. I recommend that you propose something that sounds right to you, share it with your team, and ask ...


2

It seems to imply management in your org expects the QE team to be the gatekeeper as it should not become a blame game of why the defect was missed rather why it was introduced in the first place and the team collectively investigate the root cause of it surfacing. This would be followed by how we can prevent such bugs from seeping through in the future.


2

As you've noted, there are any number of these frameworks. There isn't really all that much difference between them in terms of reporting results - that tends to be a matter of preference more than anything else. Where the big difference lies in is execution handling. What you want to look for is something that integrates easily with your existing ...


2

My company relies heavily on SQL backends. We typically make many changes to both the database schemas as well as updates to the database software as needed during a release cycle. We try to have these front-loaded towards the beginning of the release cycle so that we will have plenty of time to regress everything and ensure we have time to correct ...


2

The problem with any form of hard metric in a field like software QA is that - to use the answer I give so often here - it depends. Each hard data point is really only helpful in the context of the development project it links to, and even then there are variations. I'd suggest you take a look at the answers to the question user867 suggested as a possible ...


1

I can think of a number of possible deliverables. Pick those that your teams and stakeholder need. I would say QA deparments provides Information/feedback about the product, e.g, bug reports test reports with test cases passing/failing, areas showing risky areas, metrics showing trends across subsequent tests, Tools to collect such feedback: ...


1

from my own experience, the deliverables can be vary from one project to another. For instance, I was involved in a very new feature that has to ship within couple of months. Due to time pressure, I wrote the deployment guide document for our sales engineers so that they will know to how to deploy in customer's environment without banging their heads against ...


1

Ask them why the developer created the defect and didn't tell you! Your managements expectations are unrealistic, but they are not uncommon. We deal with this on a weekly basis. You can never find every bug because you can never complete every test. Just a little something I learned from Kem Caner and James Bach.


1

We strive to find every defect, but for myriad reasons, bugs always slip through. Generally speaking, it is unrealistic to (1) expect a feature to be defect-free by the time customers start using it or (2) expect you to be the only person who finds defects in your feature. Taken in isolation, your manager's reaction sounds unreasonable, but there may be ...


1

This is a big subject, too big to be satisfactorily answered in an Internet forum. Of course this is relevant to testing, but it is not specific to testing. In fact, aspects of this problem are not specific to global teams. Any time you ask geographically dispersed teams to work together -- whether they are across town or across the ocean -- you will face ...


1

By far your best choice is to create your own "buggy" application. That way, you can ensure which bugs are present, and what types of bugs (UI bugs, back-end bugs, security bugs, etc) can be found. You could do that by grabbing an open-source project and modifying it for your new testers. If you were to grab a public version of a buggy application, it ...



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