Tag Info

Hot answers tagged

28

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


27

Short answer is "everyone" - as was pointed out in other responses. For the long answer, I'll refer to an article I wrote recently on this exact subject, The One That Got Away.


20

I'm not sure what you mean by "responsible" in this context? who should get yelled at who should be fired who should get demerits on their next annual review who should take action to cure the problem something else Clearly both the developer(s) and tester(s), and almost certainly others, should be concerned whenever a defect escapes into production. ...


13

I feel like certain teams or people are in need of tough love when it comes to this. When there is a quality issue, point out that it could have been prevented by the rest of the team following some best practices. For example, if there are frequently broken builds, broken deploys or entire features that are blocked or not functional due to bugs you can ...


12

I think the fundamental difference between the tester and the developer is the difference between synthesis and analysis. The developer synthesizes code. He builds up things, putting pieces together and figuring out fun and unique ways of combining those distinct little bits to do wonderful and amazing things. Testers are all about analysis. Once it has ...


11

A good test manager has a number of key attributes. I tend to think that the best managers are like good, professional sports coaches. They have played "the game", at the highest levels, they know what is required to be successful and achieve the results you are after. Translated, they should be a great tester themselves and be able to test hands on if ...


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

I would like to emphasize that usefulness (like quality) is a subjective and personal/organizational thing. In other words, the general question "Is it useful?" needs context, of which some person(s) is the most important part. I made the distinction because I found that people lump checking into testing in a way that I found *un*helpful. For example, ...


9

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


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


8

"I believe one contributing factor is a matter of perspective, that a great tester approaches software in a different way than a developer." I agree! And I think that's one of the primary factors which allows testers to add significant value. Here's something I wrote a while back: In my experience, developers tend to be optimistic folks, while testers ...


8

Although I completely agree with TristaanOgre's answer, I do have another piece to add. Developer's are often (even if they don't realize it), emotional attached to their code. They've spent hours/days/weeks, sometimes years putting it together. They have taken what someone wanted and (normally) crafted those requirements into a working, and often elegant ...


8

Part of this starts at the top. Among other things, the team's performance should be judged in terms of quality. You need to choose your quality metrics carefully so that the team's goal is to improve quality rather than just improving the metrics. For example, if you measure the team by bug count, people will stop logging bugs. Organizations go through ...


7

As said, everyone. This is why postmortems are important and valuable, as well as high-communication environments where people feel comfortable taking responsibility for problems without being afraid of blame. Get everyone who might have had a chance to eliminate this issue - management, PMs, developers, testers, business owners, and so forth into a room. ...


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


6

The distinction between testing and checking adds no significant value to the profession of testing beyond witty philosophical banter around the water-cooler, or lead to changes in our SDLC processes. Perhaps the concept of checks vs. test may add value if it causes testers to reflect on the purpose or intent of a test. But, would that lead to a change in ...


6

One way could be to get them to do end time with the end users and customers so they are aware of the impact of their work and don't just interact with a keyboard and screen. The company has to have a culture of it as well and it has to come from the top with managers leading by example A quick google for 'culture of quality' will bring up lots, e.g., ...


5

Testers are different from not only developers, but also everyone else in a software organization, because they are the only people whose primary mission is to figure out how the product could fail, and not how to make the product suceed. Developers spend their spare moments trying to figure out how the code can be refactored to be cleaner or an elegant ...


5

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


5

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


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.


5

The two obvious steps that you seem to have missed out: Perform the tests. Much may be done auto-magically, but manual testing is still a key aspect at integration and system test levels. Report the results. Whilst automated tests may generate a results file, you'll need to interpret and present the results in a format that is appropriate to the ...


4

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


4

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


4

Development and testing are two diametrically opposed disciplines. Development is all about construction, and testing is all about demolition. Effective testing requires a specific mindset and approach where you are trying to uncover developer mistakes, find holes in their assumptions, and flaws in their logic. Most people, myself included, are simply ...


4

Where I work, which has a very enlightened approach to QA/Dev, we actually have a report that details every bug found at customer sites, why it was missed in QA and what steps are being taken to ensure that similar bugs will not be missed. We understand that everyone is human. If we expect developers to occasionally wirte a bug into the code, we should ...


4

This may or may not help you, but my guess is that software bug cost is likely power-law distributed. This roughly means that there are many bugs that don't cost very much to fix (imagine a bug found from unit test results early in production code; the cost to fix that is essentially zero and there may be several of these kinds of bugs) and that there are a ...


4

It's common to see graphs in textbooks of the costs of fixing bugs found at various stages: The source for the graph is Software Engineering Economics by Barry Boehm, which is probably worth getting hold of. The cost of fixing a bug is a metric which probably has little value on its own. This article (Word doc) explains some of the problems: The ...


4

As with all positions the title means whatever the hiring company wants it to mean, nothing more. The term "QA Engineer" might mean "Tester", "Standards Enforcer", "Auditor", "part-time Developer/Analyst", all of these, or none of these. I've seen them all. In my company, the team used to consist of "QA Engineers", until we were purchased by a larger ...


3

Yes It would help to identify bugs at early stage of testing Development Team handles Design, Development and Unit Testing of Code. With SCRUM/TDD I am afraid if they have enough bandwidth to execute Integration/functional test scenarios If Developers run QA Automation code, We could identify - obvious bugs which are part of functionality - cross browser ...



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