Pavol Celuch

"Shift left” sounds good on paper. Faster feedback. Earlier testing. Cost savings. But here’s the uncomfortable truth: shifting left won’t save you if your culture stays stuck. You can throw tests into CI pipelines, automate early, and chant DevTestOps until the walls echo. But if your teams still treat testing as a phase, quality as someone else’s job, or feedback as a nuisance, all you’ve done is moved broken thinking upstream. I’ve seen companies install shiny new tooling with zero conversation about shared ownership. I’ve seen developers resist writing tests because “that’s not what we do.” I’ve seen testers struggle to add value early because they’re still expected to “verify the build” instead of shape the build. Shifting left without shifting culture is like moving the finish line but refusing to train differently. You don’t get better outcomes. You just get earlier dysfunction. If you’re serious about building quality in, here’s what needs to shift first: - The belief that quality is everyone’s job, not just the testers’. - The space for testers to be part of discovery, not just delivery. -The trust that cross-functional collaboration is not optional, it’s foundational. True shift left starts with mindset, not tooling. With conversations, not compliance. With people, not processes. If your culture still rewards speed over safety, delivery over discovery, and blame over learning, no amount of leftward motion will get you where you want to go. I help companies get this right not by selling buzzwords, but by rebuilding how teams think, act, and deliver together. If that’s the kind of change you’re ready for, I’d love to talk. #softwaretesting #softwareengineering #qualityleadership #teststrategy #brijeshsays

173

27 commentaren

Most junior engineers think they’ll be rewarded if they: → close lots of tickets → stay late and jump on every bug → write clever code and push big PRs But you’re rewarded for being the person who: → ships predictable outcomes, not surprises → prevents incidents before they happen with tests, alerts, and runbooks → makes the team faster with clear docs, small PRs, and crisp reviews → understands the user and ties work to a metric the business cares about → reduces cost and risk: cleaner designs, fewer moving parts, simpler ops Hard fact: believing “more hours + more tickets = growth” is a recipe for burnout and stalled careers. You’ll feel busy, but you won’t be valuable. Do this instead: → Pick one metric to move this quarter: p95 latency, crash rate, signup conversion, cloud spend. → Own one thing end to end: read code paths, write a tiny RFC, add dashboards, add alerts, add tests. → Kill recurring pain: automate a flaky deploy step, fix a flaky test, script a one-click local setup. → Review like a pro: spot risk, ask for data, suggest simpler designs, add examples to docs. → Learn the domain: sit with PM, Support, or Data weekly; collect real user stories. → Teach one person: pair once a week, share your notes, leave the project better than you found it. Yes, work hard. Give it your all. But keep asking, “What action creates the most impact for my team and our users today?” It may not feel like much each day. Some days it is just one small improvement. Stack those improvements for 90 days and you become the person people rely on. Stack them for a year and you become the person they plan around. You’re not paid for sweating more. You’re paid for being hard to replace.

811

40 commentaren

Waiting half an hour for your tests to finish? That’s not feedback - that’s punishment 🧪 You might have been there: Every new integration test adds another minute to your overall build time. Twenty minutes turn to thirty. CI times explode. Developers stop writing integration tests and become unhappy. Flaky tests appear. Bugs slip through. Releases slow down. But what if you could slash that time, without deleting a single test? With Spring Test, that's possible. It's a hidden gem called Spring TestContext Context Caching 🏆 So, how do you know how many contexts are spinning up? More importantly, how do you figure out why they aren’t being reused? That’s why I built Spring Test Profiler ⏱️ Meet Spring Test Profiler - the free, open-source x-ray for your test suite. Integration is as simple as this three-step process: 1. Add the dependency (Maven/Gradle snippets appear on screen). 2. Run your tests. 3. Open the report at: target/spring-test-profiler/report.html. Within the report, you’ll see: • How many contexts started, and why. • Which tests are sharing configs versus starting their own. • Exact diffs: profiles, properties, or annotations blocking cache reuse. The overall goal is to help identify cache misses and align your tests to reuse contexts for faster feedback 🚤 Spring Test Profiler: Profile. Optimize. Deliver. Try it yourself: https://lnkd.in/djXVJiNE Below is a demo of a section in the report to analyze and compare two contexts 🆚

49

5 commentaren

Another day, another engineer asking: “SSM or Secrets Manager?” So, I finally wrote it down. Whenever I review a low-level design from one of my engineers and a secret is required—an API key, database credential, or any sensitive value—someone inevitably asks: Should we use AWS Secrets Manager or SSM Parameter Store (SecureString)? The answer isn’t always straightforward. In this blog post (the link is in the comments section), I break down the key differences, pros and cons, and share my real-world recommendations on when to use each. #aws #cloudsecurity #secretsmanager #ssm #devops #serverless #platformengineering #awstips

128

12 commentaren