Awhile back I talked about why test engineers should learn Groovy. Here I’ll focus on two specific tools in this ecosystem: Geb and Spock.
I’ve previously talked about being a generalist with specialist tendencies. I’ve said I’ve generalized in just about everything but I’ve tried to specialize in quality assurance and testing as disciplines. But what does that actually mean? Let’s talk about that.
A way back I talked about testing focusing on its roots as a technical discipline. I’ve also talked about how companies should interview testers as testers and, most recently, a bit about being generalists with some areas of specialization. I often hear, usually from hiring managers, that what I talk about makes it very hard to hire testers in light of modern day realities. So let’s talk about that.
Previously I had talked about valuing the “modern” tester as well as a possible defocusing of test practices. What a lot of these kinds of discussions swirl around is how much, and to what extent, testers are generalists or specialists. So let’s talk about that a bit.
The test discipline is an interesting spot right now which is where some testers are considered “too technical” and the fear is they don’t want to do the actual testing. On the other hand, some testers aren’t considered “technical enough” and thus the fear is that they put too much emphasis on the actual testing and not on the tooling around the testing. This should be a false dichotomy.
Here I argue against people, particularly certain companies, that seem to think it matters overly much if their test employees hold a certification, such as the CSTE.
One thing I often talk with testers about is a prime focus of our work: being credible reporters of useful and timely information in a diplomatically persuasive way. Coupled with that, I’m just coming out of a particular job wherein I feel my career took two steps backward and I’m now in process of regaining my forward momentum. The “steps backward” have to do with personal credibility and it’s why I’ve been silent for a month or so.
One of my pet peeves in the industry is the often very lackluster ways I see testers being interviewed. So let’s talk about that a bit.
As a tester it can be hard enough figuring out what technologies you should focus on to remain relevant in your career; not just at your current place of employment but at future ones as well. This gets even more difficult when there are “wars” within various communities about solutions and technologies. One such example is the supposed migration from Node.js to Go. So let’s talk about that.
I recently did an interview for a “technical testing” position and it was one where they had you do a whole lot of exercises for coding. In fact, as far as I could tell, that’s pretty much what all the interviews were going to be. The interview was thus, to me, largely a waste of time. I actually told the interviewers that and, to be fair to them, they were quite gracious, did engage me in discussion, and actually seemed to agree with me on a few points. But here I want to talk about why I felt the interview was a waste of time and what role “coding exercises” have when hiring so-called “technical testers.”
Earlier I talked about the opportunity descriptions that I would like to see. Having these done poorly is a huge pet peeve of mine. Some of this is just the fact that companies go through recruiters. There are many, many good recruiters out there but, quite frankly, there are many others that simply don’t know how to get what clients need — and quite, frankly, some of the clients don’t seem all that in tune with it either. This post presents a case in point.
A lot of times I get asked by technical testers the following question: “What language should I learn?” The rationale for the question is obvious: there is limited time and they want to focus on that which will do them the most good. The good news is: this is a false dilemma.