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.
Category: Career
The Quest for Testers
I seem to be on a rant lately about interview techniques for getting good testers. Here I’m going to back up a little further what I do in order to find effective and efficient testers.
Interview Testers As If You Want Testers
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.
Should I Node or Should I Go?
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.
Interview “Technical” Testers for Broad Skills
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.”
Continue reading Interview “Technical” Testers for Broad Skills
Why Test Engineers Should Learn Node.js
Lately I’ve found myself wanting to develop test solutions that essentially require a simple web server along with a lot of client-side logic. For example, a Gherkin repository interface is something I’ve been longing to do. I don’t want to learn Pylons (in the Python world) right now and while my focus is Ruby, I’m not too keen on the overhead and bloat of Rails. I’ve done a Sinatra app (Dialogic). Sinatra is sort of Rails-lite, but that doesn’t really help me with an optimized solution that is going to use a lot of JavaScript. Thus did I come across Node.js.
Post Job Opportunities That Attract Talent
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.
The “Which Language Should I Learn” Dilemma
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.
Continue reading The “Which Language Should I Learn” Dilemma
Why Test Engineers Should Learn Groovy
If you’re a Ruby programmer than, like me, you may have a healthy distrust of the bloated thing that is Java. That said, Java really does have a lot of good points and it would be silly for any tester to discount it. Well, more to the point, discounting Java, the language, for your test solutions may not be a problem; but don’t discount the JVM. There are other languages that run on it, Scala being one of them. Here I want to talk about a language that a Rubyist should feel right at home with: Groovy. So let’s learn to be Groovy.
Why Test Engineers Should Learn Scala
Technical testers are often in a role where they have to utilize a programming language in order to build their own tools. Many testers will focus on languages like Ruby and Python for those solutions. The reason for that is because in the open source testing community, those languages do tend to be the focus of test solutions, the usual reason being given that they are “dynamic” languages. I’ve been in that same camp for a long time now. But there are cool alternatives worth exploring.
Why Test Engineers Should Learn Ruby
Test engineers most definitely should have Ruby as part of their tool set. This post is not so much to showcase my clear bias for Ruby when writing test solutions. This post is rather to showcase with some evidence why I have chosen Ruby as my tool of choice. My reason is mainly because you can do so many cool things with Ruby that other languages struggle with, particularly if your emphasis is on creating a DSL.
Your Ideal Role in the Testing World
Many of us are used to the question during an interview wherein someone says: “what would your ideal role look like?” It’s a question that has an answer that is easy to envision for me, but not always easy to articulate on the spot. Recently I left a position where my role had to be replaced and the manager was asking for ideas on what kind of person would be a good replacement. I had to put myself in the position of someone coming into that role and what would have made me stay in that position.
Testers Are More Than Their Skills
As a tester, you don’t just gather and manage test data. You don’t just create test cases. As part of quality assurance, you don’t just check requirements. You don’t just do reviews. In short: you are not just a bundle of skills. Rather, you are a personality and a mindset that happens to have a bundle of skills. So let’s talk about that.