Welcome to the nuanced world of software testing!
-
Share:
-
-
-
With over 14 years of experience under my belt, I've navigated through various roles in this dynamic field, from a hands-on testing engineer to a manager leading teams. This journey has afforded me a comprehensive view of the software development lifecycle, replete with its challenges and triumphs.
In the software industry, it's rare to see engineers eagerly approaching managers to initiate detailed planning, document drafting, risk assessment or to delve into the formalities of bureaucratic processes. Yet, the foundation of robust software development and testing lies in four critical pillars: Planning, strategy, risk management and reporting. Neglecting these is akin to removing the elephants from Terry Pratchett’s Discworld — what remains is a precarious frisbee, likely to crash unexpectedly.
A common skepticism among engineers revolves around the feasibility of precise time estimations and process formalization, given the unpredictable nature of future tasks and the ever-lurking bugs in testing. However, this view often stems from a satirical perspective on the rigidity of management practices.
The perception of detailed planning and time estimation as mere tools for managerial oversight — akin to peering over one's shoulder — is prevalent. It's seen as a way to ensure engineers aren’t idly watching videos instead of propelling the project forward. This scenario typically culminates in a cycle of missed deadlines, incessant overtime and the stress of last-minute deployments.
This article aims to shed light on a different perspective, arguing that time estimation and planning are essential not just for managerial convenience but are crucial for engineers. For developers and testers, effective planning and strategic foresight act as both shield and sword, ensuring a stable and secure professional life.
Management ultimately wants a successful project completion and generally isn't too concerned about how engineers achieve it. I fully acknowledge that without formal processes, documentation, and Agile ceremonies with lengthy meetings, coding can be quick and fun, bug hunting like a safari, and creativity can flourish. Business finds the Agile ceremonial and lengthy meetings quite expensive, and management would happily forego them for an extra feature closed per sprint.
But then comes the day when something goes wrong. Maybe the manager is having a bad day, or the project crashes on the production server again, or a new feature hasn't been implemented for half a year. What should be done when the temptation arises to say, "I feel like the developers are slacking off," but means, "I think you are slacking off," or "I think this developer is weak, lazy, not interested in the project"? There are many opportunities and desires to present sometimes quite objective complaints, sometimes fabricated ones, but these complaints are based on feelings and experiences. As you understand, we are all human, and it's very difficult for others to convince someone that their feelings are incorrect.
When the world starts to express feelings like "I think," "I believe," "I have the impression," then comes forward the very shield and sword I mentioned earlier, or even a stake, which we must use to cope with these demons through objective measurements.
To add a constructive angle, let's consider task breakdowns, time estimates, and assessments made by managers, developers, and testers. We'll focus on what we plan to test, avoiding any unnecessary interference with the code, as clearly documented and communicated, including in the risk assessment. We should also consider the available hours and resources for developers and testers.
Remember, no one works 8 hours a day for many years. At best, engineers work an average of 6 hours a day, often just 5. Yes, they can sit for 12 to 14 hours, but this is during an emergency, and you can't keep them in that state for long. IT development is not a sprint; it's a marathon that you either withstand or not.
So, if a manager has accurate measurements: This is how many resources we have, and what needs to be done. Then, the manager won’t be telling the developer emotionally, "You are working poorly," "Your pace is bad." It can be, but it will be based on real figures and objective data, and then you and the manager will analyze why and what happened.
When you have measurable indicators, you, as an engineer, are protected from feelings, experiences, and most importantly, from "Let's just make the engineer do the same thing better and faster." You free yourself from management based on feelings, emotions, and this shaky ground, and move to process management.
This conversation is inspired, of course, by practical experience, actual situations, especially those where managers have feelings that then turn into deadlines and timelines without any justification. Please don't do that. Managers, take care of your engineers, give them the opportunity to work in marathon mode. And you, developers and testers, remember, part of the management work is on you. It is your protection.
Learning the ropes of this gig is crucial unless you fancy making things worse. Motivation and eagerness alone won’t cut it; you need the knowledge and the skills. I suggest kicking off with risks. Why, you ask? Well, it's high time we all switch up our mindsets and get savvy with managing risks, learn how to correctly search for solutions and prioritize them, in this unpredictable and changeable world.
Best wishes to all in navigating this challenging yet rewarding journey!
Podlipenskyi Stanislav
