"First do it, then do it right, then do it better." 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 challenges and aha moments, 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.

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

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

The time will come when you will ask yourself, which side of the QA force to choose? 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 with all the skills and holistic mindset, you still have to be kind of a rebel 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, in the world of QA engineering, you will be both creator and destroyer. 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.

PS: 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.

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

Unusual syntax, macros, and rollbacks 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 reduce the regression test suite (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 pharmaceutical companies and laboratories that analyze biomarkers needed for meds synthesizing and disease research.

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

In fact, there is not much difference 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 specific code coverage tools, linters, and other nice things from the gentleman's QA bag.

Some interesting points I've mentioned:

✅ Testing on the JVM. For example, Health Samurai uses JVM for unit testing to minimize execution time and test frontend code quickly and cheaply.

✅ REPL. REPL Driven Development or, to be exact, REPL-Like Driven Development becomes a common 'practice' for different languages. But Clojure as a Lisp-family language is about a fully-featured REPL, all-wheel drive REPL, REPL as a core idea. Clojure is true a REPL and I enjoy this experience a lot.

✅ Hot Reload. Automatic reloading of code during development is one more great thing. Debugging by using Hot Reload is something worth trying.

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: Unit Tests, Service Tests, and User Interface Tests 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.