5 Meaningful Lessons Learned Working at a SAAS Tech Startup

Tech Company

This past week, I said goodbye to Hatch, a B2B SAAS software company I joined a little over a year and a half ago as a QA tester. The past year and a half was an amazing experience that I will be incredibly grateful for as I move into the next phase of my career. When I first started at Hatch part-time, I was running a design business and contracting with two other design agencies, but had wanted to get experience in an Agile work environment more geared towards software development and UX design (versus the traditional design agency models I’d worked in the past). I hardly knew what QA was, but I knew the company and had shadowed under the product manager at the time when I was still in school. Hatch generously gave me a chance, and I had the amazing opportunity to dive headfirst into the software development life cycle. 

(For those of you who might not know, the point of QA is essentially trying to test, or break software in ways that a user might before it goes to “production,” the software that you, as the client, actually use and see, in order to prevent and squash as many bugs as possible before the software goes live. QA is basically the Hodor from Game of Thrones who protects end-users from buggy software.) 

The first two months were pretty hilarious since I didn’t even know how to use Jira or Slack, much less find (or report) a software bug. The product and dev teams kindly taught me as I went, showing me how to inspect elements and open the console to find any network errors. I got to learn about test automation and test planning and got a real feel for how software is created, as well as the importance of testing as a concept. I had never realized how weird software is in the fact that there can be serious regressions, or new ways in which the software stops working after new changes are added to existing code. Basically, you can have perfectly functioning software one day, somebody adds two lines of code, then everything breaks. 

Have attention to detail

As different as QA was from anything I had ever done before, I actually found that my production design background was wildly invaluable as I navigated this new career. Production design made me obsessive-compulsive about the tiniest pixel discrepancies and design quality of major print projects for huge signage, truck vinyl, and billboards. This sensitivity and attention to detail helped me start to notice even the smallest differences in software release to release, like typeface changes and unclickable fields. 

Test like your end-user actually uses the app

I learned this lesson early into my QA career. I would test the app according to all the main acceptance criteria and use cases from feature stories, but we’d still find major bugs that I had never thought about, but it was something our data team or customer success team would have caught instantly because they live in the product every day. 

Thinking holistically about how the client will use and need each product functionality became one of the most important aspects of how I would go about designing test cases and criteria.

Learn the product, and learn it well

This one might seem obvious but made a crucial difference to me as I transitioned from part-time to full-time QA. At first, the product seemed simple, but I soon realized how many tiny features and integrations made the overall functionality so much more complex, and how important it was to have overall product knowledge beyond just each overall feature. By getting to know the product very deeply, I was able to understand all the varied product use cases and see errors much faster.

You can’t catch all the bugs (but you can try!) 😈

We always beat ourselves up whenever a bug makes it through to production, but it’s important to realize no human can find and report everything. We’re all responsible for quality on the software team and it’s a team effort to find and figure out what caused the bug. 

You can do it! (Even if it seems impossible)

Working in QA definitely improved my confidence about working in tech too. Before Hatch, I had done basic front-end development for clients and small-scale sites. I had tried to learn other languages besides HTML and CSS but generally just given up because I had felt overwhelmed or just uncertain in my abilities to learn it. But as my job changed and grew responsibilities, I ended up learning a lot of technical skills, like Postman, Python, and Selenium by necessity with the generous help of the developers. I even got to push code to Github and be a reviewer on pull requests! 


While I’m going back to my design roots in this next opportunity, I believe that this solid foundation in QA, product design, and software development has truly made my design work so much stronger and expanded my perspective of what’s possible. I’m incredibly grateful for all these experiences and team members who have taught me so much along the way.

Previous
Previous

Adobe XD VS Sketch VS Figma: thoughts on choosing the right UI prototyping tool for your design team

Next
Next

How to ship superior code by separating QA skillsets