I was asked a few questions via mail. Here is the first of some quick answers to these:
What is the role of a Test Architect? There is not a single definition of the test architect role. A test architect is an advanced test developer whose scope is larger and who solves harder problems than the average SDE/T. The specifics of what they do varies greatly. They might be solving hard, particular problems. They might be the one called in to solve the seemingly intractable issue. They may be designing a new test platform. Or, they may be determining group test policy. Any and all of these fall in the scope of the test architect. The work they do is often similar to that of an SDE/T. The difference is often one of scope. An SDE/T will often own a specific technology or be responsible for implementing a part of a system. A test architect will own the approach to testing or developing entire systems.
Are you a test architect or do you have a different idea of what one is? Please leave your opinions in the comments section. I'd love to see a dialog develop on this subject. It's something I'm interested in but that isn't all that well understood yet in most quarters.
I always thought of Destry H. (you know who I mean!) as the model of a modern test architect (he used to be one, though now he a Director of Test, I believe).
ReplyDeleteWhen I think about it, I think about what made Destry a great tester even back in the early days of Microsoft Access -- he was generally known to be the one who always found the bugs that made you shake your head and feel a little dumb that the bugs were there. Would a customer have found them? Maybe. But did they have to be fixed? Definitely.
And (again by report) he was not full of himself, he never did it by trying to find the great bugs -- he just found them because he cared about his work and would always be thinking beyond the the next automation run into the consequences of a design.
Reportedly by others, the term "Freaking Destry bugs" (Rated G language for safe family blogging!) referred to those bugs which "since a tester had to find it, a developer had to fix it." Devs may curse them, but deep down they know that he had a lot to do with making products not suck.
Seems like that viewpoint, thinking beyond the basics of the test job (which one does not have to in order to be an excellent tester, by the way), are what leads one to be an excellent test architect....
I'm going to be doing a series not on testing but on the people that carry it out. This will be a post
ReplyDelete