Skip to main content

How to hire a tester

Being a tester is quite confusing: you write code, but you’re not a Programmer. You perfectly know business requirements, but you’re not a Product Owner. You handle test environments, but you’re not an DevOps. Role of technical testers in modern agile development teams is significantly different, and requires knowledge in many fields: software engineering, programming, test automation, environment management, …etc. Result? Hiring good and experienced testers becomes more and more difficult, since being one often means to be in temporary state before turning into programmer or product owner role. So, how to hire dedicated testers?

Screening job candidates 

We’re lucky ones working in IT, since it’s employee market, and usually you don’t have to search for a job – you receive the offers. For recruiter, first and most obvious phase of searching an ideal candidate is screening LinkedIn profiles. I’m not a recruiter, but from candidate perspective it’s looks too often like sending an offer whenever one will see ‘testing’ in profile. It really makes difference whether candidate is manual tester or automation engineer, or if he has one or seven years of experience. Proper screening will not only save your time, but also will help you to build future relations with candidates.

Role description 

“If you’re interested in changing job, send me your cv” – it’s not a joke, it’s a real message I receive often from the recruiters. Although above it’s an edge case scenario, there are still some more common issues. The bottom line is the more detailed offer you would provide, the better are chances for it to succeed. If you’re searching for a technical tester, it really makes difference if you’re in jvm or .net. Personally I have a habit of always replying (despite that I’m not actively searching for a job) for offers that are well described. Another thing is salary spread. Although I’m big fan of providing salary min & max values, it’s still a taboo. I have no doubt that providing full job details will be an advantage and I look forward for market to adapt.

Interview 

I’ve noticed that Interview questions for testers’ interviews are causing some concerns. I want to focus on interviewing test automation engineers, since I consider myself one. If your company claims to hire some of the best programmers, you should treat test engineers like so. You can’t ask programmers during interviews for solving complex algorithmic problems, and then ask people who would test their implementations “how would they test a pencil”. Tester’s mindset is one thing, but you can’t fake technical abilities. Good practice for technical testers’ recruiting is providing a home work task of implementing some test automation code, or even better – pair programming during the interview.

Onboarding 

“Here’s your laptop, and somewhere there is a pendrive with ubuntu. We have a full list of task so tell me when you’ll be ready” – another real life example, and you’d be surprised by the maturity of IT in this company. I think everybody in your team will get advantage of quick learning architecture, workflow and corporate procedures by the new teammate. Guess what – you can accelerate that process by providing new comers some kind of introduction. Whether it will be one day training or week of some peer assistance, both team and new worker will get profit. Although this blog is 100% independent, I can certainly recommend my current company in this field. In Allegro.tech every new employee passes through one and a half month bootcamp, during which you spend every two weeks in different team, and then you choose your final one.

Skills development 

Every geek likes to develop his skills and knowledge. Company should provide proper environment to keep their workers hungry for learning. Conferences and trainings are must, because that’s how you ensure they are up to date with newest technologies and solutions. Besides that, rummy idea is r&d day once a while. Yes, this is a cost for the company, but it’s still cheaper than recruiting for resigned positions.

Summary 

In above points I intentionally omitted salary issues, but for sure – valuable and experienced employees needs to be appreciated. Worth to noticed is despite the fact I wanted to point out core aspects, that would help to recruit good technical test engineers, in most cases if you change word testers to programmers, thoughts would be still valid.

Popular posts from this blog

Testing Asynchronous APIs: Awaitility tutorial

Despite the growing popularity of test automation, most of it is still likely to be done on the frontend side of application. While GUI is a single layer that puts all the pieces together, focusing your automation efforts on the backend side requires dealing with distributed calls, concurrency, handling their diversity and integration. Backend test automation is especially popular in the microservices architecture, with testing REST API’s. I’ve noticed that dealing with asynchronous events is particularly considered as challenging. In this article I want to cover basic usage of Awaitility – simple java library for testing asynchronous events. All the code examples are written in groovy and our REST client is Rest-Assured. Synchronous vs Asynchronous  In simple words, synchronous communication is when the API calls are dependent and their order matters, while asynchronous communication is when the API calls are independent. Quoting Apigee definition: Synchronous  If a

Rerun Flaky Tests – Spock Retry

One question I get asked a lot is how you can automatically rerun your test on failure. This is a typical case for heavy, functional test scenarios, which are often flaky. While test flakiness and its management is crucial and extensive matter itself, in this post I want to give a shout to the extremely simple yet useful library: Spock-Retry. It introduce possibility to create retry policies for Spock tests, without any additional custom-rules implementation – just one annotation. If you are not a fan of Spock testing framework and you prefer JUnit – stay tuned! I will post analogous bit about rerunning JUnit tests soon. Instalation  If you are an maven user, add following dependency: <dependency>       < groupId > com.anotherchrisberry < /groupId >       < artifactId > spock-retry < /artifactId >       < version > 0.6.2 < /version >       < type > pom < /type >   </dependency> For gradle users:

Performance Testing – Vegeta Attack!

Performance testing is crucial field of modern software development. Taking into account that in today’s world majority of app’s communication is web-based, it turns out to be even more important. However, it still enjoys less interest than automated functional testing, and publications on load testing subject usually focus on mature and complex tools like JMeter or Gatling. In this post I’d like to introduce command line usage of a super simple and lightweight tool for performance testing of HTTP services, which is Vegeta. Who is Vegeta  Besides Dragon Ball’s character, Vegeta is a simple load testing tool written in GO, that can be used both from command line and as an external library in your project. In order to use Vegeta, download executables from here . It is recommended to set environment variable for ease of use.  For Mac users, you can download vegeta directly from Homebrew repositories: $ brew update && brew install vegeta Vegeta’s Arsenal  Usage