Specialization in Information Technology is a fairly common thing. Due to the fact that the field of IT is vast and covers numerous intricacies it cannot be avoided that the IT specialist will at some point know more about certain technologies, approaches or domains than others. The question that kept me busy for the last couple of weeks is whether it is imperative for the software tester to specialize, in order to survive?
I consider myself to be a context-driven tester, mainly because I feel that context-driven testing facilitates the use of the brain. That’s cynical and yet also true. On a day-to-day basis in our line work we frequently meet our worst enemy; complexity. There are numerous ways to battle complexity and context-driven testing is at the very least a software testing approach that identifies complexity as being part of the craft and stimulates the tester to think freely about it. That singe fact is a major win over other schools of thought.
On the other hand I also feel that context-driven testing is a generic approach; there are generic principles that govern the way we master the problems we face. We need, for example, creativity in our line of work. Having recognized this we can study the way creativity works and use that knowledge to our advantage. I find myself more eager to focus on the generic aspects of the work than on the specializations that are often the focus of the context in which we test. I do not think that we can easily say that once we know all about banking we know all about testing banking applications. The same goes for mobile applications, cloud applications, specific architectures, frameworks, programming languages, tools or quality characteristics. The temptations of becoming very good at testing in a specific context are numerous, but should we yield to those temptations?
I found myself wondering about this topic because currently business rules and business logic are a serious part of my context. Now the field of business rules is an emerging one, I believe it started to develop in the 1990s. And there is not a lot of focus on business rules from a testing perspective. It is a niche market but it is also a market that has a chance of becoming quite popular. If we are to believe one of the founding fathers of business rules, Larry Goldberg, it is a very elegant and simple solution to reducing complexity in systems, because, for the first time, it strictly and consistently separates business logic from technical implementation. Larry has a convincing story.
Now if job security, financial rewards and recognition of being one of the ‘pioneers’ in business rules testing are the rewards that can be had from specializing in this particular field, is it then okay to specialize? This time I’m not so sure about rejecting specialization without a closer look. After all, it may be a relatively easy way to survive and thrive…