Should testers code, should developers test? What is test?
eBay posted a unique job posting for a Software Engineer in Test (Don’t look at it now — see screenshot at the bottom of this post later). This is a great description of the development culture which supports testing, not just focused on test automation. This is a key sentence they mention about their candidate: “……. and your inquisitive nature and desire to dig into the unknown are two of your strengths.”
For a large company like eBay, it’s possible to pull this off. Many engineers will cheer this new world of testing. However, many companies don’t use TDD. Nor do they pair. They also aren’t much of a fan of Scrum or Kanban. In that case, the whole scheme collapses.
I decided to modify the job description a bit. This is the culture that I would want. These are some of the modifications I made:
- I won’t mandate that developers test. I know some excellent developers who just don’t have the DNA to test without looking at code. I am OK with that.
- You don’t “write tests” — that isn’t testing. Some people can write and test. I want to make that optional.
- I want to be very clear that test automation is different from testing.
- I want good testers who can do a “chalk talk”, even if they don’t write code. I have a strong belief that any tester, no matter how weak, can do a “chalk talk”.
Modified job description
What is Product Development like in the — — — — — ?
— — — about the organization — — — -
We are continually striving for the highest quality, and work in small focused teams following bits of Scrum, bits of Kanban, with a healthy dose of Extreme Programming (p.s these aren’t buzzwords, we mean it when we say we do this stuff).
Our cross functional teams have Product Management, all aspects of Product Development (including DevOps and Test), and UX all working together on a daily basis.
Testing consists of two parts — Risk and Quality Engineering (QE). We always select QE engineers who like testing in addition to being good programmers. While QE engineers may also find issues related to risk, the outcome of QE is a strong safety net which allows rapid changes in the software. The term Quality Engineering is a reference to engineering high quality software. This is similar to a building which is robust. It does not address risk unrelated to construction.
Risk engineers (Testers) on the other hand are focused on discovering any risk to customers or other users, e.g., customer support.
We allow developers to determine how they want to participate in risk testing. Risk engineers have a sense of risk depending on the feature and the team, e.g., experience level of the developer. They may take the initiative to pair with developers to counter risk.
Risk engineers evaluate risk related to customers/users, systems, complexity and the environment (these are broad representative topics).
We expect Risk engineers to be able to do a “chalk talk” with developers (James Bach mentions this in a video). For Risk Engineers, good computer science knowledge is a higher priority for us than programming skills.
Working at — — -is a rewarding, challenging and inspiring experience.