My Portfolio as My First QA Playground

One of the first mini projects I worked on as a QA was actually something I already had: my own personal portfolio.

Since I was already building and maintaining my website, I thought, why not use it as a testing playground?

It gave me a real application that I could experiment on without worrying about breaking an actual production product. At the same time, it had enough features for me to explore different areas of QA—from functional testing and automation to accessibility and even AI-assisted testing.

I wanted this project to be more than just checking whether my website worked. I wanted to use it as an opportunity to learn how I could approach testing as a QA, what tools I could use to make the process more efficient, and where automation could actually help.

So, I decided to test my own portfolio.

Why My Own Portfolio?

As a beginner exploring QA, one of the challenges I had was figuring out what I could actually test.

I didn't have a large application with hundreds of features to work with, so I started with something I already understood.

My portfolio had:

That made it a pretty good little testing playground.

More importantly, because I was the one building it, I could experiment with different testing approaches and immediately see how they applied to a real application.

It also gave me a chance to experience something I think is important in QA:

You don't always need a huge application to practice testing. Sometimes, you just need something that you can question, break, and improve.

What I Wanted to Explore

Since this was one of my first QA mini projects, I didn't want to make it overly complicated.

Instead, I wanted to explore a few things that I was curious about:

That became the direction of the project.

Step 1: Exploring the Website as a Tester

The first thing I did was simply go through my portfolio.

At this point, I wasn't thinking about automation yet.

I wanted to experience the website as a visitor would.

I went through the different pages and interacted with the different components.

I looked at things like:

This was a simple start, but it helped me understand what I actually needed to test.

Step 2: Getting Started With Playwright

After exploring the website manually, I wanted to see how much of the repetitive testing I could automate.

That's where Playwright came in.

Since I was still learning, I treated this as an opportunity to explore browser automation rather than trying to immediately build a huge test framework.

I started with simple scenarios.

For example:

Once I got the basic tests working, I started expanding them.

Step 3: Using AI to Help Me Learn and Work Faster

One of the things that made this project particularly interesting was that I didn't do everything from scratch.

I also experimented with using AI as a QA assistant.

Since I was still learning Playwright, AI helped me understand how certain tests could be written and gave me ideas for scenarios that I could try.

I used AI to help with things like:

For me, the goal wasn't to simply tell AI:

"Write my tests for me."

Instead, I wanted to understand what it was generating and use it as a way to learn faster and explore more possibilities.

Sometimes the suggestions worked immediately.

Sometimes they didn't.

And honestly, those failures were also useful because they forced me to understand what the test was actually doing instead of blindly copying the generated code.

That became one of the interesting parts of this project.

Step 4: Thinking Beyond the Happy Path

Once I had some basic automated tests, I started thinking:

"Okay, what else can go wrong?"

This was where I started getting more into the QA mindset.

Instead of only testing:

"Can I navigate to the other sections?"

I started asking:

These questions helped me realize that testing isn't just about verifying that the expected scenario works.

It's also about intentionally looking for situations where things might fail.

Step 5: Exploring Responsive Testing

Since my portfolio is meant to be viewed on different devices, I also wanted to explore responsive testing.

I used Playwright to test different viewport sizes and looked at how the website behaved.

I checked things such as:

This was particularly useful because I encountered situations where something looked perfectly fine on my desktop but didn't look quite right on a smaller screen.

It reminded me that:

"It works on my screen" isn't really a sufficient test result.

Step 6: Exploring Accessibility With axe-core

Another area I wanted to explore was accessibility.

I've been becoming more interested in accessibility as part of QA, so I wanted to see how I could incorporate it into my automated testing.

That's where axe-core came in.

I integrated accessibility checks into my testing and used them to identify potential accessibility issues.

This allowed me to explore automated checks for things such as:

It was interesting to see how quickly an automated tool could identify things that I might not immediately notice during a normal visual check.

Step 7: Learning the Limits of Automation

One of the biggest things I learned from using axe-core was that passing an automated accessibility test doesn't mean a website is automatically accessible.

There are still things that require human testing.

For example:

This helped me understand that automation is a tool—not the entire testing strategy.

The same idea applied to my Playwright tests.

A test passing doesn't automatically mean the application is good.

It only tells me that a specific scenario behaved as expected.

Step 8: Using the Portfolio for Regression Testing

As I continued working on my portfolio, I realized another benefit of having automated tests.

The website was constantly changing.

I would add a new component, modify an existing design, change a journal card, update navigation, or add another feature.

And every change introduced the possibility of breaking something that was already working.

This gave me a chance to explore regression testing.

After making changes, I could run my Playwright tests again and quickly check whether previously tested functionality was still behaving correctly.

Instead of manually repeating the same checks every time, I had automated tests that could act as a safety net.

Step 9: Testing My Own Work Is Surprisingly Different

One thing I didn't expect from this project was how difficult it could be to test something I built myself.

Because I knew how the website worked, I naturally followed the paths I expected users to follow.

I already knew:

"This button should do this."

"This page should look like this."

"This link goes here."

That familiarity can make it easy to miss things.

So I started deliberately trying to think like someone who had never seen the website before.

That meant clicking things differently, using different screen sizes, using only the keyboard, and testing scenarios I wouldn't normally perform.

What This Mini Project Gave Me

What started as:

"I have a portfolio. Maybe I can test it."

ended up becoming a small QA playground where I could explore several different areas of testing.

I got to experiment with:

Manual Testing

Understanding the application and exploring different user flows.

Playwright

Automating browser interactions and regression scenarios.

AI-Assisted Testing

Using AI to help generate ideas, write tests, troubleshoot issues, and make the process more efficient.

axe-core

Exploring automated accessibility testing.

Responsive Testing

Checking how the application behaves across different screen sizes.

Accessibility Testing

Combining automated checks with manual validation.

Regression Testing

Making sure new changes didn't break existing functionality.

And perhaps most importantly, I got to practice thinking like a QA.

What I Learned

Since this was one of my first QA mini projects, I wasn't expecting to build a perfect automation framework or discover every possible bug.

The bigger goal was to explore.

I wanted to understand what testing tools could do, where automation could help me, and where I still needed to rely on my own judgment.

Using my own portfolio made that process much easier because I had complete control over the application. I could introduce changes, test them, break things, fix them, and test them again.

I also learned that AI can be a really useful assistant in QA—not because it replaces the tester, but because it can help make certain parts of the process faster and help me think of scenarios I might not have considered.

At the end of the project, my portfolio became more than just a website showcasing my work.

It became my first little QA playground.

And honestly, I think that's what made it a good place to start.