Forem: George Bakatsias

5 QA automation interview-questions that senior engineers still get wrong

George Bakatsias — Tue, 31 Mar 2026 12:12:04 +0000

George Bakatsias

Mar 27

5 QA Interview Questions That Senior Engineers Still Get Wrong

Comments

3 min read

5 QA Interview Questions That Senior Engineers Still Get Wrong

George Bakatsias — Fri, 27 Mar 2026 00:39:04 +0000

Whether you're preparing for a QA Engineer or SDET interview, some questions trip up even experienced professionals. Here are 5 I've seen catch people off guard:

1. "Design a test automation framework from scratch — what's your architecture?"

Most candidates jump straight to tools (Selenium, Playwright).
Interviewers want to hear about:

Page Object Model vs Screenplay pattern
Test data management strategy
CI/CD integration approach
Reporting & failure analysis

Tip: Start with the problem (what are we testing?), not the tool.

In real interviews, you might be handed a full Playwright project — complete with Page Object Model, Builder pattern, custom fixtures, and API + UI tests — and asked to explain the architectural decisions, not just run it.

2. "You have 2 hours to test this API — walk me through your approach"

The trap: candidates start writing tests immediately.

Better approach:

5 min: Read the API docs/Swagger
10 min: Identify critical paths & edge cases
15 min: Set up collections (Postman/REST client)
90 min: Execute tests (happy path → edge cases → security)
Remaining: Document findings

3. "Look at this form and tell me what's wrong" (Attention to Detail)

You're shown a screenshot of a registration form — something like a "New Registration" page with fields for user ID, password, name, email, address, and country.

Everything looks fine at first glance. But the interviewer expects you to catch things like:

Password confirmation is visible in plain text while the password field is masked
The "First Name" field accepts numbers (John Plainfield 777)
Validation messages are inconsistent — some fields show errors, others silently accept bad input
The address field allows multiple selections when it shouldn't
The copyright year at the bottom says 1811
The "I am not a robot" is a simple checkbox instead of a proper CAPTCHA
Missing asterisks on required fields like Email and Confirm Password

Most candidates spot 2–3 issues. Strong candidates find 10+. This tests whether you actually look at what's in front of you or just tick boxes.

4. "Write a test for this code" (Code Reading Challenge)

You get production source code and must decide which tests give full coverage. This isn't about writing code fast — it's about analytical thinking.

For example, you might see pseudocode like:

IF A > B THEN
    C = A - B
ELSE
    C = A + B
ENDIF
Read D
IF C = D Then
    Print "Error"
ENDIF

And you're asked: "What's the minimal test set to cover all branches?"

Most people say 5 tests, or 3. The answer is 2 — if you pick values that traverse complementary paths (one where both IFs are true, one where both are false), you get full statement and branch coverage.

This question filters out people who test mechanically from those who reason about coverage.

5. "Draft a bug report for this scenario"

Sounds simple, but interviewers evaluate:

Clear title (not "bug in form")
Steps to reproduce (exact, numbered)
Expected vs Actual behavior
Environment details
Severity/Priority classification
Urls/screenshots/logs as evidence

A typical setup: you're given a requirement — say, a Payment module with a "Status" column that should show Red/Yellow/Green based on due dates. The developer implemented it, but in your testing you find the status turns Yellow when the due date is wrong instead of the one specified in the requirements.

Now write the bug report. Most candidates write vague descriptions. What interviewers want to see:

Title: "Payment Status shows Yellow instead of a more precise condition"
Steps: Access the URL, navigate to Payment, filter by specific rules
Expected VS Actual reasons should be clear
Reference: Link to the requirement

The difference between a junior and senior bug report is precision. Developers should be able to reproduce the bug without asking you a single question.

Want to practice all of these?

I put together a hands-on exercise pack with real scenarios,
solution docs, and a Playwright automation project for almost nothing:

👉 QA Interview Content Pack

Includes:

✅ Attention-to-detail exercise
✅ Test case exercise
✅ Code-reading challenge
✅ Bug report writing exercise
✅ A Playwright project (TypeScript, POM, fixtures, architectural decisions readMe)

What's the hardest QA interview question YOU've been asked? Drop it in the comments! 👇

Introduction to Test-Driven Development (TDD) with C# Examples

George Bakatsias — Wed, 29 Nov 2023 15:30:39 +0000

Introduction

In the dynamic realm of software development, the pursuit of impeccable code, the avoidance of pesky bugs is the ultimate quest.
Yet, this journey is full of challenges, particularly as projects grow in complexity, this is where Test-Driven Development (TDD) emerges as your trustworthy companion. In this article, we will dive into TDD, unravel its benefits, explore how to utilize it proficiently with C# code examples, and importantly navigate the complexities of requirements and what precisely should be tested. We will look at the aspects of software that need testing, with practical testing examples on: functionality, data types, boundaries, behavior driven tests, security, performance and integration.

The TDD Ballet

What exactly does TDD entail? Envision TDD as a choreographed dance, with you as the choreographer:

Step 1 Craft a Test: Picture building a calculator. Initially, you formulate a test case that articulates your code's intended behavior. It resembles composing the dance steps.

[Test]
public void TestAddition()
{
    Calculator calculator = new Calculator();
    int result = calculator.Add(2, 3);
    Assert.AreEqual(5, result);
}

Step 2 Craft the Code: Subsequently, you script the code, ensuring it aligns with the aspirations of your test. This phase equates to instructing your dancers in the steps.

public class Calculator
{
    public int Add(int a, int b)
    {
        return a + b;
    }
}

Step 3 Execute the Test: It's time to evaluate whether your code performs the dance flawlessly. Execute the tests and verify that they passed as expected.

$ dotnet test

Step 4 Refine: If the dance seems somewhat lacking in elegance, you can fine-tune it. Polish your code to make it sleeker, swifter, or more efficient. However, remember the golden rule: don't disrupt what's already working.

public class Calculator
{
    public int Add(int a, int b)
    {
        if (a < 0)
        {
            throw new ArgumentException("Input must be non-negative", nameof(a));
        }
        return a + b;
    }
}

Step 5 Repeat: Continuously iterate through these steps for each new segment of the dance you intend to teach.

Why TDD Triumphs

TDD isn't just a dance; it's a dance-off where victory is guaranteed.

Offers

Improved code quality: TDD can unveil any missing specifications of the feature you are developing and help find bugs early in the development cycle.

Painless Maintenance: Your code becomes a breeze to maintain. Farewell to those late-night debugging expeditions.

Swift Troubleshooting: If something falters, your tests pinpoint the trouble spot. No more sifting through code like a detective in a labyrinth.

Regression Resilience: Armed with an array of tests, you can confidently introduce fresh moves without disarraying the old ones.

Living Documentation: Your tests materialize as a cheat sheet for your code. Everyone comprehends what to expect in the dance.

Team Harmony: TDD fosters cohesion among your team, developers and testers.

What Warrants Testing in TDD

Now, let's now address the most basic question: What should be subjected to testing in TDD? Here is a thorough analysis of your software's components that demand close examination, along with real-world examples:

Functionality Testing: This represents the very essence of TDD. You assess whether your code executes its designated functions. For instance, if you consider designing a calculator you should test against the addition function.

// Testing Calculator's Addition
[Test]
public void TestAddition()
{
    Calculator calculator = new Calculator();
    int result = calculator.Add(2, 3);
    Assert.AreEqual(5, result);
}

Data Type Testing: Validating data types for accuracy is essential. Ensure that the variables, inputs, and outputs you use correspond to the appropriate data type and size. This strategy works as a prevention towards data-related errors.

// Verification of Integer Data Type
[Test]
public void TestIntegerDataType()
{
    int number = 42;
    Assert.IsInstanceOfType(number, typeof(int));
}

Edge Cases and Boundaries: Probe the extremities. Investigate the outcomes when you present the smallest or largest conceivable values. For instance, if your calculator can process integers, examine its behavior with the most minuscule and colossal integers.

// Edge Cases and Boundaries, adding one to int.MaxValue should throw an OverflowException
[Test]
public void AddingOneToIntMaxValueThrowsOverflowException()
{
    int maxValue = int.MaxValue;

    Assert.Throws<OverflowException>(() =>
    {
        int result = checked(maxValue + 1);
    });
}

UI Testing writing it the Gherkin way: UI testing assumes paramount importance for assuring the seamless functionality of your application's user interface. Tools such as Gherkin/SpecFlow provide a framework to draft human-readable scenarios that test the behavior of your application.

Scenario: Successful User Login
    Given user navigates to the login page
    When inputs valid credentials
    And clicks the login button
    Then should be directed to the dashboard

Security Testing: Security should never be an afterthought. Investigate vulnerabilities such as SQL injection, cross-site scripting (XSS), and authentication flaws. Specialized security testing frameworks can unravel and mitigate these risks.

// Prevention of SQL Injection
[Test]
public void TestSQLInjectionPrevention()
{
    // Simulate a SQL injection attempt
    string userInput = "'; DROP TABLE Users; --";
    bool isSafe = SecurityHelper.IsInputSafe(userInput);
    Assert.IsTrue(isSafe);
}

Performance and Benchmark Testing: Evaluation of your software's performance is crucial as it grows. How quickly is it able to work? Can it handle an abundance of users or data? Tools for performance testing shed light on these questions.

// Evaluate improvement on bottleneck operation
[Params(1000, 10000)]
    public int Count;

    [Benchmark]
    public void GeneratePrimesMethod1()
    {
        GeneratePrimesMethod(Count);
    }

    [Benchmark]
    public void GeneratePrimesMethod2()
    {
        GeneratePrimesNewMethod(Count);
    }

// Method 1: Simple prime number generation
    public static void GeneratePrimesMethod(int count)
    {
        // Implementation detail
    }

// Method 2: New improved prime number generation method
    public static void GeneratePrimesNewMethod(int count)
    {
        // Implementation detail
    }

Integration Testing: Examine the interactions between the various parts of your software. This is especially important for complex systems with several interrelated components.

// API Integration Test
public void TestApiIntegration()
{
    ApiClient apiClient = new ApiClient();
    ApiResponse response = apiClient.Get("https://someApi.aa/Getdata");
    Assert.AreEqual(200, response.StatusCode);
}

Regression Testing: As you introduce novel features or rectify defects, it's imperative to ascertain that the existing functionality remains unaffected. Execute regression tests to apprehend unintended side effects.

Conclusion

In summary, Test-Driven Development (TDD) is your reliable ally in the realm of coding. It empowers you to create robust, bug-free software by putting tests at the forefront of your development process. With C# as your platform and a deep understanding of what aspects should undergo testing, you have the tools to engineer high-quality software. So, get ready to embark on your path to software excellence through TDD, where meticulous testing leads the way to success!

Useful Keyboard Shortcuts

George Bakatsias — Sun, 05 Mar 2023 23:00:04 +0000

F2: Rename identifier.
Ctrl + W: Context sensitive selection (press multiple times to expand the selection).
Ctrl + Shift + W: Reversing context sensitive selection.
Ctrl + Shift + R: Open refactoring quick menu.
Ctrl + Alt + Enter: Reformat code.
Double Shift: Search everywhere.
Ctrl + Shift + A: Quick menu to create a file.
Alt + Enter: Show Intention Actions.
Ctrl + Space: Basic auto completion.
F12: Go to implementation.

Get full list here

Poor method signatures

George Bakatsias — Sun, 05 Mar 2023 22:59:48 +0000

Poorly designed method signatures are a prevalent code smell that can significantly impede code comprehension, maintenance, and testing. Method signatures serve as the public interface of your code, and it is crucial for them to clearly communicate the method's purpose, expected inputs, and returned outputs. Inadequate method signatures can lead to confusion and errors, particularly in team environments or when working with legacy code. Let's explore different categories of poor method signatures to be aware of:

Overloaded Methods:
Overloading methods with the same name but different parameter types or numbers can introduce confusion and errors. While overloading can be useful for offering multiple ways to perform an operation, excessive overloaded methods can make it challenging to remember the parameter order and types, leading to difficulties in distinguishing between them in code.

// Methods that lead to confusion
public int Add(int a, int b)
public double Add(double a, double b)
public decimal Add(decimal a, decimal b)

Methods With Too Many Parameters:
Methods that require an excessive number of parameters can be challenging to understand and use. Having numerous parameters makes it difficult to remember their order and meaning, and it can also complicate testing the method with all possible parameter combinations. Moreover, methods with an abundance of parameters often indicate poor encapsulation, exposing too much internal state to callers.

// Poor method signature
void Calculate(int x, int y, int z, bool isFast, bool isExact, bool useCache)

// Improved method signature
void Calculate(CalculationParameters parameters)

Methods With Inconsistent Parameter Ordering:
Inconsistent parameter ordering among methods in the same class or module can confuse developers, making it hard to remember the correct order for each method. Additionally, inconsistent parameter ordering can lead to mistakes when using code completion and copying and pasting code.

// Poor parameter ordering
int Subtract(int b, int a)

// Improved parameter ordering
int Subtract(int a, int b)

Methods with Vague Return Types:
Methods with ambiguous return types can be challenging to understand and utilize. When a method returns a generic type like "object" or "dynamic," it becomes challenging to determine the actual return value and the available operations that can be performed on it. Such vague return types can hinder code completion and lead to errors when the returned value is used elsewhere in the code.

// Vague return type
object ParseFileContents(File file)

// Clear return type
ParsedFileContents ParseFileContents(File file)

Methods with Too Many Side Effects:
Methods with excessive side effects are difficult to reason about and test. Modifying internal state or the state of other objects within a method can make it unclear what the method does and how it affects the rest of the code. Additionally, methods with numerous side effects can be challenging to test due to unexpected interactions with other parts of the code.

// Code with to many side effects
void Deposit(double amount)
{
     // Add amount to balance
     // Code to update database and log transaction
}

// Omitted side effects
public void Deposit(double amount)
{
     // Add amount to balance
}

Poor Naming Convention:
Using inconsistent or unclear naming conventions for methods can hinder code readability and maintainability. Employing consistent naming conventions helps make code easier to understand and maintain, saving time and effort in the long run.

// Poor naming convention
void save_to_database()

// Improved naming convention
void SaveToDatabase()

By following good practices for method signatures, you can make your code more readable, maintainable, and testable. Remember to choose clear and descriptive names, limit the number of parameters and side effects, use consistent parameter ordering and return types, and use refactoring tools like Rider to help you improve your code.

Here is a way of how Rider's refactoring tools can help to encapsulate a long parameter list of a method into a class:

Select the method name.
Right-click and select "Refactor" > "Convert" > "Transform Parameters" from the context menu.

Keyboard Shortcuts:

Ctrl + Shift + R > Convert > Transform Parameters

Rider will then prompt you to enter a new name for the class(CalculationParameters), select which parameters to transform and will automatically update all references to that method replacing it with your new class.

Poor Names

George Bakatsias — Sun, 05 Mar 2023 22:59:38 +0000

In software development, code smells such as poor names can greatly hinder code comprehension and maintainability. Inadequate naming of variables, methods, and classes can lead to confusion and errors. It's important to be aware of various categories of poor names:

Mysterious Names: These names fail to convey their intention or purpose. Examples include using vague variable names like "dr1" instead of "dataReader" or employing ambiguous method names like "Button1_Click" instead of "CheckAvailability_Click".

Meaningless Names: These names are overly generic and lack descriptive meaning. Instead of using convoluted method names like "BeginCheckFunctionality_StoreClientSideCheckboxIDsArray", it's better to opt for more descriptive names that clearly indicate the method's purpose.

Names with Encodings: This refers to the use of prefixes, suffixes, or Hungarian notation to indicate data types or scope. With modern IDEs providing advanced features, encoding is no longer necessary. Let the IDE handle the determination of data types, avoiding encodings like Hungarian notation.

Ambiguous Names: These names can be interpreted in multiple ways, leading to confusion. For instance, a method named "MultiSelect" could be unclear about whether it selects multiple items or handles multiple selections. Similarly, a variable named "incidentNameId" raises questions about its nullability or the presence of "Name" in the name itself.

Noisy Names: These names are excessively verbose or redundant. Instead of using long variable names like "theCustomer" or "listOfApprovedCustomers", it is better to use concise names such as "customer" and "approvedCustomers".

To avoid poor names, ensure that your chosen identifiers are meaningful, of appropriate length, convey intention, and are relevant to the problem domain you are working on. Additionally, you can employ refactoring tools like Rider to easily and efficiently rename identifiers without introducing any issues into your codebase. By adhering to these guidelines, your code will be more readable, understandable, and maintainable for both yourself and other developers.

Let's consider a C# example to illustrate how naming conventions can significantly impact code clarity:

// Poorly named variables and methods
int o; // overdue days
string c; // customer
double[] p; // prices
void fc() // function to calculate discounts

// Well-named variables and methods
int overdueDays;
string customerName;
double[] itemPrices;
void CalculateDiscounts()

In the above example, the poorly named variables and methods employ single-letter names or abbreviations that provide little insight into their purpose. Conversely, the well-named variables and methods use descriptive names that clearly indicate their intent.

By following proper naming conventions, you can greatly enhance code readability and comprehension, saving time and effort for both you and fellow developers. Remember to choose meaningful and relevant names that align with the problem domain. And don't forget to utilize refactoring tools like Rider, which facilitate quick and hassle-free identifier renaming.

Here is a way of how Rider's refactoring tools can help:

Select with your mouse the variable or method
Do a mouse right click and go to "Refactor > Rename" (or go from the "Refactor" menu in the ribbon).

Keyboard Shortcuts:

F2
Or Ctrl + Shift + R > Rename

Rider will then prompt you to enter a new name for the identifier, and will automatically update all references to that identifier throughout your codebase.

Cleaner Code & Refactoring Tools (C# & Rider)

George Bakatsias — Sun, 05 Mar 2023 22:59:24 +0000

series: How refactoring tools can help you write cleaner code

Refactoring refers to the process of enhancing the internal structure of code while preserving its external behavior. It plays a crucial role in software development as it enables developers to modify code without introducing bugs or disrupting existing functionality.

The practice of refactoring involves making small, incremental modifications to code, aiming to enhance its readability, maintainability, and scalability. Typically, refactoring occurs during the maintenance and update phases of code development.

Refactoring tools are software applications that automate the process of refactoring. These tools assist developers in identifying areas of code that can be improved and offer suggestions for implementing those improvements.

Integrating with Integrated Development Environments (IDEs) like Eclipse, Visual Studio, or IntelliJ IDEA, refactoring tools become a part of the development workflow. They can also function as standalone applications within a development setup.

Refactoring tools contribute to cleaner code in multiple ways. Firstly, they detect areas of code that could benefit from improvements by identifying duplicated code, unused variables, and other code smells. This feedback assists developers in prioritizing the refactoring process and addressing areas that require the most attention.

Secondly, refactoring tools provide recommendations for improving code quality. They propose ways to simplify code, extract methods, and enhance naming conventions, aiding developers in writing cleaner and more maintainable code.

Thirdly, refactoring tools automate the refactoring process by executing tasks like variable renaming, method extraction, and code relocation across classes or files. This automation saves developers time and reduces the risk of introducing new bugs.

Lastly, refactoring tools help enforce coding standards and best practices, ensuring code quality. They can verify code compliance with established guidelines and highlight areas that deviate from these standards. This promotes consistency and maintainability in the codebase.

To sum up, refactoring tools are indispensable for developers seeking to produce clean, maintainable code. They identify areas for improvement, offer suggestions, automate refactoring tasks, and uphold code quality. Utilizing these tools enables developers to enhance their code's quality, while minimizing the risk of introducing bugs.

In the upcoming series, we will explore practical examples of refactoring C# code using the Rider IDE (or Resharper). This exploration will emphasize the benefits and advantages of employing refactoring tools.