Sometimes, as a test engineer, you have to argue with product owners about seemingly obvious things. — It was at the time when I was testing a media web service with around 16 millions of average monthly visitors. There was a legacy page with a list of snippets of some content (images and descriptions) and a [Show more] button at the bottom. The problem with such a…

Sometimes, as a test engineer, you need to log in to Google (or other third-party authentication providers) to give access to your website for autotests. — In my recent project, I have to test a web app under an authenticated user, but the only authentication provider was Google. The problem with third-party authentication providers for autotests are: Complicated API; Auth providers have anti-robot detectors.

Sometimes, as a test engineer, you have to perform testing under a knotty environment and not affect production with your activity. Autotests can help, but they require thorough preparations. — Before diving into the topic about autotests, I need to explain the architecture of my project and its testing environments. Without this context, it will be unclear what a problem is solved here: I have a cluster of hundreds of IoT devices;

As a test engineer who has to maintain a bunch of autotests, you will definitely face the task of speeding up the execution of your test suite. — When your autotests grow in number, they are running slower and slower. Managers and developers do not usually like to wait long to find out the results of regression testing. To shorten the feedback loop, your test suite should run as fast as possible (within reason).

Being a test engineer (QA) for a decade «I’ve seen things you people wouldn’t believe», I’ve tested enough web applications to accumulate experience that can be shared. I collected tricky test cases which somehow led to bugs and hacks to perform unusual checks. They are sorted by logical blocks in…

When a frontend team starts building a testing infrastructure, there is always a debate about the choice of testing tools. — There are dozens of tools for testing web applications on JavaScript, TypeScript and Node.js. Ava — test runner; CodeceptJS — end-to-end testing framework; Cypress — end-to-end browser testing framework; Hermione — test runner for browser testing based on Mocha and WebdriverIO;

While working on test automation in different projects, I’ve learned that there are not enough static analyzers and code formatters for writing good tests. The team had to have an agreement on how the tests should be written. — If any team member will write tests with his own ideal vision it will be a mess. Some patterns, applicable to unit tests on Java or Python, do not fit for integration tests on JavaScript and vice versa. …

The main tools for writing UI tests are: browser, IDE and testing framework documentation. — Playwright’s documentation is rich and intricate at the same time. Sometimes you can make a check or perform an action one way, and after a while find that it could be done in another way — just because you look into the API section instead of Docs or vice versa. …

Testing JSON could be a part of contract testing — you check whether the response body corresponds to specification (or contract or terms of reference). — The most appropriate way to do that is through JSON Schema — the method of description of the structure of the JSON data. Besides JSON Schema, each individual key/value pair can be checked for compliance with a number of criteria from the specification.