Blog  Subscribe to our RSS feed RSS

A Day in the Life of a QA Analyst

We asked one of our co-op students, Mike Wu, to give us both a glimpse into life at Gossamer Threads as a relative newcomer, as well as what his work as a Quality Assurance Analyst entails. What follows is a story of bugs, barbecue and Big Two…

Being a third-year computer science student, it was a bit intimidating to start the co-op program and work full time at a web tech company, especially since my previous work experience wasn’t in the technology industry. However, through the camaraderie and family-like atmosphere at Gossamer Threads, I quickly got over my somewhat unfounded fears. My co-workers at Gossamer quickly welcomed me to their team and I haven’t looked back since.

Below, I’ve documented an example of what I do on a daily basis as a Quality Assurance Analyst. I hope that anyone reading this blog will gain some insight into what I do, and the culture at Gossamer Threads

Start of the Day

10:00am: I usually come into the office at around 10am. Gossamer doesn’t have strict hours and managers are flexible with hours, as long as you work 8 hours each day. To start the day off, I always read through my email, checking for new tickets which have been assigned to me. Tickets is Gossamer lingo for a logging system that we use to record changes, comments, and updates related to any bugs, issues or features.

Ticket Creation
A sample ticket used to track work and goals.

10:30am: After reading through my email, I’ll start testing the highest priority ticket. For example, I can have a ticket that requires me to test if a new search functionality is working as expected. This would be a high priority ticket if the ticket is expected to be pushed (or go live) to the production site (what the users sees) in the late afternoon. Each ticket has a description, comments and/or screen-shots attached. Tickets are passed back and forth between me and other team members, so it’s vital that I understand the comments and notes each developer leaves on the ticket so I can test the ticket appropriately.

Take, for example, the search functionality ticket. Before I start testing the functionality, I need to understand the types of users that will use the search, the types of information they are searching for, how the results are displayed, etc.

Believe it or not, a lot of thought is put into the functionality of a search!

Often, features will have different test cases documented. I can follow and test each test case and add new test cases where I see fit. A new feature added might be: if a term has a ‘-‘ character in front of the search term, then all results containing the following term will not be displayed.

Some test cases I would test for in such a case might include:

  • Test that all previous recorded test cases in the test suite are working. This is also known as ‘regression testing‘. This tests for new bugs introduced by new changes.
  • Test searching for normal terms without the ‘-‘ character. This tests that the normal test terms (before the added functionality) still work.
  • Test searching for a term containing the ‘-‘ character in front of it. This is the obvious and most important test case. This is also know as the ‘Sunny Day‘ test, cases where a result is expected or not expected to work.
  • Test for more obscure cases related to searching, e.g. Search for terms with two ‘-‘ characters.

If all the test cases pass, I update the test suite and add in all the new test cases in the appropriate section. Then, I validate the ticket, leaving a comment about what I have tested and what is working. Following that, I pass the ticket back to the project manager.

If at least one of the test cases does not pass, I will make a note of all the bugs that are appearing and directions on how to reproduce each bug. If I know exactly how each bug is produced, or if I have any extra information, such as how it is produced or how it can be fixed, I also leave a few extra notes on the subject.

Whenever bugs are hard to describe, I like to take screen-shots and annotate the image with arrows and short descriptions to make it easier for the developers to understand. I also like to record a video of my browser whenever a bug is difficult in to describe the reproducing steps.

A sample bug
A sample bug.

After updating the ticket with all the bug information, I assign it back to the project manager. The ticket will then be assigned to the appropriate developer and it will eventually circulate back to me to test again.

Lunch time!

12:30pm: After testing tickets for about 2 hours, I get ready to have my lunch. Lunchtime is a great time to catch up with my co-workers. We often have competitive games of cards like Hearts, Big 2 and poker. Also, during the summertime, we regularly have company BBQ’s where we go upstairs to the roof for hamburgers, while we bask in the warm sun.

The luxurious Gossamer roof!
The luxurious Gossamer roof!

1:30: After lunch, it’s back to work again. First, I go through any new emails, and then I return to testing new tickets. Occasionally, I’ll have a few questions regarding some specific functionality for a ticket. If that happens, I send a quick instant message to the developer or pop over to their table if they aren’t too busy. This saves me a lot of time digging and investigating for answers. I think communication between a developer and a Quality Assurance Analyst is important for both parties. It helps both understand the product better and, in return, produces a higher quality product.

6:20: If I finish a ticket within the last 20 minutes of the day, I like to plan out my next day. I read through a collection of comments, try to understand what I need to test for the ticket, and then make a mental list of what I need to test the next day. I find this is better than trying to start and rush through a brand new ticket. This also helps increase my productivity and efficiency.

6:45: This is when I will normally end my day. If I have any to-do items, I write them in a text file and leave it open on the desktop for the next day. It’s a quick reminder to me when I log on the next day as to what I’ve been doing. That way, I can pick up exactly where I stopped working.

To-do list
An average to-do list.

Happy Hour

Often, at the end of the day, my co-workers will get together for a friendly game of two-on-two Ping-Pong. Sometimes, if folks are interested, we also get together for a fun game of poker. Of course, when the bosses (Alex and Jack) join in a game, I always remember to lose on purpose!

Adrian and Asaf locked in a deadly battle of Ping-Pong.
Adrian and Asaf locked in a deadly battle of Ping-Pong.

After a productive day at the office, it’s time to go home and rest and get ready for the next day.

Hopefully this has shown what it’s like working as a QA Analyst at Gossamer Threads. Of course, there are the intangibles about the company that I haven’t touched on, like how friendly and easy to approach everyone is. I also enjoy the fact that Gossamer isn’t just about doing work all the time. We have a lot of fun with our paint-balling events, dodge ball competition, Poker tournament, and even a Stair Climbing Challenge – which I’m proud to say that my team won!

All in all, Gossamer isn’t just about the work we do, it’s about the way we work, and having a good time along the way.