What background do you look for when hiring a software tester? I'm not hiring and I'm not an agent: it's just a question I've pondered.
* Someone with a computer science degree? Is an in depth knowledge of computer science necessary?
* An ex-programmer? They'd have a good insight into the corners programmers will cut when schedules are tight and test cases which will have been difficult, annoying or boring to implement.
* Someone who liked breaking things as a kid? Although this probably applies to the entire human race. How does someone get good at learning how to break stuff?
* Just generally the sort of person who thinks of everything? Would they have certain hobbies or interests which would mark them out?
* Someone with all the certifications? Or been on particular course?
* Just someone with a lot of experience?
I know there's some professional testers in these forums and I'd very much like to hear what it's all about; I don't mean to antagonise forum members and I'm not trolling. Someone who can come in, find bugs that no one even knew where there and identify corner cases nobody else can would be an excellent team member but I've never worked with these professionals.
In my experience, the majority of the testers I've met have been from non-IT backgrounds and were moved into testing when other departments were laying people off. Most I've considered general dogsbodies without any particular skills. Their main value, as I see it, is programmers often have a fixed idea of how someone will use an app, and having someone else use it can be an eyeopener. Also, you can't always trust a programmer to test his own work. However that's a task a general dogsbody could fulfil: not someone who touts themselves as a professional tester.
At one place, the accounts team became the testing team when their department was downsized. The application was nothing to do with accountancy so they didn't have the advantage of domain knowledge or anything. Their roles were to do what most companies would do with automated testing tools. Automated testing tools existed back then and it would have been nice if they'd known enough about the technologies in their area of expertise to suggest one, which ended up being something the programmers piped up about. I guess the test team would be putting themselves out of a job if they suggested Selenium but they simply didn't have any interest in testing as a profession.
They followed a set of instructions (which represented a test case) by hand, manually clicking the mouse etc, and filed a bug report if it went wrong. The developers had to create the test case instructions because the testers did not have the skill, understanding or familiarity with the requirements to do it and thus all test cases were solely identified by the programmers. The testers performed no exploratory testing either. Indeed I've rarely worked anywhere that allowed the testers the luxury of just playing with the app to see if they could break it.
So the programmers saw no benefit from the testers at all. Without the test team I assume this would have been a task left to the programmers so I guess it freed them up to write code. But that's it. According to the manager, testers and programmers were paid similarly, which I find bizarre when the programmers could do the testers' jobs but not vice-versa.
Whilst I've described the worst example above, I've seen this pattern many times in other workplaces.
Any thoughts?
* Someone with a computer science degree? Is an in depth knowledge of computer science necessary?
* An ex-programmer? They'd have a good insight into the corners programmers will cut when schedules are tight and test cases which will have been difficult, annoying or boring to implement.
* Someone who liked breaking things as a kid? Although this probably applies to the entire human race. How does someone get good at learning how to break stuff?
* Just generally the sort of person who thinks of everything? Would they have certain hobbies or interests which would mark them out?
* Someone with all the certifications? Or been on particular course?
* Just someone with a lot of experience?
I know there's some professional testers in these forums and I'd very much like to hear what it's all about; I don't mean to antagonise forum members and I'm not trolling. Someone who can come in, find bugs that no one even knew where there and identify corner cases nobody else can would be an excellent team member but I've never worked with these professionals.
In my experience, the majority of the testers I've met have been from non-IT backgrounds and were moved into testing when other departments were laying people off. Most I've considered general dogsbodies without any particular skills. Their main value, as I see it, is programmers often have a fixed idea of how someone will use an app, and having someone else use it can be an eyeopener. Also, you can't always trust a programmer to test his own work. However that's a task a general dogsbody could fulfil: not someone who touts themselves as a professional tester.
At one place, the accounts team became the testing team when their department was downsized. The application was nothing to do with accountancy so they didn't have the advantage of domain knowledge or anything. Their roles were to do what most companies would do with automated testing tools. Automated testing tools existed back then and it would have been nice if they'd known enough about the technologies in their area of expertise to suggest one, which ended up being something the programmers piped up about. I guess the test team would be putting themselves out of a job if they suggested Selenium but they simply didn't have any interest in testing as a profession.
They followed a set of instructions (which represented a test case) by hand, manually clicking the mouse etc, and filed a bug report if it went wrong. The developers had to create the test case instructions because the testers did not have the skill, understanding or familiarity with the requirements to do it and thus all test cases were solely identified by the programmers. The testers performed no exploratory testing either. Indeed I've rarely worked anywhere that allowed the testers the luxury of just playing with the app to see if they could break it.
So the programmers saw no benefit from the testers at all. Without the test team I assume this would have been a task left to the programmers so I guess it freed them up to write code. But that's it. According to the manager, testers and programmers were paid similarly, which I find bizarre when the programmers could do the testers' jobs but not vice-versa.
Whilst I've described the worst example above, I've seen this pattern many times in other workplaces.
Any thoughts?
LOL!
Comment