Premise 1: Low Qualification Level of Testers
Before the war, I worked as the lead of a testing team in a fairly large international company. I joined the company after working in financial automation. Additionally, I had a relatively free year, which I dedicated to studying the full software development lifecycle: from architecture design and project planning to managing Scrum projects, implementing code, CI/CD, and testing.
As a lead, I conducted numerous interviews and found that the skill level of testers was catastrophically low. Consequently, the perception of testers has always been (and remains) that of the least qualified IT professionals. I would compare it to how a cleaning person mopping the programmers’ office floor is tangentially connected to IT simply because they work in the same environment.
Premise 2: Training Companies – Modern “Infogurus”
Then the war started. Chaos ensued, and companies reacted differently: some financed employee relocations to safer cities, while others abandoned their staff to fend for themselves. The company I worked for chose to cut staff, starting with testers, followed by entire teams handling projects in development. Salaries for the last few months went unpaid, but that’s another story entirely.
Some time later, I was offered the chance to design and teach a course on testing, and of course, I agreed (I genuinely enjoy teaching). However, my initial course outline was rejected for being “too complex” and “unnecessary.” The target audience, I was told, consisted of “failures and retirees” 🙂 I was advised to review competitors’ courses. Upon doing so, I realized that the goal wasn’t to teach but to sell fluff, capitalizing on the trending slogan “break into IT” (a phrase I despise).
Despite this, I developed a somewhat informative course (though I had to include some filler topics at the insistence of the “infogurus”). Over 100 students graduated from the course, and reviews can be found in this video (ukrainian language):
Unsurprisingly, I didn’t receive payment for half the courses sold. But what else can one expect from “infogurus”? (That’s a story for another time.)
Premise 3: Experience with ERP Systems
I have substantial experience with ERP (Enterprise Resource Planning) systems and am a strong advocate for their use. The concept revolves around an interconnected ecosystem of programs that handle entirely different business resources yet work together seamlessly.
A simplified example: consider an e-commerce store that includes a website, a call center, a warehouse, and an accounting department.
- On the website, a customer places an order for a product—this is one “program.”
- The order goes to the call center, where an operator contacts the customer to confirm availability, delivery dates, etc. Incidentally, this step is a uniquely frustrating Ukrainian practice. I hate when companies call to confirm—I’ve already made my choices and even paid. Why call? Nevertheless, this second program handles call center operations.
- After confirmation, the order moves to the warehouse, handled by a third program for inventory management.
- Finally, data about sales, payments, stock deductions, and employee work hours flow into a financial accounting program. This consolidates everything into both management reports (for the owner) and accounting reports for compliance purposes.
What is an SDET?
“A Software Development Engineer in Test (SDET) is also a developer, but their focus is on testability and the overall testing infrastructure. SDETs review designs, scrutinize code quality, and evaluate risks. They refactor code to make it more testable and write frameworks for unit testing and automation. They are partners in the SWE codebase but are more concerned with improving quality and test coverage than adding new features or enhancing performance.”
— James Whittaker, Jason Arbon, Jeff Carollo, How We Test at Google