DEV Community: Julie Laursen

How to Build a Test Automation Portfolio That Will Get You Hired

Julie Laursen — Sun, 04 May 2025 23:13:10 +0000

Portfolios - we think of them as important for designers, yet we rarely think of them as testers or developers. Most of us treat GitHub like a storage bin, not a showcase. So, we rarely curate our GitHub repos in the same way we would strategize a portfolio. In this way, we leave a valuable chance for marketing ourselves off the table.

Before you interview or try to market yourself for consulting, you should consider cleaning up your Github and possibly creating a website. Instead of telling people what you can do, show them. Consider how many times you've had a take home assignment that was to write unit or integration tests for a company's public website? Imagine if you had an example of doing this pinned to the top of your Github repo along with a personal website that linked to the project and described your process for how you chose what tests to write, how you prioritized your work, and how you executed. In this way, you can get ahead of employers by giving them a window into how your thought process before the interview.

By the end of this guide, you’ll know how to:

Set up a Github repository for your portfolio
Design and style your portfolio with HTML & CSS
Optimize your site for search engines
Deploy it live with Github Pages
Use Github stats directly on your website

Step 1. Clean Up Your GitHub: Pin and Polish

If you have existing projects, now might be a good time to do some spring cleaning. Find the six repositories you're most proud of and pin these to the top of your Github. Make sure these repositories are public so employers won't get a broken link when they click on them.

If you're unsure of which repositories to select, consider:

Relevance: Highlight projects that align with your career goals and expertise. For example, if you are applying for SDET jobs which use Cypress or Playwright, pin repositories that use these tools. However, consider throwing in a couple of repos that showcase your knowledge of front-end skills, back-end skills or data engineering for diversity.
Popularity: If a repository has forks, stars, or issues, it shows engagement and community interest. Employers don't want to know that you can code alongside a tutorial as much as they want to know if your work has had an impact.
Collaboration: Showcasing team projects or open-source contributions adds value to your profile. It also shows that you can work in a team to deliver a product.

Steps to Pin a Repository:

Go to your GitHub profile.
Click on the "Customize your pins" button.
Select up to 6 repositories to showcase.
Click Save to update your profile.

Next, clean up the READMEs associated to your pinned repos so that they demonstrate good technical writing skills. Use markdown to have clear headings and list items or even use emojis. Make sure you have clear directions for installation and set up of these repos. Add a folder structure, call out scripts, and include licensing information. Well-documented repos will show that you're a detail-oriented and thorough developer.

I updated my Github profile alongside a group of other women called Frontend Queens. For more detailed information on updating your Github ReadMe, check out How to Craft a Perfect ReadMe File For Your Portfolio

Step 2. Add Visual Appeal with Images and Stats

First, update your profile with all the necessary information in the overview tab. Add a profile image, location, email contact and LinkedIn contact. Then update your main README. This will control the 'landing page' that users see when they go to your Github. You can include an image that will act as a hero image on your github, and if you don't have your own design, you can consider using a profile header generator such as Levi Arista's Profile Header Generator. I used their generator for my header, which is in tribute to Ada Lovelace:

Consider adding badges, visualizations and statistics. I found Rahul Jain's Read Me Generator helpful. I chose to show my top languages, github stats, and streak stats. Just having these stats tied to my profile added a component of gamification that made me want to continue my current 'streak' and commit to coding at least a little bit every day outside of work.

For inspiration on crafting your README, see these examples: Github README Templates

Step 3. Build Your Github Portfolio

Now that you have your readme down, consider creating a static website for free using Gitub. Previously, I was paying $10 a month to host portfolio websites using AWS, but I could never justify keeping them up for years at a time, especially when I wasn't looking for new work. With my Github Portfolio, I don't have that worry, and I feel better contributing. The downside is that you won't have backend support, database support, or server-side functionality. However, for a portfolio, all you need is HTML, CSS, and JavaScript.

Steps to Create a Github Portfolio:

Go to your GitHub profile.
Click the "+" button, and select "New Repository
Name it .github.io
Set it to public
Add a README file with the same level of documentation as your favorite pinned repositories

Now, design your portfolio. For a inspiration, check out this list of Developer Portfolios

For my portfolio, I needed to showcase my skills as an SDET. So I intentionally included email links, hidden tabs, search functionality, and anything else I could think of that would provide a range of testing beyond asserting that copy was on a page. Theoretically, I could also create a to-do app on my page and test that to showcase more complicated tests. One benefit to having my own portfolio to run tests against is the control I have over the Application Under Test. My website won't change and break all my tests unless I change it.

I also included my developer stats directly on my Github Portfolio website. This way users who are not tech savvy can go directly to my website from LinkedIn and still get an idea about my contribution status and coding knowledge.

I will continue iterating on my profile as well as documenting my project management process. For a good example of a project management roadmap, see Github Projects.

Your portfolio should grow as your skills evolve, so keep it fresh by scheduling periodic updates and adding them to your roadmap.

Thanks to Frontend Queens who gave me the idea for my portfolio. Visit their detailed summary of portfolio creation at Master Your Frontend Portfolio. I hope I've provided you everything you need to get started today. If you found this helpful, share it or drop your GitHub below—I'd love to see your work!

A walkthrough of "Bootstrapping Microservices with Docker, Kubernetes and Terraform"

Julie Laursen — Tue, 01 Feb 2022 04:25:07 +0000

"Bootstrapping Microservices with Docker, Kubernetes and Terraform: A project-based guide" is a great way to learn all of these tools, if you can get it working. In this article, I attempt to document the workarounds and tricks that were helpful to me.

Chapter 1-3: Publishing your first microservice and learning Docker. Here the book does a great job in articulating the differences between concepts like a docker image, docker container, Dockerfile, docker compose and the different commands associated with each. You've probably seen Dockerfiles in the root of your project when you clone one from github. You may have also seen other types of docker-related files like Makefile and .dockerignore. Don't worry about those yet. If you're unfamiliar with github at this point, I would recommend reading through the git scm before starting this book and possibly installing the desktop version of Git for Windows/Mac. In the later chapters on Terraform, you'll be iteratively working alongside the code with commits to your own git account.

Know that the Dockerfile is a script file which creates an image and contains all the commands needed to start a container. The Docker image created from the Dockerfile consists of a series read-only layers (commits) that are stacked and each one is a delta of the changes from the previous layer.

The flow of containers goes like this: the command "docker build" packages our microservice as an image. Then, "push" publishes our image. Then, the "run" command uses our published image to execute a container. Commands like "docker build" and "docker run" are associated with a single container but "docker-compose up" can build and run multiple containers at once. You'll get familiar with all these commands in the first three chapters and also running them in combination with a cloud provider.

Running a Docker container directly from the Azure container registry presented some authentication challenges. You'll need to set up the Azure CLI according to the Azure docs. If you get authentication errors, remember to Docker login with the username and password in your Container Registry > Access Key. Although it won't come up in the book until after you need it, a service principal is an authentication mechanism for Azure. It allows our clusters to authenticate with Azure so it can create load balancers as external endpoints for our customer-facing microservices. I linked the file for creating this principal later in this article.

Chapter 4-5: Databases and Communication between microservices

The book uses the MEAN stack, meaning that we'll be using mongoDB as our database. You'll have to upload information to mongoDB through the use of a tool called Robo3T. I was only successfully able to install this tool with the brew command and not from the website. After loading the json file from your example folder into Robo3T, you're supposed to be able to see your video with in localhost with the id appended, but this didn't work for me- no idea why so far.

Ch5 introduces the concept of volumes and message queues. Application code should be ephemeral and tied to the lifecycle of our container. But what about persistent data that we want to stick around and lives outside of the container? This is achieved with volumes. This allows us to upgrade or delete our database container without losing any database data that is tied to the application. Note that the book doesn't talk about bind mounts specifically- you'll have to learn those separately. The rest of the chapter is briefly devoted to message queues. In this, you're still executing much of the already established code in these chapters vs writing the code yourself. This is one negative I would have with the tutorial except the book is covering a lot of ground to begin with.

Chapter 6+: Creating Infrastructure

Ch 6 goes over the basics of Infrastructure as Code and how you'll want to use declarative over procedural languages. The book defines infrastructure as code is a form of executable documentation. Terraform is a tool/language for configuring infrastructure for cloud based applications. Kubernetes is a container orchestration platform (which is why we started the book with Docker). It's a good idea that if you don't know Docker/Kubernetes/TF to start with Docker.

There can be a large number of Terraform files ending with .tf in your repository. Providers.tf is where you'll set up configuration having to do with your cloud provider. The choice of Azure configuration again presented more challenges that I don't remember having when practicing Terraform with AWS. To set up Terraform/Azure correctly, I had to follow the instructions on creating/using a service principal: https://docs.microsoft.com/en-us/azure/developer/terraform/get-started-cloud-shell-bash?tabs=bash. My Mac natively with zshell so just replace .bashrc with .zshrc.

There are several caveats here when getting errors. Always terraform init in any new directory, to change your app_name/resource group to a unique name, and remember to change your kubernetes version to a working version for your region.

Cloudflare and Terraform- Tweaking the AWS Cloud Resume Challenge Experience

Julie Laursen — Sat, 11 Sep 2021 22:16:39 +0000

I recently went through the AWS cloud resume challenge, only in the end to realize that I didn't want to do my project in SAM at all, but in terraform. For that, I wanted to try a new terraform project first with some of the same elements such as an S3 bucket, visitor counter and CI/CD.

Following this site Host a Static Website with S3 and Cloudflare , here's how I created my project with terraform:

CloudFlare

I really wanted to learn CloudFlare because it includes SSL, CDN services and DDOS protection. We also use both CloudFlare and CloudFront at work, so I wanted experience in both. CloudFront also advertises itself as easy set up and having tried both options, I'd have to agree.

Set up

First, acknowledge that you can't do this tutorial in a day. You have to wait for several steps:

Cloudflare to complete their verification.
When you update nameservers in AWS, the changes don't propagate immediately. AWS needs to approve these as well.
Finally, you have to tell Cloudflare to poll Route 53 again for the changes.

The tutorial we're following wasn't very specific on how to include Cloudflare authorization. I started down the rabbit hole on CF-terraforming's github but it requires you to go through another tutorial on CloudFlare workers first: CloudFlare workers. That seemed a little complicated so I just did this:

provider "cloudflare" {
  #Cloudflare email saved in $CLOUDFLARE_EMAIL
  #Cloudflare api token saved in $CLOUDFLARE_API_TOKEN
}

and then in my tfvars file (not my variable.tf file) I just instantiated

 CLOUDFLARE_API_TOKEN=<my token>

And bob's your uncle- not only did it work, but I didn't have to worry about setting up SSL certificates and waiting for approval. I didn't have to tweak the CNAME. CloudFlare is definitely easier.

Adding Website files to your S3 bucket

It's exciting to see the 'terraform-apply' command working the first time, but don't get your hopes up by clicking on your S3 bucket yet. You'll notice that bucket is empty.

Run

aws s3 cp website/index.html s3://$(terraform output -raw website_bucket_name
)/

and not only will you see the file uploaded to your S3 bucket, but if you go to your domain, your index.html will load.

Github Actions and Terraform

Now, to continue to update your website, you'd have to type this aws CLI command every time! How annoying. Set up a Terraform Cloud account and follow this tutorial to automate your Terraform code with Github Actions

Finishing my website

I didn't end up with lambda/dynamoDB/api gateway or a counter after all. I saw I could do everything I wanted by integrating google sheets. I created a script from my google sheets and then verified by creating a TXT record in DNS.

https://github.com/dwyl/learn-to-send-email-via-google-script-html-no-server#3-set-the-to_address-in-the-script

https://support.google.com/a/answer/7173990?hl=en

My AWS Cloud Resume Challenge Experience

Julie Laursen — Wed, 04 Aug 2021 01:47:55 +0000

About Me

I'm a QA/SDET living in Austin, TX with 10+ years experience in tech, but I've been interested in devops before it was named. In 2008, I was working as a manager in a NOC. I remember writing queries to monitor the real-time stats of my employees in Microsoft SharePoint and color coding them with red, yellow and green. I didn't have to guess who needed help or who was on track, I just knew I would be "alerted" when needed. I wanted to do more work like this, but I didn't know what or where to start. At the time, I considered myself just a manager.

Several years later, I made the switch back into technical. When I got write access for Google Cloud Platform (GCP) at one of my jobs, my role got exponentially more exciting as I was able to help train the machine learning algorithm for a chatbot in Google Dialogflow and create a testing framework for it in Node.js. Getting permission for that project was a lengthy process and my goal with the Cloud Resume project is to prove my AWS chops so I'm not in a position of waiting so long for access next time. Recently, I joined a team at a company which uses the phrase "one team, one heart" and is one of the few positions I've had where the wall between QA and Dev is so low that I can bunny hop right over it when needed, chiming on code reviews or adding test IDs to front end repos.

Right now, I'm helping QA their infrastructure as code. This mostly consists of small tests such as deploying an artisan command in AWS OpsWorks and querying the database for results. As all those small pieces of stories come together and as I slowly test through the various epics that the stories are made from, it will result in me having more of an end to end understanding of our architecture.

Hope you enjoy!

The Challenge

The Cloud Resume Challenge

I'd highly recommend buying the book to start. The author allows for a lot of substitutions that I would have chosen had I read through all of his documentation beforehand. If I could re-do anything about the challenge, I would weigh the pros and cons of different ways of implementing the challenge before diving right in.

The Certification

Step 1 of the Challenge is getting the AWS Cloud Practitioner certification. This was a pretty easy certification. I initially tried to take the Solutions Architect Exam, and when I sat down for it, all the questions seemed to revolve around tools I've never used in the real world and wanted you to memorize a lot of pricing. It seemed very sales-oriented and not worth it. The CP exam, however, just covered the basics of most of the services that I actually do use, and didn't require more than a few weeks of studying. I passed that my first attempt and pivoted to this project before deciding I'd rather go for the Developer Exam instead of Solutions Architect.

HTML and CSS

I wrote my resume in HTML and CSS. Pretty easy, I've actually done this once before. I spent a little more time at it for the challenge because I wanted it to look more styled and less blocky. This took a couple of nights.

Creating a static S3 Website

Again, this was pretty easy as S3 is a huge topic in both the Architect and Practitioner exams, but I did have to wait a bit for AWS to approve my domain name.

HTTPS + CloudFront + DNS

Here's where the challenge started for me. I knew I needed to protect my website with HTTPS but I didn't know whether I needed to create the SSL certificate myself. I also didn't know which order to do things in. I went to youtube for some tutorials and some people started with DNS and ended with CloudFront. Other people started with CloudFront and ended with DNS. Some people did some fairly strange things with multiple buckets. I learned that there is no "one right way" in AWS. In the end, the DNS was fairly simple but my CloudFront distribution wasn't pointed at a specific file in the bucket, my index.html. While it was at the bucket level, my domain name only displayed style errors in XML. It took over a day to figure that issue out and get back in business.

Javascript

I ran into another issue here where I added a dummy counter to my front end (just a random number). When I uploaded the amended file to my S3 bucket and refreshed the domain, my update didn't show. I didn't know about invalidating CloudFront endpoints or why I needed to do so. AWS documentation was helpful here: Adding, Removing, or Replacing Content That CloudFront Distributes

Databases, Python, Lambda

I knew the sequence of events was going to be

S3-> API Gateway -> Lambda -> DynamoDB

Having DB experience, I ended up creating a DynamoDB table first and hooking Lambda up to it. I then created a python script to update the visitor count in the DynamoDB table using the Atomic Counter function. A tutorial that came in handy was this one here. Also, this article came in handy on learning how to format my Lambda functions.

Another topic that came in helpful from studying the AWS exams was IAM. I needed roles with permissions between all the different components and my API gateway needed a trust policy. I'd recommend having a foundation in IAM before starting the project.

API

Now, I have my api gateway set up and I was able to hit the endpoint URL successfully. My resume is updating my visitor counter with a PUT statement.
Geeks For Geeks was a helpful website on learning how to embed the javascript code in my HTML.

Github, CI/CD, Tests

Steps 11 and 14 of the challenge required Python tests to be ran whenever there's an update to your code. I created a quick API response test and added the run step for the file in my github action's yml. Now whenever there's a commit to my project, the test kicks off.

The biggest issue I had here was python and vscode working together. It took hours to find the command

pip freeze > requirements.txt

and my github actions wouldn't kick off the run step without that file in my project. The other issue is that I still have more tests I want to run in pytest, but I have yet to figure out why my vscode isn't recognizing my import statements.

Infrastructure as code

Here's where I should have started. Since I was following the steps in order, I began the journey by setting up my services mostly manually through the console. Though I prefer the CLI, manual set up was much easier to follow the mostly GUI based tutorials in the AWS docs. I created a github action in my front end repo to sync any existing files to my S3 bucket and made a small change to test it that ran successfully. I then tried adding SAM to my project starting with DynamoDB, but didn't find many examples of editing an existing DB.

So, that's where I'm at today. I'm not impressed with SAM and I've decided to re-do all my setup in either the AWS CDK or Terraform. I followed Hashicorp docs to provision and terminate an AWS instance and I'm looking at re-deploying my services in terraform. Since terraform may destroy any components that it updates, there's a small chance I'll blow out my whole project on this step.

So, I'm ending my cloud resume project for the time being, not 100% complete. However, every new bride needs a wedding website, and since my wedding has a hard stop date, I've chosen to practice deploying that website on terraform. I'll pick the AWS Cloud Resume Project back up after my save the dates are sent. In the meantime, you can view my project at https://julielaursen.com

Thanks for reading :)