Tag Info

Hot answers tagged

75

Yes. Because no matter how good you are, you can't think of everything. You will also be asked to make your software do things that you never intended for it to do. You will also never have requirements that are so clear that you will be able to think of every possibility to make sure the code doesn't break. You will also work with other people's ...


73

Yes For the same reason that a chef tastes his food while cooking it.


37

The question seems to be asking specifically about System Testing, so that's what I'm referring to throughout this answer. I think there's an important distinction to be made between being a bad person to choose to perform testing, and actually being bad at testing. Why programmers are bad at testing: If you've written the code, you (should) have already ...


30

QA should always try and make the bugs as easy for you to reproduce as possible and the bug description should contain the steps taken. However, if they can't easily reproduce the bugs, they should still get entered into the bug database with suitable title/headings and a full description of what they did to cause the bug. The bug description should ...


29

It sounds to me like you have a dysfunctional team with a cowboy culture and you're trying to figure out what the root cause is. You are proposing a hypothesis that maybe developers don't respect test because of some sort of implicit hierarchy or length of service or some other factor, but you're not necessarily presenting evidence for the case, you're ...


24

First thing that comes to mind is, because they're big enough to grow a few layers of bureaucracy. This means, among other things, that you no longer have really smart coders in charge of the hiring process, which means they lose their ability to weed out potential programmers and QA people who are incompetent. Which leads to bad code getting written and ...


23

As a member of our company's QA team, I frequently get entirely unenthusiastic feedback from developers in their responses to test results in our agile, web-based software-as-a-service shop. That's because: Our product owners are vacant: acceptance testing doesn't exist, and user stories usually are only one sentence long, and don't provide the ...


19

Well, the direct answer to your question would be Mu I'm afraid - there's just not enough details to make an informed guess whether you should or not quit trying. The only thing I am pretty positive about is that level of agility should be driven by customer / market needs (which you gave no info about). For example, as a user of IDE I am perfectly happy ...


19

I think programmers are bad at testing their own code. We like to believe our code works perfectly according to the requirements and test it as such. In my place we test our own code, then test each others code before releasing into the actual testing cycle and far more bugs were caught that way than just by testing our own code


17

Because the programmers weren't told to test for that and the crushing corporate culture didn't give them enough leeway to have their sense of professional ethics kick in and demand another couple of weeks to test for security vulnerabilities. Or to insist that they be secure from the start. Because the boss didn't want to spend a couple of extra weeks ...


17

This is quite common. We use this in our team. For Every production defect, the developer must add a note on the root cause of the problem , add a failing unit test and add a test impact analysis before the ticket can be pushed to dev state to check in the code. I don't think this has a specific name except that general "regression testing". This is very ...


17

When your dev team and your QA team don't not talk to each other, there is a certain risk that some tests are unnecessarily done twice, and some others are forgotten. One worst case scenario is when your dev team has implemented some nice automatic integration tests, which run in a few minutes or hours, and your QA people tests the same things manually, ...


16

I work with someone that thinks like this, he thinks that because he is a senior programmer he no longer needs to test his code. The company does not understand how dangerous this attitude is and instead of firing him outright they hired more programmers to tackle the bug backlog. Not knowing where this backlog comes from they think it's part of what ...


16

According to the various answers found here and on Wikipedia, soak testing seems to be a test of normal sustained use for a long period of time. This is done to to ensure bugs or memory leaks do not appear after what is considered to be a relatively "normal" usage period. Stress testing is also a form of reliability test that tests beyond normal usage of ...


16

Developers are very, very good at abstraction. If you give us half a problem, we'll come up with the whole solution. In fact, we're so good at this, we won't even notice that we've only got half the problem. We're "solution space" people. Our job is to solve problems. Testers, on the other hand, are "problem space" people. They're the ones who ask, "What ...


16

Testing team (the so called QA team in some organization) insists that the dev team should share their (Dev team's) test cases with them. Sure, QA should have a general understanding of what is covered by unit/integration tests, and what is not. Their arguments are Dev test cases are the starting point for the QA testing. ...even if their ...


15

Maybe I'm too old-fashioned, but even the most modern development or proccess techniques cannot substitute another set of eyes, fresh eyes, before releasing a product to your client. Even if your product is simply an API for another developer, you can use QA to think as the API user, providing test/use scenarios that you or your client did not think in ...


14

I would strongly suggest that management reconsider trying to track things in this level of detail. It's going to be inherently subject to gaming. I've seen clients attempt to do something similar but at a group level rather than at an individual level. What inevitably happened was that there was a strong incentive for each manager to get their group's ...


14

Oh, I do feel your pain. There are some serious changes you need to make to the QA team for this to work. My advice is to split the team into three teams: Feature testing - Fast turn-around on testing new developments. Regression testing - Fully testing the product before it goes out of the door. This shouldn't take 3 months, even after reducing the team ...


14

Yes, that's the right response. The indentation style should be consistent for all code. A big part of the value of consistent indentation is that it's consistent. That way people learn to read it easily, which speeds up everyone. My rule of thumb is that any indentation style the team wants is good, as long as it can be mechanically applied. Applying it ...


13

It looks like your QA department is doing too much exploratory testing (ie. They don't have a good test plan). Exploratory testing is good, and identifies problem areas, but from there they should be defining reproducible test cases (ie. a test plan) to perform that will reveal specific bugs. There's a number of reasons why a correct repro is necessary ...


12

There is not a hard-and-fast answer; it is up to your organisation. One thing to consider is that if QA find many bugs in the new feature, it would be better to track each of them separately, so I would tend towards filing individual bug reports. If the bug is so major that there is no way the feature could ever be used as intended (e.g. the menu item to ...


12

The bigger the corporation, farther away the decision makers are from any real-life responsibility. Knowing how corporations work, the site design was probably outsourced to some consulting company chosen based on the lowest price per developer. That company would in turn hire bunch of random people on similar criteria, with average person staying on the ...


12

By way of illustration: Note that your QA team is probably working outside the (ATDD) circle, and you are working inside. I think it is OK to work that way; if you can prove in your automated tests that you are fulfilling the customer's requirements on each sprint, you can allow QA to perform their tests at their leisure, and come to you with defects, ...


12

Absolutely! If you can agree that unit tests are a good thing, then you will realise that if there is a bug then there is a missing unit test covering that code path. So what should happen is, you write a unit test that shows the bug exists, fix the actual bug, then the unit test will pass. If you have no unit tests at all, then this can be a good way of ...


11

Organizations work well when QA and Dev have shared goals and shared responsibility (including financial responsibility for the well-being of the company) for any errors that slip into production. In my experience, situations where Dev and QA are measured independently and there is rivalry are bad for the company in the long run. Bugs happen, that's ...


11

It obviously depends on your code review process but personally I'd say the functional completeness of the requirement is more within the remit of the QA / Test team than the code reviewer. That's not to say that a code reviewer shouldn't be able to pick up on problems with the functionality where they find them (assuming they have the knowledge to identify ...


10

Well I tend to use the fingers metric. I hold up my fingers to count and say: Me: "How many offshore testing teams would I consider working with?" Me: "Umm... None." Then the problem of defining other metrics goes away. Now, before that gets marked down... The only reason I would use an offshore testing team, is if I was testing a localised ...


10

For a short block, (3 days), accept it and do something else - read ahead, i.e. investigate tools and techniques that will be needed later - pay off some technical debt, i.e. do code reviews, look through //TODOs. Investigate to make sure you understand what the real block is right now. It might not be what you think. Don't delegate this. Look into it ...


10

In my experience QA receive a smaller salary than Devs as they are undervalued in most companies. I have seen one instance where QA and Dev received similar compensation and where both roles had equal importance on the team. This company stood out for this fact. QA was taken very seriously and the company had a ratio of 1 QA for 1 Dev. QA and Devs worked ...



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