Hasan AKDOGAN

ABOUT ME

Automation & QA Experience

5+ years in software testing and QA
Experience in test automation & manual testing
Web, API, and database testing expertise
End-to-end test ownership
Experience in iGaming, CRM & enterprise platforms

Test Automation Frameworks

Playwright with TypeScript
Selenium WebDriver with Java
Cucumber BDD framework implementation
Cypress for modern UI automation
JUnit & TestNG for test orchestration

Technical Skills

Java, TypeScript, JavaScript, Python
REST API testing and validation
SQL and database testing
JDBC-based DB automation
Debugging and root cause analysis

Tools & CI/CD

Jenkins for CI/CD pipeline integration
Git & GitHub for version control
Postman & Rest Assured for API testing
Jira & X-Ray for test management
Selenium Grid for parallel execution

Testing Methodologies

Manual & Automated Testing
Smoke, Regression, Sanity, UAT testing
SDLC & STLC knowledge
Agile / Scrum methodology
BDD and data-driven testing approaches

Education & Certification

ISTQB Foundation Level Certified
Bachelor's Degree in Industrial Engineering
Strong analytical and problem-solving skills
Clear communication with all team mates
Continuous learning mindset

TEST AUTOMATION PLAYWRIGHT DEMO

Explore how a QA Automation Engineer turns user stories and acceptance criteria into automated Playwright tests, live browser execution, reports, bug tracking, and CI/CD pipelines.

Test Case Design (requirements · gherkin example)

User Story	As a user, I should log in successfully and leave the session safely.
Acceptance Criteria	User can log in with valid credentials, access the Products page, log out successfully, and return to the login form.
Test Case ID	TC-LOGIN-001
Test Case Description	Verify successful login with valid credentials and complete Sauce Demo login/logout flow.
Pre-Condition	Application is accessible and demo environment is available.
Test Steps and Description	Navigate to the application URL. Log in with valid credentials. Verify logged in. Open side menu and Click Logout. Verify login form is displayed again.
Test Data	URL: `https://www.saucedemo.com` User: `standard_user` Pass: `secret_sauce`
Expected Result	User logs in successfully, logs out successfully, and the login form is displayed again.
Actual Result	Actual behavior matches expected result. Test completed successfully.
Comments / evidence	Demo execution output confirms successful flow.
Pass / Fail	PASS

Feature: User Authentication
  Scenario: Successful login and logout
    Given the login page is displayed
    When I log in with valid credentials
    Then the inventory page should be visible
    When I click Logout
    Then the login page should be displayed again

Test Script (read-only)

import { test, expect } from '@playwright/test';

const BASE = 'https://www.saucedemo.com/' as const;
const CREDS = { user: 'standard_user', pass: 'secret_sauce' } as const;
const sel = {
  user: '#user-name',
  pass: '#password',
  login: '#login-button',
  inv: '.inventory_list',
  menu: '#react-burger-menu-btn',
  out: '#logout_sidebar_link',
} as const;

test.describe('SauceDemo — auth', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto(BASE);
    await expect(page.locator(sel.login)).toBeVisible();
  });

  test('login → inventory → logout', async ({ page }) => {
    await page.locator(sel.user).fill(CREDS.user);
    await page.locator(sel.pass).fill(CREDS.pass);
    await page.locator(sel.login).click();

    await expect(page).toHaveURL(/inventory/);
    await expect(page.locator(sel.inv)).toBeVisible();

    await page.locator(sel.menu).click();
    await page.locator(sel.out).click();
    await expect(page.locator(sel.login)).toBeVisible();
  });
});

Test output (simulated console)

Start the demo from here: click Run test — code, Gherkin, step list, and headed preview move together.

npx playwright test — chromium

Execution summary

STATUS —

Browser —

Framework —

Execution time —

Headed browser (simulated UI + test flow steps)

Chromium (headed · demo)

about:blank

Headed preview

Run the test to watch the UI follow each Playwright step.

Loading page…

Swag Labs

Products (inventory)

Start — engine & open URL
Log in with demo user
Assert products (inventory)
Open menu & log out
Back to login & pass

Run dashboard (Playwright HTML reporter · artifacts like a real CI run)

HTML Report —

— test cases

—

SUITES 0 item total

—

Show all

Environment

There are no environment variables (simulation)

Test cases 0 items total

Show all

Total tests

—

Suite scope

Passed

—

Assertions OK

Failed

—

Flaky / errors

Duration

—

Wall time

Browser

—

Project

Recent run

Test name	Status	Duration
`—`	—	—

Artifacts

Screenshot

On a real run, Playwright saves PNGs per step or on failure. In this demo, assert thumbnails (login, inventory, logout) load only after the run finishes; until then, the slots stay empty.

Assert: SauceDemo inventory (demo screenshot)

Assert: back to sign-in (demo screenshot)

Video

On a real run, set video: 'on' or 'retain-on-failure' in playwright.config — output often lands in test-results/. In this demo, a screen recording (video evidence) is attached only after the run completes.

Demo file: videos/pw-run-demo-evidence.mp4 — optimized screen capture of the login → inventory → logout run.

Trace Viewer

Traces bundle DOM, network, and console. Open with npx playwright show-trace trace.zip — ideal for debugging flaky steps in a headed timeline UI.

HTML Report

Default reporter writes playwright-report/index.html. Use npx playwright show-report locally; publish the folder as a CI artifact. Allure users swap in allure-playwright + allure serve for a comparable dashboard.

This panel is a front-end simulation. In production, wire the same layout to your reporter output or Allure JSON — the workflow matches how QA engineers triage runs after npx playwright test.

Bug Report Lab — yükleniyor

Bu kutu, arayüz açılır açılmaz kaybolur. Görünmüyorsa sayfayı file:// yerine bir HTTP sunucusu ile açın; proje kökünde npx serve . veya VS Code Live Server kullanın. Aynı paneli Test Automation bölümünde Run dashboard’un yanında (aşağı kaydırarak) bulursunuz.

If this box never disappears, the bundle did not run — check that bug-report-lab/dist/bug-lab.iife.js exists (run npm run build inside bug-report-lab).

CI Pipeline Lab — yükleniyor

Bu kutu, arayüz açılır açılmaz kaybolur. Görünmüyorsa sayfayı file:// yerine bir HTTP sunucusu ile açın; proje kökünde npx serve . veya VS Code Live Server kullanın. Aynı bölüme Test Automation bölümünün hemen altında, sayfada aşağı kaydırarak ulaşabilirsiniz.

If this box never disappears, the bundle did not run — check that bug-report-lab/dist/ci-pipeline-lab.iife.js exists (run npm run build inside bug-report-lab).

TOOLS

Click any tool card to explore detailed information, installation guides, real-world usage examples, interactive demos, and official resources.

QA ENGINEER CAREER

Explore selected resources about QA careers, interview preparation, real work life, and software testing growth.

View More QA Content

SUBJECTS

SDLC

SDLC has six steps. These are requirements gathering, design, development, testing, release, and maintenance.

1. REQUIREMENT GATHERING
Product Owner collects the requirements from the client. Then business team writes the SRS - Software Requirement Specification document according to these requirements and uses SMART (Specific, Measurable, Achievable, Relevant, and Testable) criteria.

2. DESIGN
Designers, design a prototype of the software according to the SRS. Then the SDS Software Design Specification document is written in this step.

3. DEVELOPMENT
Developers build/develop the software according to SRS/SDS documents and feedback. There are 4 Software Environments a.Development (Developers)
b.QA/Test (QA Engineer - SDET/Perf. Testers)
c.Staging (Client)
d.Production (End-Users)

4. TEST
Testers, test the app in the QA Env. according to the expected and actual results. If there is a difference between them, they write a bug report.
a. Functional testers test the functionalities of the app on 3 layers (UI, DB, API)
b. Performance testers test the non-functionalities of the app

5. RELEASE/DEPLOY
Developers/Testers/BT release the application then End-Users use it in the production environment.

6. MAINTENANCE
End-Users may find a bug in the application or receive feedback then developers fix and testers test it. It is known as Hotfix.

SDLC starts again with the new requirements. That is why we call it the life cycle.

ENCAPSULATION

Encapsulation is one of the Object Oriented Programming (OOP) principles. The other Object Oriented Programming principles are:
* Inheritance * Abstraction * Polymorphism

* Encapsulation is hiding the data by giving private access modifiers.
* If data is defined as "private", it can only be accessed within the same class.
* The data cannot be accessed from other classes.
* If we need to access these variables, we have to use public "getter" and "setter" methods.
* Both Getter and Setter are public instance methods used to protect our data and make our code more secure.

* Getter is used for reading the private data (instance variable only)
- The return type must match with private instance variable's data type
- Does not pass any parameter
- Returns the private instance variable's value

*Setter is used for writing (modifying) the private data (instance variable only)
- The return type is void
- Passes a parameter, and the parameter will be assigned to the private instance variable
- The data type of the parameter must match the data type of the private instance variable

* Encapsulation gives us control over the data.
* We can provide some conditions for the data.
* For example, we can implement the employee's age between eighteen and sixty-five via Setter.

LOCATORS

Selenium provides 8 different web locators for locating WebElements on the page. These are:
* id * name
* className * tagName
* linkText * partialLinkText
* CSSselector * XPath

1- id:
* ID locators are unique so it is the fastest and safest locators.
* Because of that, it is a common way to locate elements.
* But it can be dynamic, after refreshing the page, we can understand whether it is dynamic or not.

2- name / 3- className / 4- tagName :
* These 3 locators are not unique.
* If there is more than one element with the same locator, the first element on the page is selected.
* Our locator can fail if developers add some locators at a later stage.

5- linkText / 6- partialLinkText :
* If our targeted element is a Link then we can use the linkText or partialLinkText locator to locate the web element.
* linkText works similarly to the equals method in java.
* partialLinkText works similarly contains method in java.

7- cssSelector / 8- XPath :
* We can use different attributes and tag names with CSS and XPath to identify any given element.
* CSS selector and XPath can identify dynamic elements on a web page.

ABSTRACTION

Abstraction is one of the Object Oriented Programming (OOP) principles. The other principles are: * Encapsulation * Inheritance * Polymorphism

What is Abstraction?
* Abstraction is a process of hiding the implementation details and showing only functionality to the user.
* For example, sending messages. Users only type and send the message. They have no idea about the message-sending process.
* Abstraction helps with "reusability" and "less duplication", Abstract Method
* Abstract Method uses an abstract keyword inside the abstract classes or interfaces without implementation.
* The first concrete subclass must implement all abstract methods

An Abstract Method ;
* Cannot be static and final
* Cannot have private access modifier
* Does not have a body (implementation), they just have a method signature.
* Can only be created in an abstract class or in an interface

Abstract class and interface;
Both are used to achieve abstraction and they can't be instantiated and final.
1) Abstract class can have abstract and non-abstract methods.
Interface can have abstract, default, and static methods also.
2) Abstract class can have final, non-final, static and non-static variables.
Interface has only static and final variables.
3) Abstract class can have a constructor, Interface cannot
4) Abstract class can have other access modifiers than public
Interface is public by default.

HOW TO TEST

When testing a vending machine, I first check all requirements and acceptance criteria as a tester.
Users can purchase the product with valid payment. For example cash, debit/credit card, apple pay, etc.

* Payment by cash
Users should be able to insert cash into the machine and select the product by pressing the vending machine's corresponding button on the keypad.
When overpayment, the vending machine must share the product and return the change.
Because of that, there should be enough cash in the vending machine.
If there is no product left or a non-existent product is selected, it should not be paid.

* Payment by debit/credit card and Apple pay
Users can purchase the product by following the cash payment steps with a valid debit/credit card.
For this, there must be necessary internet or mobile network connections.

* The product should not be shared in the following cases;
When paying less or trying to pay with invalid money.
When payment is made with an invalid, expired, insufficient, or different currency card.
When two or more buttons are pressed together.
When an invalid or out-of-stock product is selected.
when there is no electric power.

* Also a vending machine;
The product must be visible and in its correct place.
The vending machine should be able to keep the products fresh and at the required temperature.
Messages on the screen should be understandable.
The vending machine must be locked and secure.
Card/debit card encryption security must be provided.
It should be large enough to fit in the area to be used.

PAGE OBJECT MODEL

Page Object Model, is a design pattern that is commonly used in Selenium Automation Test. It makes our codes more readable, maintainable, and reusable.

In Page Object Model, there must be a Page Class for each web page in the application.

Each class file will contain only corresponding web page elements.

We can also store related re-usable utility methods in that "page" class.

In order to support Page Object Model, we use Page Factory Instead of using the .findElement method we will use the @FindBy annotation.

We also use the configuration.properties file to centralize and avoid hard coding.

To read this file, we use the "Configuration Reader" class.

We use Driver class to be able to instantiate our object without many codes.

We can also use BrowserUtils class to re-use some of the general utility methods.

SYNCHRONIZATION

When a web page is loaded in the browser, the web elements that we want to interact with can load at different time intervals.
In that time, we need synchronization because we need to make sure our driver and our browser are on the same page at all times.

Thread.Sleep method comes from Java and is not a good practice to use because it will wait for regardless of the given time in milliseconds.

ImplicitlyWait comes from Selenium library. It is ONLY triggered when findElement (@FindBy) method can NOT find a web element with given locator. It will wait until the web element is found or timer runs out. We use it once, and it will be applied to the rest of our driver session life. When the given time expires NoSuchElementException is thrown by findElement method.

ExplicitWait comes from Selenium library. It can wait for expected conditions to happen on the page.

It is mainly used when we want to click or act on an object when it is visible. We can use a lot of Expected Conditions can be used in Explicit Wait. Some of them are:
elementToBeClickable()
elementToBeSelected()
visibilityOf()

FluentWait is quite similar to explicit Wait and it defines how frequently WebDriver will check if the condition appears before throwing the ElementNotVisibleException

POLYMORPHISM

Polymorphism is one of the Object Oriented Programming principles. Polymorphism means many forms.
Occurs when the reference type is a parent class or interface and the object type is a child.

Reference type decides what is accessible and Object type decides which implementation of the method to be executed.

For example, in our framework, we use polymorphisms like
WebDriver driver = new ChromeDriver(); driver.get("https://www.google.com");

then we can go to our web page.

We use the instanceof keyword to check if the object is a certain class.
Dynamic Polymorphism is Method overriding.
It means One method with multiple implementations.
Static Polymorphism is Method overloading.

It means Multiple methods with the same name and each method has one implementation ONLY
There are two types of reference type castings: upcasting and downcasting

Upcasting
Casting the smaller reference type to a larger reference type
It is done implicitly

Downcasting
Casting the larger reference type to a smaller reference type
It is done explicitly
Downcasting Allows us to access the features of the objects type that are not in the reference type

AGILE

In our project, I have been working with the Agile Scrum methodology.
Our sprint cycle is 2 weeks and starts every other week on Monday.
In our team, we have a Product Owner, Scrum Master, 5 Developers, and 3 Testers.
We have 5 meetings in this sprint time period.

On the first day of the sprint, we have Grooming Meeting and Sprint Planning Meeting.

1. Grooming Meeting
In this meeting, PO explains the User Stories and Acceptance Criteria that are listed in the Product Backlog.
We give estimation points to User Stories based on Fibonacci.

2. Sprint Planning
In this meeting, PO identifies the sprint goal and prioritized the User Stories (by the Product Owner)
After that, we select the user stories from the Product Backlog to the Sprint Backlog based on our team capacity of the sprint then assign each User Story to each Developer and Testers to work on during the Sprint.

3. Daily Stand up (Scrum)
The purpose of the Daily Scrum is to review progress toward the Sprint Goal and adjust the necessary planning.
We have a Daily Stand up meeting every morning and we give information about
What did we do yesterday? What will we do today? Do we have any blockers?
in 15 minutes.
Burndown chart helps us to predict when all of the work will be completed.

4. Sprint Review (Demo Meeting)
On the last day of the sprint, we have the Demo meeting.
In this meeting completed work is presented to the client.
PO accepts or rejects User Stories based on the DOD criteria.
The rejected User Stories will back to the Product Backlog for the next sprint.

5. Sprint Retrospective
We are holding this meeting to improve quality and effectiveness with Scrum Master, developers, and testers.
As a Scrum Team, we discussed what went well during the Sprint, what problems we faced, and how those problems were solved or not by answering 3 questions.
What went well? What went wrong? How we can improve?

GIT COMMANDS

There are many different ways to use Git. Git supports many command-line tools and graphical user interfaces. The Git command line is the only place where you can run all the Git commands.

The following set of commands will help you understand how to use Git via the command line.

1. git clone
We use it to copy and download the remote repository to a local.

2. git status
The Git status command gives us all the necessary information about the current branch.

3. git add
When we create, modify or delete a file, these changes will happen in our local and won't be included in the next commit.
We need to use the git add command to include the changes of a file in our next commit.

4. git commit
Git commit is like setting a checkpoint in the development process which you can go back to later if needed.
We also need to write a commit message to explain what we have changed in the source code. Git commit saves your changes only locally and each commit has a unique ID.

5. git branch
By using branches, several users are able to work in parallel on the same project. This command will create a branch locally. To push the new branch into the remote repository. 6. git checkout
We use it for switching from one branch to another.

7. git merge
git merge combines the changes from one branch to another branch.
When you've completed the task in our branch and everything works fine, the final step is merging the branch with the master branch.

8. git pull
To get the latest version of a repository run git pull. This pulls the changes from the remote repository to the local computer.

9. git push
After committing our changes, the next thing is sending our changes to the remote server. Git push uploads your commits to the remote repository.

10. Resolving a merge conflict on GitHub
Open the repository on GitHub and click Pull requests.
click the pull request and Resolve conflicts.
Delete the conflict markers
<<<<<<<,=======,>>>>>>>
and make the changes.
After resolving all the conflicts, click Mark as resolved.
Then Click Commit merge.

CHEAT SHEET

JAVA

SELENIUM

AGILE SCRUM

ISTQB

FOLLOW ME

Quality|Control|Verification|Validation|Analysis|Assurance|Reliability|Stability

ABOUT ME

Automation & QA Experience

Test Automation Frameworks

Technical Skills

Tools & CI/CD

Testing Methodologies

Education & Certification

TEST AUTOMATION PLAYWRIGHT DEMO

Test Case Design (requirements · gherkin example)

Test Script (read-only)

Test output (simulated console)

Headed browser (simulated UI + test flow steps)

Products (inventory)

Run dashboard (Playwright HTML reporter · artifacts like a real CI run)

SUITES 0 item total

Environment

Test cases 0 items total

Recent run

Artifacts

Bug Report Lab — yükleniyor

CI Pipeline Lab — yükleniyor

TOOLS

QA ENGINEER CAREER

SUBJECTS

CHEAT SHEET

CONTACT ME

EXPLORE & CONNECT

FOLLOW ME

Hasan Akdogan

HASAN AKDOGAN

FOLLOW ME

Quality|Control|Verification|Validation|Analysis|Assurance|Reliability|Stability

ABOUT ME

Automation & QA Experience

Test Automation Frameworks

Technical Skills

Tools & CI/CD

Testing Methodologies

Education & Certification

TEST AUTOMATION PLAYWRIGHT DEMO

1 Test Case Design (requirements · gherkin example)

2 Test Script (read-only)

3 Test output (simulated console)

4 Headed browser (simulated UI + test flow steps)

Swag Labs

Products (inventory)

5 Run dashboard (Playwright HTML reporter · artifacts like a real CI run)

SUITES 0 item total

Environment

Test cases 0 items total

Recent run

Artifacts

Bug Report Lab — yükleniyor

CI Pipeline Lab — yükleniyor

TOOLS

QA ENGINEER CAREER

SUBJECTS

CHEAT SHEET

CONTACT ME

EXPLORE & CONNECT

Hasan Akdogan

Test Case Design (requirements · gherkin example)

Test Script (read-only)

Test output (simulated console)

Headed browser (simulated UI + test flow steps)

Run dashboard (Playwright HTML reporter · artifacts like a real CI run)