are you hiring employees just for testing or is it done by your developers?
if you hire them, what are your experiences?
what is the ratio of them to your developers?
what kind of testers do you hire? do you use college grads or do your testers are masters and as good as your developers?
do they make a huge difference for you and in what way?
Edit: And if you don't, would you want your company to hire testers or are you fine with the way you are working?
In my company we have several full time testers that takes care of the usability and spit shine testing.
The functional testing is mainly done by the developers when unit and integration testing the code.
This split of responsibilities has worked out very well for us, and offsets some of the testing to eyes that are not blind to the faults of the system.
I currently work in QA for a medical device company (soon to be a developer, Sept. 1!). We have 4 full time "professional" QA techs (including myself) and 2 interns/temps. We have about 15 developers, which gives us almost a 3:1 ratio of developers to QA techs.
Most of the full time QA people are experienced, with the exception of myself (I began as a temp and was offered a full time position). We could definitely use more testers as our code base is growing very large.
In the companies I have worked for, the testers are called "Sr Developers." Testers in general are a key, since testing your own code never works.
We have a 2-3 QA Engineers for each software project. Unit tests are written and maintained by developers, but QA test for usability, compatibility, bugs, etc. They also write extensive acceptance (and other non-unit) tests using Ruby and tools like WATIR.
We have 3 testers (and another new one next week) to our 11 developers. Having testers has helped out my code considerably to find little things I didn't think of, or completely iron out bugs by helping with the building a test plan into the design of whatever project I'm working on.
We have one tester for every 2 developers. They are considered professionals also, most having the ISEB Practicioner qualification.
They follow a rigorous testing methodology and form a key part of the development process. They also do a lot of work with automation which is very helpful for regression.
Of course we do developer unit tests also and look for these to be completed to a high standard. All are essential to a successful enterprise level development.
Also, you need testers to pass the Joel Test ;)
I work on very large hardware projects, and we have more than one tester (validator) per designer just for pre-silicon validation. Post-silicon has its own pretty large group. I don't know how to relate to SW testing, but HW testing is considered a completely separate discipline from HW design, at least where I work.
I've done this for more than 7 years over many projects, and there are many more experienced validators here, so we definitely have experts in the art.
Validation has a big say in determining what features are in. It only goes in if we say we can test it. I guess you could say that in our case, we have an impact on the projects.
Non-techies as testers are a valuable resource. You cannot imagine what these guys can find bugs.
Our company has a QA team within software that handles functional/acceptance testing. They are a critical part of ensuring that a quality product was delivered.
Developers write code tests (unit tests, integration tests, maybe some system tests) but the tests developers write only find code problems. When your code tests are passing you know that the code does what the developer thought it was supposed to do.
By contrast, QA performs functional tests. The goal is to make sure that the system does what the user wanted, and these tests consist of user interactions with the system via the GUI or other interface. (Although it can still be automated using tools like functional tester.
You could have your developers write and perform the functional test cases, and in a small company you may have to, but in my experience developers don't make very good QA testers. It takes a different personality type to do it well. Developers are builders, QA are breakers.
Ratios depend on your level of automation, but without automation you'll want about a 1:2 ratio of QA to developers to allow QA to keep pace with development and not bottleneck releases. With more automation of functional tests, you won't need quite as many.
Short answer: you need both.
I am by myself right now working on a very decrepit codebase, I have frequently said that in order to really being moving forward we would need at least one other developer and at least one tester.
However, in all honesty, our applications are being all used internally by no more than 50 people at a time whose data interacts very little. As outdated as these applications are in the IT world, they're well liked by people who until 5 years ago were doing the same thing with paper and pencil. As such, the only particularly annoying effect of having our users do the bulk of our testing is that I am frequently distracted from my projects with a need for patches and bug-fixes.
I shudder when they start talking about packaging our flagship app as a product and selling it to our sister companies though.
If your team doesn't have dedicated testers, at least one for every two or three programmers, you are either shipping buggy products, or you're wasting money by having $100/hour programmers do work that can be done by $30/hour testers. Skimping on testers is such an outrageous false economy that I'm simply blown away that more people don't recognize it Joel Spolsky.
I am a Software Quality Engineer team lead, part of a large Solutions Quality Engineering team. SQE is separate from Software Development, but part of the same organization. Most of my teammates were hired as testers, but a few of us were brought over from development.
On my current project the ratio of developers to testers is almost 1:1 testers to developers. I think there are 13 developers and 11 testers on the project right now. It is a large, complex and mature system. The development effort is about 60 percent enhancements, 40 percent fixes.
Most of our testers are new hires, direct from school. Majority of the team is offshore and are assigned to either development or testing regardless of preference. Short-term contractors are typically developers who take a testing role until something better comes around. Inexperience and boredom are enemies of accuracy. I have not yet experienced a newcomer with rigorous testing experience. We have well-documented processes and job-aids. I spend a lot of time with newcomers during their first planning effort to enforce and explain the process and hammering home that the functional specs are the base of all planning. The turnover is high. The good testers often get promoted (becoming too expensive) or stolen by other projects. I’m biased in this, but I think the best testers are those who have development experience, but choose to be testers.
When the organization was less mature there was no separate test team or consistently applied test practices. When we merged with another organization with a designated test team it was a struggle to convince Project Managers that the extra costs were worth it. Seven years later SQE is indispensable and built in to all project plans.
Quality testing takes a lot of effort and planning. The developers component test before sending it to SQE, but all the integration, performance, product and UAT testing are handled by SQE. A product test with UAT for a typical release takes six weeks. After the first pass, most of the developers move on to their requirements for the next release.
Our customers are happy with the consistent high quality of our products. Developers who take jobs elsewhere are shocked at the shoddy test practices they find.
We do not, though I wish. It seems there is no budget for that. Never has been. Sometimes customer assigns a person to do the testing, but this person is rarely dedicated to full time testing or rarely has enough technical background to do them properly/systematically. As a result the products are buggy. As a bonus the general attitude is that developers shouldn't make bugs in the first place, therefore no testing is necessary.