https://dsheiko.com/categories/testing--qa/ Recent content in Testing & QA on Dmitry Sheiko's Web Development Blog Hugo -- gohugo.io en-us Tue, 25 Mar 2025 00:00:00 +0000 https://dsheiko.com/weblog/optimizing-end-to-end-testing-with-playwright/ Tue, 25 Mar 2025 00:00:00 +0000 https://dsheiko.com/weblog/optimizing-end-to-end-testing-with-playwright/ End-to-end (E2E) testing is a crucial step in ensuring that web applications function as expected across different scenarios, devices, and browsers. However, maintaining efficient and reliable tests can be challenging. This is where Playwright shines — offering a powerful and developer-friendly framework for robust E2E automation. In this guide, we will explore how to optimize Playwright for E2E testing, covering best practices for improving test readability with fixtures, handling authentication flows, working with data tables, and verifying responsive design. Additionally, we will dive into performance budgets to maintain a smooth user experience. Whether you’re transitioning from Selenium or Cypress, or you are new to Playwright, this guide will help you write cleaner, more maintainable tests that ensure your web applications perform flawlessly. https://dsheiko.com/weblog/puppetry-3-test-automation-without-coding/ Wed, 27 Nov 2019 00:00:00 +0000 https://dsheiko.com/weblog/puppetry-3-test-automation-without-coding/ Nowadays nobody would argue the importance of automated testing. Yet end-to-end tests are often hard to write and even harder to maintain. There are many solutions to help with it. Puppetry is a test constructor, which allows you building test suites without any coding. QA-engineer can record user scenario in a built-in browser, extend the generated test case with browser commands and assertions, manage the suite structure (like drag’n’drop) and run tests. https://dsheiko.com/weblog/testing-sign-up-flow-with-activation-by-email/ Mon, 08 Jul 2019 00:00:00 +0000 https://dsheiko.com/weblog/testing-sign-up-flow-with-activation-by-email/ Functional testing is nothing new. We all do it, to varying degrees, with different tools and approaches. But when flows involve transactional emails (signup confirmations, password resets, purchase notifications), things get trickier. You instruct your testing tool to navigate to the registration page, fill out the form, and click submit. The app sends a confirmation email with an activation link. Now your tool needs to read that email, parse it, and navigate to the link. https://dsheiko.com/weblog/puppetry-2-0-released/ Mon, 01 Jul 2019 00:00:00 +0000 https://dsheiko.com/weblog/puppetry-2-0-released/ Eventually Puppetry 2.0 was released. The development took for a while, yet it contains a lot of changes. In fact the branch 1.x was basically a GUI for Puppeteer/Jest, but the tool grew up into a fully-fledged testing environment. Now Puppetry has a built-in templating engine, which supports environment-dependent variables and expressions, what brings a great potential. Just consider: you have test/stage service, which never resets. The only way to test, let’s say, signup flow is to create a new (no-yet-existing) user account. https://dsheiko.com/weblog/end-to-end-testing-with-puppeteer/ Mon, 11 Jun 2018 00:00:00 +0000 https://dsheiko.com/weblog/end-to-end-testing-with-puppeteer/ A sound application architecture doesn’t resist to changes, but welcomes them. Yet it still doesn’t guarantee that the code is unbroken after we implement new features, making fixes or refactoring. Here we run automated tests to ensure that the app integrity didn’t suffer. So we write unit-tests to check if separate objects, methods, functions work property independently. With integration tests we ensure they play as designed together. Eventually we create system tests to find out if the entire system meets our business requirements. https://dsheiko.com/weblog/nightmare-of-end-to-end-testing/ Wed, 28 Sep 2016 00:00:00 +0000 https://dsheiko.com/weblog/nightmare-of-end-to-end-testing/ Modern application get complex, we cannot go without automated testing. The canonical agile testing quadrants are split to technology-facing and business-facing tests. As for technology-facing testing I believe nowadays everybody has dealt with unit-tests. Thus we make sure that the smallest parts of the system act as intended in isolation. Also we use component tests to verify the behavior of large parts of the system and integration tests to check if communication between object isn’t broken. https://dsheiko.com/weblog/functional-testing-with-qunit/ Tue, 03 Jul 2012 00:00:00 +0000 https://dsheiko.com/weblog/functional-testing-with-qunit/ Automated testing is an essential part of application life-cycle (see Continuous Integration). In web-development we usually test: Back-end (*Unit-tests), Front-end (HTML/CSS validators, JSLint/JSHint, CSSLint, YSlow etc) and UI (functional testing). Unit-testing (Back-end, Front-end) is about checking if all the application components adhere the technical design requirements. Every unit-test simulates the application environment on which runs. Functional tests are to determine if the application as a whole ecosystem has no flaws. They run on a copy of real application environment and show if everything is ok from user prospective. https://dsheiko.com/weblog/you-own-simple-tool-to-test-web-forms/ Fri, 07 Oct 2011 00:00:00 +0000 https://dsheiko.com/weblog/you-own-simple-tool-to-test-web-forms/ When testing a web-site, nevermind who you are developer or QA-engineer, it happens to you pretty often to fill-in form fields again and again. Boring, stupid work, but how to make sure the form does still work as intended? Some fields added, CAPTCHA was attached, whatever else done –you have to run the test again. Besides, it will be repeated on different browsers. Browser form auto-completion feature helps a bit, but that is not the same as when you have various sets of test-data always ready to apply on a form, isn’t it?