The Pillars of Leadership

 💡 Leadership in IT: It Starts With You

Leadership isn’t about titles or control — it’s about authenticity, growth, empathy, and self-awareness.

👤 Authenticity

People spot fake. They notice when you say one thing and do another.

If you call your team a “family” but threaten disciplinary action the next day, you lose trust instantly.

Be real, be consistent — your words and actions must align.

🌱 Growth

Leadership means helping others grow, not cloning yourself.

If a junior delivers good work that’s not exactly how you’d do it, praise them. Then guide them.

Confidence builds competence — not constant correction.

🤝 Empathy & Flexibility

No two people are the same. Great leaders see individuals, not headcount.

Your job is to mix strengths and balance weaknesses.

A team of only “rockstars” or only juniors fails — just like you can’t build a house with only hammers.

🧭 Self-Leadership

You can’t lead others if you can’t lead yourself.

Know your triggers, manage your emotions, own your weaknesses.

If you don’t, your team will pay the price for what you haven’t yet learned to control.

In the end, leadership is not about power — it’s about trust, growth, and balance.

API E2E Tests – Your Application’s Real-time X-Ray

 🚀 What if API tests could do more than check small pieces of your system?

For years we’ve treated API automation as “low-level only” — tiny isolated checks that live far away from the real user experience.

But here’s the thing:

You can mirror your entire E2E user flow through APIs… and the value is enormous.

🔗 E2E API = Your Backend Mirror of the UI Flow

Map the exact journey the user takes in the frontend, directly through the backend.

No browsers. No selectors. No flakiness.

Just real business logic, executed fast.

It’s like having an x-ray of your product’s most important flows.

🛡️ A stronger safety net

UI E2E tests catch issues last.

API E2E tests catch them early.

Together:

UI → validates the experience

API → validates the system

A double layer of confidence.

🎯 Instant FE vs. BE debugging

If the UI flow fails but the API E2E flow passes → Frontend issue

If both fail → Backend or integration issue

No more “whose bug is it?” meetings.

🔍 Clarity for everyone

E2E API flows make hidden logic visible.

Engineers, QA, PMs, even non-technical stakeholders can understand what’s happening under the hood.

It’s transparent. It’s traceable. And it’s fast.

💡 Final Thought

E2E API testing doesn’t replace traditional API checks — it completes them.

It sits perfectly between low-level tests and fragile UI automation.

Sometimes the smartest innovation is simply using what we already have… better.

Test Automation – Value Over Perfection

 🛑 Stop trying to build the perfect test automation framework.

Because by the time you finish, your product will have already changed.

🚀 Test Automation: Progress Over Perfection

One of the biggest traps teams fall into when building a test automation framework is trying to make it perfect from day one. But here’s the truth:

Frameworks evolve together with the product. You can’t design one that lasts forever.

Here are the principles I’ve learned over the years:

✅ Focus where it matters

Start with the major user flows. No one will thank you for automating error messages if critical bugs slip into production.

✅ Keep it simple (KISS)

Don’t over-engineer. A framework that’s hard to maintain or confusing for new joiners adds no value.

✅ Think about your team

If your QAs can code, use the language most widespread in the team.

If not, go pragmatic: Postman for APIs, record & play for UI.

The best framework is the one your team can actually use.

✅ Test what’s relevant

Focus on common browsers, devices, and OS versions. Don’t waste weeks covering edge cases like IE8 on Windows XP.

✅ Pick the right level

- Unit tests for isolated checks

- API tests for speed and reliability

- UI tests only for key end-to-end flows

✅ Start now, improve later

Even an “imperfect” suite that saves you 2 hours of daily manual testing gives you back 40 hours a month. That’s time you can reinvest in improving your framework and skills.

⚖️ Test automation is not about elegance or perfection — it’s about value. Start simple, adapt to your team, and iterate. Progress always beats paralysis.

Test Management Without Bureaucracy

 🧭 Test Management: Transparency Without Bureaucracy

The goal of test management isn’t paperwork — it’s transparency.

A good process should make the QA effort visible, showcase product quality at any moment, and help the team share knowledge efficiently.

But when it turns into bureaucracy, it fails its purpose.

🎯 The Real Value of Test Management

Done right, test management helps the team:

• See where quality stands — instantly.

• Understand testing progress and risk.

• Reuse knowledge and learn from the past.

It’s about visibility and collaboration, not about filling out endless fields or updating spreadsheets.

⚙️ Keep It Lean

• Don’t overdo documentation. You don’t need a test case for every ticket. Thousands of unmaintained tests become noise.

• Pick the right tool. Integrate QA into the same system developers use. Avoid silos.

• Automate updates. Connect your pipelines and test suites so reporting happens automatically.

🚀 The Outcome

When test management is lightweight, integrated, and automated, it enables:

• Faster, more confident releases

• Clear insight into product quality

• A shared understanding of risk and coverage

If it feels like bureaucracy, simplify it.

Because the real job of test management isn’t to manage tests — it’s to enable quality at speed.

QA Misconceptions

 🚀 QA is not the boogeyman of software development

Too often, Quality Assurance is misunderstood as the gatekeeper that blocks releases, the “bad guys” who say no until they stamp an approval. But that’s not what QA is about.

✅ QA is not bureaucracy

It’s not about maintaining endless checklists or executing test cases mechanically. It’s about delivering working software to the customer with just the right balance of coverage and traceability.

⚙️ QA is not a silo

Think of QA as one of the gear wheels in the complex system of software delivery. If developers don’t finish their work, the team fails. If QA doesn’t finish testing, the team also fails. Success or failure is shared — and that’s why collaboration matters more than handoffs.

🔍 Testability matters

If a task that should take hours turns into days because the product is hard to test, that’s not just QA’s problem — it’s a recipe for failure for the entire team. Testability must be considered from day one, just like scalability, usability, or security.

⚖️ QA is about risk, not perfection

Quality Assurance is about constantly weighing risks, not chasing an impossible bug-free ideal.

- Is it worth delaying a million-dollar feature because of a minor bug?

- Should we block a release to do performance testing for an app with only 10 beta users?

Sometimes, the smart move is to release and hotfix later. Other times, the risk is too high. QA’s role is to help the team make those decisions consciously and responsibly.

🤝 In the end, QA is not here to block. QA is here to enable delivery with confidence.

Spotless Code Formatter

Clean and formatted code is maintainable code.

Spotless is a popular tool that can format code in any programming language out there (Java, JavaScript, Python, C#, TypeScript, etc.) using any build tools. (Gradle, Maven, etc.)

In this tutorial we will look into integrating it in a Java project built with Gradle. In order to do this, we just need to add and configure Spotless in the build.gradle file in 3 easy steps:

1. Add the Spotless plugin:

plugins {

    id "com.diffplug.spotless" version "6.19.0"

}

2. Configure the formatting jobs:

spotless {

    java {

        googleJavaFormat() // format the code in Google Java format

        importOrder() // order the imports

        removeUnusedImports() // remove the unused imports

        formatAnnotations() // format the annotations

    }

}

3. Trigger Spotless automatically when the project is compiled:

tasks.withType(SourceTask) {

    finalizedBy 'spotlessApply'

}

Worth mentioning is that Spotless also offers additional features like automatic refactoring of the Java code using cleanthat().

The Penny Game

Or why when embracing Agile, individual productivity decreases, but the team's productivity greatly increases.

Automating E-Mail Test Cases When Using Twilio SendGrid

   SendGrid is a customer communication platform for transactional and marketing email, which boasts an impressive client portfolio with big names like Uber, Spotify or Booking.com.

   Let's look into automating a simple test scenario that will check if new users that sign-up for a test application will also receive their welcome e-mails. 

   The presented small test suite only details the e-mail verification part, as the sign-up part can be done in multiple ways - UI action, API call, etc. and is application specific. 

   The test case uses the RestAssured Java library with a previously created API key to call the SendGrid API and check for the e-mail event of interest.

@Test

@Order(0)

void signUp(){

// perform user sign-up

}

@Test

@Order(1)

void verifySendGridEmailEvent() {

    sleep(asyncWaitingTime); //it is an async process so waiting time has to be allowed

    given().log().method().log().uri().header("Authorization", "Bearer " + sendgridApiKey)

            .when().get("https://api.sendgrid.com/v3/messages?limit=1&query=to_email=\"" + emailAddress + "\"")

            .then().statusCode(200)

            .body("messages[0].subject", equalTo("Welcome to Going T-Shaped!"),

                    "messages[0].from_email", equalTo("no-reply@goingtshaped.blogspot.com"),

                    "messages[0].to_email", equalTo(emailAddress), // the e-mail address from the previous sign-up test

                    "messages[0].status", equalTo("delivered")); // e-mail accepted at the receiving server

    System.out.println("Welcome E-mail event correctly retrieved from Sendgrid for user " + emailAddress);

}

   So a quick and simple way of making sure that users are not missing any important e-mail communications due to unforeseen bugs. The above test case can be easily adjusted for any types of e-mails just by switching the verified attributes, e.g. e-mail subject from "Welcome to Going T-Shaped!" to "Forgot Your Password".