Every now and then I stop to wonder about the world of testing I live in. A recurring theme that stops me seems to be that of automation.
Working with selenium, I'm getting a hang of page objects. Page objects seem like a nice way of saying to create classes of concepts that neatly pack things up together, so that you wouldn't have elements from a page dispersed around your actual tests. A great idea that helps maintaining, and really obvious to developers except for giving the concept a new name.
There are two test automation specific terms that leave me pondering: data-driven testing and keyword-driven testing. I seem to actually have some problems with those words. For me, both of these terms are fancy ways of renaming existing programming ideas to test specific concepts, and as such, create an extra divide between the testers and developers. The way these concepts are presented to testers new to automation gives the impression that these two extremely old programming ideas are somehow the center of test automation without getting really into the world that belongs to a developer.
To me, data-driven testing is just a way of saying that you should use variables. It's a concept I've been practicing with my 5&6-year olds, and they seem to start getting a grasp of it. Why should we in testing say data-driven for any other reason than introducing the idea of variables. And why would we need a separate concept for that? And keyword-driven testing is just a way of saying that we should modularize code for reuse, right?
I think these two words in particular have their roots in the idea that tester's can't code. Well, many can't. But treating them worse than I treat my 5&6-year-olds in regards to their intelligence and capability seems wrong. People can take the challenge. People appreciate being supported. And people appreciate when they learn the stuff that started off as difficult.
I don't dislike automation work because coding is difficult. Some coding is difficult, but test automation isn't the hardest of programming challenges there is out there. I dislike it because it's more boring than the other options I can use my time for. And I appreciate my time on manipulating my team's developers to do the automation stuff over implementing it myself - for the benefit of the team in general. I dislike it because it steals potential great minds and turns them into machines if given without appropriate support of a balanced perspective of what it can and cannot do. I dislike it because it turns into a silver bullet that downplays the role of thinking tester by giving us keywords you can call to create scripts without knowing how to code, and excuses of not learning the next step that we're perfectly capable for.
Is it just me? Most likely. :)
Working with selenium, I'm getting a hang of page objects. Page objects seem like a nice way of saying to create classes of concepts that neatly pack things up together, so that you wouldn't have elements from a page dispersed around your actual tests. A great idea that helps maintaining, and really obvious to developers except for giving the concept a new name.
There are two test automation specific terms that leave me pondering: data-driven testing and keyword-driven testing. I seem to actually have some problems with those words. For me, both of these terms are fancy ways of renaming existing programming ideas to test specific concepts, and as such, create an extra divide between the testers and developers. The way these concepts are presented to testers new to automation gives the impression that these two extremely old programming ideas are somehow the center of test automation without getting really into the world that belongs to a developer.
To me, data-driven testing is just a way of saying that you should use variables. It's a concept I've been practicing with my 5&6-year olds, and they seem to start getting a grasp of it. Why should we in testing say data-driven for any other reason than introducing the idea of variables. And why would we need a separate concept for that? And keyword-driven testing is just a way of saying that we should modularize code for reuse, right?
I think these two words in particular have their roots in the idea that tester's can't code. Well, many can't. But treating them worse than I treat my 5&6-year-olds in regards to their intelligence and capability seems wrong. People can take the challenge. People appreciate being supported. And people appreciate when they learn the stuff that started off as difficult.
I don't dislike automation work because coding is difficult. Some coding is difficult, but test automation isn't the hardest of programming challenges there is out there. I dislike it because it's more boring than the other options I can use my time for. And I appreciate my time on manipulating my team's developers to do the automation stuff over implementing it myself - for the benefit of the team in general. I dislike it because it steals potential great minds and turns them into machines if given without appropriate support of a balanced perspective of what it can and cannot do. I dislike it because it turns into a silver bullet that downplays the role of thinking tester by giving us keywords you can call to create scripts without knowing how to code, and excuses of not learning the next step that we're perfectly capable for.
Is it just me? Most likely. :)
