From Idea to MVP in a Day — My Talk at Global Azure Bootcamp, Coimbatore

Pandiyan MuruganLeave a comment

Over the weekend, I had the opportunity to speak at the Global Azure Bootcamp held in Coimbatore. My session, titled “From Idea to MVP in a Day: Building SaaS with Azure, GitHub Copilot & AI Tools”, focused on how developers can rapidly prototype and launch SaaS applications using modern cloud services and AI-assisted development tools.

The audience included developers, CTOs, data scientists, and startup founders — all bringing unique perspectives and questions that made the session highly interactive. I also demonstrated how AI tools like GitHub Copilot can speed up development, alongside Azure’s scalable services for building real-world MVPs.

It was inspiring to be part of such a collaborative atmosphere. Big thanks to the organizers and everyone who joined the discussion!

Do We Need to Test UI Changes During Code Review?

Pandiyan MuruganLeave a comment

Code reviews are a crucial part of the development process. They help catch bugs early. They maintain code quality and guarantee consistency. But when it comes to UI changes, one question that comes up every time –

“Should I test every UI change during code review?”

Let’s break it down.

The Real Deal

When reviewing code, your job isn’t to become a full-time QA. You’re not expected to click through every screen or test every browser. But that doesn’t mean you just review the code and approve without even running it.

Here’s a simple rule I follow:

Do a smoke test. Leave deep testing to the person who wrote the code.

Responsibilities – Who Does What?

Code Author (the one raising the PR):

  • Clear information of what has been changed.
  • Links to relevant to related requirements document if any.
  • Tests all use cases — positive, negative, edge cases.
  • Ensures responsiveness and accessibility.
  • Runs the app in different screen sizes (desktop, mobile, etc.).
  • Adds before/after screenshots or screen recording in the PR.
  • Mentions what was tested and how.

Code Reviewer (the one reviews the PR):

  • Pull the branch and run a quick smoke test.
    • Does the UI render?
    • Does it break anything obvious?
    • Are core interactions working? (clicks, inputs, nav)
  • Review the code:
    • Is the styling clean?
    • Any hardcoded values?
    • Are components reusable and scoped?
    • Does it break any layout in high level?

You’re the second line of defense, not the QA team.

When to Dig Deeper?

You don’t always need to click every flow, but in these cases, it’s worth going beyond a smoke test:

  • It’s a high-impact UI change.
  • There’s a risky refactor.
  • The code seems too simple for the change it claims to solve.
  • You’re curious or feel something’s off.

TL;DR

  • Do a smoke test during code review.
  • Let the code author do full testing.
  • Make sure they show what’s changed with screenshots or a demo.
  • Your goal: catch obvious issues, review clean code, ensure UI logic is solid.

Let your review be lightweight, focused, and valuable. Not every change needs a deep dive — just enough to ensure you’re not shipping broken UI.