I once went on a job interview for a Senior QA position and after a brief face to face with the program manager, I got to sit down with the guys who actually did the QA work. I've heard their stories before, and I've heard them since from various other people at different companies. The way it goes is this: We have to write the test cases, run the test cases, and we have to automate the test cases.
I understand there are tremendous pressures to save money. This guy can automate tests, make him a QA Automation Engineer. He'll create test cases, run them, and he'll automate them as well. It makes sense. After all, "QA" is in his title. It should be his responsibility. Or should it?
I understand there are tremendous pressures to save money. This guy can automate tests, make him a QA Automation Engineer. He'll create test cases, run them, and he'll automate them as well. It makes sense. After all, "QA" is in his title. It should be his responsibility. Or should it?
Skillset differences
| For QA you need the following abilities:
| For QA Automation you need these abilities:
|
It's understandable to want all of these qualities in a single individual. You don't want to pay more people than you need. But both of these skillsets are specialties all their own with deeper specialties involved. One requires intimate knowledge and hands on in every stage of creating and maintaining an application, the other requires deep technical expertise in coding and testing frameworks. Finding a single person who has all of these skills is no simple feat, and when you dIo, they will inevitably find themselves tasked with far more work than a single person can accomplish. Documenting and running test cases is a full-time prospect, as is implementing, maintaining, and utilizing testing frameworks to automate appropriate test cases.
Which is another subject to talk about. Not every test case is worthy of the time it would take to automate it. Login tests for one, while logging in is a legitimate task, it's done by every user of the system. It can't fail without everyone knowing it. So what tests should be automated? I think this should be a Lead QA decision, but I'd start with tests that have found bugs. Especially if the test has found multiple bugs and different times in the life of an application. Multiple bugs at different times in the life of the app indicate either a design flaw or an area the developers might not understand well. These tests should be automated in order to guarantee they are run everytime there is a change to the system.
Other tests that could be automated might include more obscure system actions. If it doesn't happen often, but it's critical when it does is an immediate flag for automation. Not every functional test deserves automation. It's simply not worth the time provided there are plenty of unit tests and integration tests built during development, and in the case that there aren't unit or integration tests, automating test cases should be the least of your concerns.
Which is another subject to talk about. Not every test case is worthy of the time it would take to automate it. Login tests for one, while logging in is a legitimate task, it's done by every user of the system. It can't fail without everyone knowing it. So what tests should be automated? I think this should be a Lead QA decision, but I'd start with tests that have found bugs. Especially if the test has found multiple bugs and different times in the life of an application. Multiple bugs at different times in the life of the app indicate either a design flaw or an area the developers might not understand well. These tests should be automated in order to guarantee they are run everytime there is a change to the system.
Other tests that could be automated might include more obscure system actions. If it doesn't happen often, but it's critical when it does is an immediate flag for automation. Not every functional test deserves automation. It's simply not worth the time provided there are plenty of unit tests and integration tests built during development, and in the case that there aren't unit or integration tests, automating test cases should be the least of your concerns.
