Этот дайджест создан совместно с телеграм-каналом QA Live | тестирование ПО. Подпишитесь, чтобы получать дайджесты прямо в телеграм!
Почитать:
Баг и дефект — это одно и то же? Когда ошибка приводит к дефекту и считается багом? Какие бывают баги? Как написать простой баг-репорт, и каким должен быть идеальный репорт? Иногда люди устраивают Bug Bash, чтобы не допустить Bug Leakage — как они это делают? И еще: бывают редкие, хитрые баги, которые трудно найти, еще труднее от них избавиться, и почти невозможно забыть.
В данной статье мы подробно рассмотрим суть профессии тестировщика ПО, требования к специалистам этой области и вопросы, связанные с заработной платой.
Тестирование ПО: шаблоны тест-кейсов + примеры
В данной статье мы рассмотрим, что такое тест-кейсы, зачем они нужны, как их правильно составлять и приводить примеры использования на практике.
На других русскоязычных платформах:
У команды тестировщиков был всего один час, чтобы провести sanity-тестирование и сообщить о любых проблемах в приложении. Мы запустили автоматизированный набор тестов, содержащий около 100 тест-кейсов.
В этом комплексном руководстве мы рассмотрим фундаментальные аспекты тестирования банковских приложений. Будут приведены практические примеры создания эффективных и управляемых тест-кейсов, которые необходимо включить в тестирование при развертывании приложения.
В этой статье мы рассмотрим, как написать тест-кейсы для страницы входа в систему. Все примеры мы разбили по категориям на основе различных типов тестирования. Вы можете обращаться к ним при создании тест-кейсов для вашего приложения.
API или программный интерфейс приложения является одним из стандартов современной разработки программного обеспечения. Тестирование API – это процесс, используемый для проверки того, что API работает так, как ожидается. Оно включает в себя проверку функциональности, производительности, безопасности и совместимости API. Тест-кейсы для API могут быть выполнены путем отправки запроса к API и изучения возвращаемого ответа.
Первое, что я поняла, начав работать в тестировании – это то, что я страстно ненавижу системы управления тест-кейсами. Если вы не знакомы с такими системами, то это инструменты, позволяющие тестировщикам создавать коллекции ручных тестов, чтобы использовать их повторно. До бума популярности тест-автоматизации они были очень распространены. В этой статье я объясню, почему я так их ненавижу, а затем поясню, почему все равно ими пользуюсь и меньше недолюбливаю ту, которую я выбрала.
Наша главная задача как тестировщиков – это выявить реальный статус продукта. Помните – все остальные участники проекта сконцентрированы на Успехе, Предотвращении Проблем, Встраивании Качества, Добавлении Ценности, и всякое такое. Все это здорово, ничего плохого тут нет. Но есть нюанс.
В этой статье я хочу ответить на вопрос, заданный мне в LinkedIn Полом Сименом (Paul Seaman). Он спросил, что я думаю о документировании автоматизированных тест-кейсов как способе продемонстрировать, что автоматизация вообще делает.
Я видела много статей о том, что это вообще такое, но мне очень не хватало шпаргалки по разным селекторам, причем в разрезе «Вот он в CSS и он же в XPath» для сравнения.
Вы — разработчик и хотя бы раз говорили тестировщику «докажи руками»? Или вы — тестировщик и хотя бы раз слышали такое от коллег-разрабов? Либо вы — продакт или тимлид, в команде которого случались или могут случиться такие конфликты? Тогда эта статья для вас!
Привет, Habr! Прошло уже некоторое время, и AI довольно быстро стал интегрироваться в инструменты и пускать корни во многие профессии, QA не исключение. Здесь точно есть что оптимизировать, ведь у тестировщиков всегда много рутинных задач, которые требуют внимательности, но не слишком сложны по своей сути.
Цель данной статьи — продемонстрировать подход к созданию стенда для нагрузочного тестирования в том виде, в котором пишутся обычные интеграционные тесты: в форме spock-тестов с использованием Testcontainers в среде Gradle проекта. В качестве утилит нагрузочного тестирования используются Gatling, WRK и Yandex.Tank.
Возникали ситуации, когда стандартных методов поиска веб-элементов не хватало для полноценной автоматизации? То кнопка не нажимается, то элемент перекрывается, то не подгружается. У всего этого есть разные причины и самые разные решения.
Если тесты выполняются пару раз за спринт, то ошибки могут показаться незначительными. Но в моем случае, где скрипты работают постоянно в качестве мониторинга, ошибки браузера становятся настоящей проблемой. В этой статье я собрал некоторые опции для запуска Chrome, которые позволили сократить количество ошибок и улучшить качество мониторинга.
В мире QA на других платформах (англоязычных):
It might seem that a web browser, aside from Developer Tools and internet access, doesn’t hold much of interest for QA. Many assume that the essential tools for QA work must be installed as extensions or separate programs. However, there are several underrated internal tools within the browser that can significantly enhance the daily workflow of QA professionals. Here’s a look at some of these hidden gems that many are unaware of.
In the previous article, I highlighted some notable Playwright methods that made testing easier when I started using it as a default test automation framework in production. Here I continued to pick up some interesting features of that tool.
This post has been sitting in my drafts pile for far too long. I wrote an outline for this post nearly a year ago! Then Janet Gregory and Lisa Crispin recently made a post about flaky tests which reminded me I still had this post awaiting my attention. I decided it’s time to pick this back up and finish writing my guide to handling flaky tests.
As a QA engineer with over a decade of experience across various sectors, I have witnessed the evolution and undervaluation of Quality Assurance (QA) and Quality Engineering (QE). Despite being crucial to the success of any project, QA often takes a backseat. This document explores why QA/QE is underrated, the misconceptions surrounding the field, and how we can change these perceptions.
I’ve worked in various roles, such as QA Engineer, QA Lead, Test Manager, and Technical Manager, where I witnessed conflicts between QA individuals and other departments. I know firsthand how frustrating this can be, but I’ve learned some tricks to help navigate and resolve these situations positively.
Settle in for a long one this time. I would like to write about my journey from being a Tester back in 2004 to being a software engineer today ( 2024 ). A mere 20 year long journey. I’m going to write down how I got this far, what it took, the sacrifices, fears, doubts and all the things in between. Let’s get started.
I’ve been the first QA hire and an early hire for start ups and engineering organisations. Here’s what I’ve seen and the things that I wish you knew when picking what to hire for.
Hakkim Alavudeen, Head of App Engineering @ Zalando.
The most common testing problem is getting consistent results from a suite of automated UI tests(often referred as regression tests). This issue usually arises when QAs keep adding new UI tests to the regression suite without any proper testing strategy.
When we introduced a default setup for system tests in Rails 5.1 back in 2016, I had high hopes. In theory, system tests, which drive a headless browser through your actual interface, offer greater confidence that the entire machine is working as it ought. And because it runs in a black-box fashion, it should be more resilient to implementation changes. But I’m sad to report that I have not found any of this to be true in practice. System tests remain as slow, brittle, and full of false negatives as they did a decade ago.
Посмотреть:
- 10+ Mobile App Testing Types ⏱25 минут
In today’s video, I am going to talk about mobile app testing types. Mobile testing is special because of many factors. First, there is the high mobile app user expectations. If apps are too slow or bad in design, they will get deleted. Second, there are so many different mobile devices on the market that mobile teams need to support. At the same time, mobile devices are small super computers running all our data. In this video, I am presenting you more than 10 different testing types for mobile apps. At the end of the video, I share a source with you, that might help you even more when you are working in the field of mobile testing.
Артем Русов собрал топ 30 вопросов на собеседовании тестировщика по теории — в одном видео.
In this worked example I show how to build a high level coverage plan which can be used to guide testing.
Хорошей недели!
