Hot answers tagged

39

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


34

My recommendation: You either include testing time in the ticket, or add a ticket to represent the testing task itself. Any other approach causes you to underestimate the real work needed. While developer time is often a bottleneck, in my experience, there are many teams constrained on test. Assuming the limiting resource is one or the other without ...


31

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


30

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


27

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. The failing unit test must pass before we can push the code to production. I don't think this ...


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


21

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


20

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


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


19

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


19

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


19

Emphatically, Yes Testing is part of the development process. If your team actually spends time testing the software, the time spent testing needs to be part of the estimate.


18

they have none of the obsessive neurosis attention to detail of "real" developers Preface: The kind of language you used here is typically a red flag for me. When I hear people talk about "real" developers or the (one and only) "right" way of doing things, I start thinking of tunnel visionned cargo-cult developers. Now, I'm not saying that you're ...


16

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


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


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

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


13

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


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


13

If you don't test a User Story (US) and verify that the acceptance criteria are met this story is not done. If its not done this US goes to the next sprint of course. And if all your US are in this state you sprint has ended with no value added to the project. From the client point of view I cannot distinguish this from the entire development team going on ...


13

QA should probably be testing twice. The first testing should be around the specific changes and done on the feature branch. This lets QA test around the specific changes and see that the particular change is complete as specified and behaves as expected. It also gives them an early preview for the second round of testing, which is what actually matters for ...


12

It does not matter if you implement E2E and integration tests or not, you need a backup plan either way. Never expect a system to be bug-free just because it was tested. Thus, in your cost estimation, you do not compare the cost for implementing E2E tests against the costs your backup plan estimates in case of a failure, you compare: Costs for doing E2E ...


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


11

The technique is test-driven development. It's not really about being able to spot a similar bug next time, although the suite of repeatable tests is always helpful. The point is that you can demonstrate that you've isolated what is wrong with the code, proved that it is wrong, fixed it, proved that the fix is correct. There's a quote that I can't quite ...


11

Programmers are definitely the right people to test some parts of the system -- in places they are the only ones who might be able to do it effectively. One place programmers tend to be very bad at testing is the whole "use the UI like a normal user" bit -- they aren't normal users and don't behave like them. For example: Programmers tend to be very good ...


11

For most real life situations agile stops at delivery to QA/UAT or whatever its called. The effort to move from QA to Production in a real life environment is often underestimated. In many cases this involves real business users in testing, management sign off from the real line of business managers, scheduling the release with operations etc. etc. This is ...


11

Really, everyone should make a reasonable effort to avoid duplicates, but developers are usually in the best position to do so. Bugs can be found by many people, but usually are filtered to one developer or a small team responsible for that area of code. Also, you often need the code to determine if two different symptoms have the same root cause. All bug ...


10

Yes and no :) Both developers and QA people should have the same goal (and their performance measured against that): deliver a quality product in time and on budget. You get to define "quality product", but it has to be the same for both groups. Why? Because if it isn't the same, you will get two groups with different agendas and that can quickly ...


10

You don't need any references, IMHO. Here's what you could (rather should) do: Quantify the Cost of Delay! Let's assume that it takes 1 week to test the feature(s). A 2-3 week delay implies that the feature won't be available till at least the 4th week. And that too assuming 100% success. Add a fixing time of another week so that's about 5 weeks of delay. ...


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