Tag Info

Hot answers tagged

61

As a tester, I can say that I'd prefer to work on a team with a high score on the Joel test. However, the Joel test doesn't necessarily cover some of the things that testers run into. I actually wrote a version of the Joel Test for testers. I didn't think I had the clout to call it the Alan Test, so I just called it the Test Test. Here's what's in it. The ...


30

Should QA push for programmers running QA's automated tests? Yes, but I'd also suggest that if the programmers don't seem to, it's probably more productive to find out why before pushing harder. What's preventing them? Access to proprietary test tools? Difficult to setup easily on dev environment? Results not meaningful or easy to read? Too slow to ...


21

Disclaimer: I am approaching this as a programmer (who is here mostly to learn how to better interact with our testers.) It's important to remember that the developer has not always been told how to test the code. Although we wish it wasn't true, the developer was given a set of requirements from someone who really didn't care about every aspect of the ...


18

Although unit tests are normally good enough, it's nice to see a developer ensure that they've run a process from start to finish, not just the unit tests. Because the types of tests that should be run vary greatly with the type of application, I would discuss with a testing point of contact for the product. With new developers to me, I usually ask them ...


15

What has worked well for me is the following steps. The developer makes their best effort at writing good code. The developer gets a code-peer review from another developer The developer runs their unit tests, and checks that they all pass. The developer and the tester sit down for a review: The developer walks through with the tester to let them know ...


14

I definitely feel your pain. As noted in a question I had (I'll link in a minute) I too work for a 10-digit revenue company, and our primary software has 0 automated tests for over a million lines of production code. It boils down to the same philosophy that a lot of developers have about using external libraries rather than rolling their own: we fear what ...


12

In my experience ... Execute, YES. Maintain NO. Context for my comment. I am assuming Programmers in your question = developers of application, not testers with programming skills I think that there is an inherent motivation that testers, (even dedicated software engineers in test) have that developers don't, and that is that writing, running and ...


11

I found Jerry Weinberg's comments about pinpointing in "Perfect Software: And other illusions about testing" really helpful. (My copy's at work, so this is from memory). Jerry comments that responsibility for pinpointing a bug's exact location sometimes lies with the programmers, and sometimes with the testers. In my experience, the most trouble occurs when ...


9

If the QA team is not embedded in the development team I don't think the whole process will run smoothly. Development should always write unit tests, not the QA team. This is because development has more insight in the code. I would let the QA team write more functional test scripts.


9

I think you'll need to understand why they are being nay-sayers. It may be that you've landed in the snake pit of office politics and you're wondering why because herpetology isn't written in your job description. Some of the complaints you may have heard from the Knights Who Say NIH (Not Invented Here)! may include: Why Change? We've always done it ...


9

As a tester on a small team in a large organization, my answer may be skewed from that of a tester in another situation. I'm all fine for testers fixing bugs, but, we also need to realize that we specialize in testing, and developers specialize in coding. We could fix it, and it could break something else that we don't know about. At the end of the day ...


9

I know this problem way too well. There's no "right" answer, unfortunately, but there are some things you can do to help with this problem. Dependency map - do you have a list of application features that have heavy dependencies and tend to break when changes occur in other areas? If you know changes in feature X tend to break feature Y, you know you ...


8

I think it depends on two primary elements: Are your testers embedded on your software engineering teams. Is the output of your tests intelligible and useful to engineers. Obviously it's folly to think that engineers could run tests from some other shadowy team that they have no rapport with. However, if you do have engineers and testers embedded on ...


7

This depends on the organization. Where I have worked, QA teams tended to prioritize breadth over runtime or simplicity of setup. The "QA environment" may require some special settings and configuration for mock objects, fake data, and so on. Developers, on the other hand, prefer tests that run quickly so that they can be integrated into their ...


7

I'm going with my favorite response here: it depends. Sometimes the decision is made because that's the language the tool supports. Sometimes the language is a flavor of the language used by the development team - this often happens where there's an expectation that the development team will be writing at least some of the test automation code. Sometimes ...


7

No, they shouldn't. The major reason is that the natural role of Developer is to stand up for idea that "the program is working". The natural role of QA is a direct opposite: to prove that "the program is not working". If the same physical person acts for two opposite roles, this may lead to compromises with themselves. Specifically speaking, sooner or ...


6

Seems like there is a disconnect between management and the QA Team, although I can't tell what Management is buying in if the QA Lead is outsourcing when you have done work. Communication could help, but having it come from the top down should be done diplomatically. Try to find out from the QA Team what their issue is, do they fear automation will put ...


6

In the past I have approached this by firstly defining the "quality bar" as to what is expected and had this agreed by the whole team. This includes setting a defect threshold for the whole team (usually 0 Sev 1's and 10 bugs per developer). When a developer or the team gets above this threshold they must stop adding features and fix their bugs. With this ...


6

If possible, sit down with them, explain the bugs. Explain how you found it and ask what kinds of tests they run before they say that it's ready. Start giving some suggestions. I've always found that starting the code quality discussion with some polite, constructive feedback has yielded the greatest results, letting them decide what what they think is ...


6

Should QA insist that all of their automated tests pass before checking in? At my last employer, the QA test suite involved multiple operating systems (and several different service packs of each), so it would not have been possible for devs to run those tests as part of the smoke/tdd tests. Some of the other tests could not be automated as they ...


6

I would make it automatic post-commit (via a trigger, or preferably a build system) that some kind of test is run. If the test is too extensive, then scale the post-commit test back to run in a reasonable amount of time (so the dev gets feedback quickly.) If the longform test (because longform makes it better, right?) takes X hours to run, I would ...


6

There seem to be a wide range of answers from "Yes, this makes sense." to "No, don't you dare." I can see both sides of the question so here's an answer in the middle. It depends. It depends on the role of QA on a particular project. If QA has been involved in the software development lifecycle, if QA has played a role in defining requirements from ...


6

As a manual/exploratory tester who works very closely with developers I find that the best way to improve my effectiveness is to learn as much as possible about programming in general, plus the languages/technologies (e.g. Drupal, WordPress) being used. Being able to code to the same standard as a developer is not a requirement to be an effective tester, but ...


5

Many companies will have QA's developing full functionality automation suits with tools like selenium. Those can be used as automated smoke tests and used with Build integration tools like Hudson and maven . Each time when the developers add something new to the application, they can just trigger the suit and see the applications functionality . This ...


5

My recommendation is to write them up in the bug tracking system that you use. If you don't have one, you need to get one started. If the bugs are that obvious, then their project manager should have words with them. The stats from the tracking software should be able to support your argument that they are careless, or need better understanding of the ...


5

I'd like to pipe in with one smaller piece here for shops where there is not a mature test automation framework, or the test automation takes too long to realistically run every night, or requires manual setup. I'm not sure about other shops, but my test automation for enhancements and bug fixes is normally done before the application code is ready with ...


5

I dealt with the same issue several years ago, and frankly, as a portion of this issue is personal integrity, corporate accountability can only go so far. As a realist, I acknowledge that increased accountability did help, but only temporarily. As soon as the individual realized they can get away x amount of misunderstandings, errors and vague specs, they no ...


5

There is no hard and fast rule for what kind of testing a developer should do before handing off to QA. It depends on the developer, the QA team, the organization, and the product. Testing is a means to an end, not an end in itself. The important thing is to pay attention to the quality of what QA receives and the quality of the released product. If the ...


5

First, make sure you can back up your concern with some objective data, e.g. bug counts from your bug tracking system. How you tell them depends on your relationship with the developer. If you trust and respect each other, you can try showing them your objective data. They may not be aware that they're delivering a lot of bugs. If you don't have a strong ...


5

The general rule I try to follow is "Respect everyone's Time" - one of the lessons I remember from the great book "Lessons Learned in SW testing". This is what that comes in mind when I advice my team members whether to continue investigation or not and when negotiating the amount of help I give to development team on debugging.



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