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 run? ...
This answer should be seen as a supplement to Bruce's answer. I wanted to add a few more notes that wouldn't fit well in a comment.
A lot of the tools you already might use for unit testing will likely be useful - NUnit, mocking frameworks, etc.
Books to read: "How we Test Software at Microsoft", "Beautiful Testing", "Lessons Learned in Software ...
I think you may want to ask yourself a few questions first:
do you want to be involved in testing or in programming? In my experience, colleges are usually less than stellar in the QA domain, and tend to assume that testing is "any warm body" and useful to familiarize someone with an application before they start coding with it.
do you like ...
Good and Interesting question.
Here are some to make the tester's job easier:
Developers should perform basic testing before giving the product to the tester.
Include QA from the beginning of the project, not when the product is ready to test.
Work as a Team, not as two different departments [Developer & QA]
As the developer, never ask the QA to ...
In my experience, the best developer/testers bring what I call the boredom herusitic to software testing. Inother words, they often automate rote tasks so they can focus on testing and analysis of the software.
An example I use often is the "add contact" feature in an instant messaging or email client. To test the feature, I'd need to try long names, ...
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
Clearly both the developer(s) and tester(s), and almost certainly others, should be concerned whenever a defect escapes into production.
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 ...
No - there is no "right" ratio. The answer depends on the product (is it a web service providing junior hockey scores, or a space ship?), and the roles that programmers and testers play on the team. I've seen highly successful teams with a 15 or 20 to 1 programmer to tester ratio, and teams with a 1 to 1 ratio that made crap software.
In the high ratio ...
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 ...
Like Sam points out experience with SQL and/or with MySQL will greatly depend on the project and/or the company with whom you hope to work. SQL skills are one aspect of Software Testing that focuses specially on technology.
James Bach, an expert in the field of Software Testing with 20+ years experience, published a Tester's Syllabus for those who are ...
I think it is not a good idea because regression testing is carried out once you complete integration and sanity testing followed by system testing.
No, it is not necessarily a bad idea.
You should not consider it as a bad idea solely based on the order in which tests are carried out.
Regression testing is a type of software testing which ...
The whole team regardless of responsibilities should shoulder the blame. It is not a "test escape" but a "team escape". Testing is not only a department, it is also a discipline that everyone in the team should be involved in.
Personally I find that tester who codes in addition to great testing skills is much more effective than the non-technical equivalent.
A techical tester can esentially bring more "weapons to bear" on testing problems than you could without those skill sets. Some examples:
Need to generate some test data? Write a tool to do it.
Need to check security access ...
Treat them as equals.
I have seen a lot of developers thinking they are more or better then testers in their companies and also treat them that way. Developers and testers have a similar goal: Making high quality software.
Firstly, currently being ranked #1 on this site shows that you already have a good idea abou the basics and would get most positions based on what you know already. :-)
The exact tools that you are going to use would vary job-to-job dependent on technology, so I would actually research and find the tools that you want to use, gain experience in those and ...
You describe several skills that are advantageous in a tester: analytical skills, the ability to find flaws, and tolerance for repetition. You also seem to be interested in testing.
A potential disadvantage from your own admissions: reluctance to take ultimate responsibility and, to a lesser degree, discomfort with starting something from scratch.
Just a few quick ones off the top of my head:
Run the code they've completed at least once on their machine before marking it as 'Done'.
Consult with QA on their intended route to implement a feature or bug fix to help flush out potential issues or bugs before even one line of code is written
Encourage QA to participate in sprint planning/grooming, design ...
I've worked in both roles for a while and my recommendation is:
Pair (before coding when possible) on test plans
See QA as an asset that is protecting you and customers from the mistakes we all make
Have an open mind when a QA approaches and avoid the (common) mistake of explaining away an issue as their lack of understanding
Don't assume that they can pass ...
I cannot speak for the industry in general, but at places I have worked, developer-initiated smoke-testing is a common practice if builds delivered to QA tend to be unreliable.
I had a job as a test lead on a team that required developers to smoke-test the builds. At first it was a painful process, taking up most of a developer's time for an entire ...
"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 ...
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.
The problem I can see with counting defects, is that all defects are not equal. You might move a release deadline when you find a single bug - a showstopper resulting in complete data loss for the customer, but you'd be unlikely to do so for even a few dozen cosmetic bugs.
On the other hand - you can't just discount cosmetic bugs either. What if that ...
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 the ...
I would think that one thing you'll need to work on is changing your mindset. I have never been a coder/developer, but I do realize we think & approach a project in different ways.
As Carmi said, be curious & ask questions, but remember it isn't our job to fix the problem. We can provide suggestions and ideas but ultimately the decision on what ...
I've had success using tester/developers for code review of production code. I've found that developers review code thinking, "Will this work", while testers review code thinking "In what ways could this not work". I've also found that most testers discover new test ideas while reviewing production code.
I wrote a paper on the experiences of our team in ...
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. ...
I never see common agreement on any software-related titles.
In some shops where I have worked "Architect" implies a thinker, not a doer. For QA Architect, it means someone who thinks about QA, researches and suggests improved methods and metrics. Sometimes it's someone who trains others.
In other shops, "Architect" just means "very Senior". It's the top-...
Without being flippant, this sounds like you've got a serious communication problem in the team.
Given the limited timeframe, here's a few things to consider:
everyone in the team needs to know what a good bug report looks like
everyone in the team needs to search for a bug report on the issue they're seeing before they write up a bug report. This means ...
Professors make this suggestion. I suspect many of them don't actually know what a QA career entails since most of the professors I know are a bit divorced from the world of business. For more information, I'd suggest reading this very similar question (Fundamental Requirements For an Entry Level QA Engineer) and my response to it.
Some specific skills ...