QA's Notes: My Toolset, Testing Myths, and First Clojure Project

About me

{{list-bl31-1="/custom-block-to-blog/one-page"}}

"<medium>First do it, then do it right, then do it better.<medium>" This quote by Addy Osmani could be a pretty good motto for the testers division.

Anyway, that's how I see my mission as a QA engineer.

Full of <medium>challenges and aha moments<medium>, the tester's career is the path worth stepping on. Here I want to share my thoughts on how to do it with joy, what tools to use, and more.

3 common myths about QA testers

Let's start with 3 popular myths and misconceptions about software testing, and try to bust them.

{{list-bl31-2="/custom-block-to-blog/one-page"}}

If you're passionate about <medium>exploring software development, diving into processes, and want to improve your critical thinking skills<medium> — software testing is exactly what you need. Take your time, stay enthusiastic and let's start the journey!

How to become a QA tester or leave this idea forever

{{fact-bl43-9="/custom-block-to-blog/one-page"}}

The time will come when you will ask yourself, <medium>which side of the QA force to choose<medium>? The light one — to think holistically about architecture and entities, harnessing peace and calm? Or stay on the dark side, breaking things developed and being up to tricky things missed by devs?

The truth is that <medium>with all the skills and holistic mindset, you still have to be kind of a rebel<medium> not to lose sight of risks, bugs, and others.

Here is the moment of glory: missed by dev, a corner case is caught by you. Thus, a critical error is detected. You prevent a bit of a headache. The apocalypse is canceled. Are you ready to become a superhero? :-)

Thus, <medium>in the world of QA engineering, you will be both creator and destroyer<medium>. And all for a good cause — to create a superb product and shape the best customer experience.

Important point: don't start chaotic learning of anything and everything. Set a goal.

For example, you want to be good at API testing.

{{list-bl31-3="/custom-block-to-blog/one-page"}}

<medium>PS<medium>: Here youare three books I'd recommend both for beginners and experienced quality assurance specialists to look at QA testing from a new angle and find interesting facts you didn't know.

{{list-bl31-4="/custom-block-to-blog/one-page"}}

QA toolkit: my top tools for testing and not only

{{list-bl31-5="/custom-block-to-blog/one-page"}}

Testing Clojure product: challenges and solutions

I'll say right away that my first experience with Clojure was not very smooth.

<medium>Unusual syntax, macros, and rollbacks<medium> which at first glance seemed to be something too complicated.

Since it was my first Clojure project, the first steps were to get acquainted with the documentation, analyze requirements and write user stories.

Next, our QA team faced quite a task: together with the dev team we had to choose the testing strategy that will <medium>reduce the regression test suite<medium> (by covering all the vital functionality with autotests).

By the way, a little bit about the project.

It's a Biomedical Data Science Platform (NDA) providing software for <medium>pharmaceutical companies and laboratories<medium> that analyze biomarkers needed for meds <medium>synthesizing and disease research.<medium>

I worked on <medium>test parameterization and improving the reusability of test scripts<medium>, which allowed developers to quickly check test results and work closely together.

In fact, <medium>there is not much difference<medium> in QA testing methods and practices used for Clojure products and software written in other programming languages.

Unit tests, integration tests, e2e tests — everything is at your disposal. You can test with or without mocks or stubs. There are <medium>specific code coverage tools, linters, and other nice things from the gentleman's QA bag.<medium>

Some interesting points I've mentioned:

{{list-bl31-6="/custom-block-to-blog/one-page"}}

It was one of the projects where we succeeded with the implementation of the testing pyramid concept promoted by Mike Cohn.

This pyramid includes the following stages: <medium>Unit Tests, Service Tests, and User Interface Tests<medium> on the top. It visualizes the principle of grouping software tests into buckets of different granularity. More high-level = fewer tests. Next time I'll tell you about it a little bit more.

{{book-bl31-7="/custom-block-to-blog/one-page"}}

Little backstage story

My typical workday is pretty simple. It starts with fresh lemon water with mint and the outdoor workout (jogging, jumping rope, etc) in the early morning.

Then, after checking work email, Jira, Confluence, and work chats, the story begins. Jira tasks, Trello tickets, tests, bugs, video meetings, and evening reports — you won't get bored :-)

And, finally, a walk along the evening park or illuminated central streets to gather thoughts and inspiration for the next workday.

Besides the professional self-development, I have three dreams:

{{list-bl31-8="/custom-block-to-blog/one-page"}}

I like to learn new technologies and share this knowledge with the team. Hope I'll have more time to do it. I am always ready to have a little talk QA or answer your questions on Linkedin. Or welcome to my Instagram page to find new posts about testing and share content you like. Keep in touch!