Home

Автор: Евгений Домнин

Представьте – вы разработчик, и тестировщик приносит баг, который найден в ходе регресса. Хочется поправить этот баг и вы просите оформить тикет. Уже представляете как возьмете его в работу, залинкуете к нему пулл реквесты и проставите эстимейты, чтобы не было вопросов у продакт менеджера.

Спустя время появляется новый тикет, но внутри лишь пара строчек и скриншот. Вздохнув, вы пробуете воспроизвести баг по этим данным, но ошибки нет. Пробуете несколько раз, но в итоге пишете тестировщику, что баг не воспроизводится и начинается новый цикл уточнений. Тратите время, которое могли потратить на решение новых задач, исправление других багов, просмотр аниме, рефакторинг.

Меня зовут Евгений Домнин, я QA и постараюсь поделиться видением, что делает баг репорт хорошим. Прошу простить за долгое вступление, давайте начнем.

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

В предыдущей статье я утверждала, что тесты не следует делить на тесты черного и белого ящика. Однако многие знакомы с этими терминами, и для них, возможно, «отбеливание тестов черного ящика» будет понятнее, чем «структурирование логических тестов».

Опишу контекст, чтобы пояснить, что конкретно я имею в виду.

Когда тесты создают разные команды, зачастую они хотят убедиться, что все покрыто и все тесты верны – особенно если между командами или их участниками нет доверия, или создатели тестов уже покинули компанию.

Вместо того, чтобы поделиться определениями тестов (в некоторых командах они даже не зафиксированы) и вникать в логику интеграционных и E2E-тестов, некоторые стремятся разработать автоматизированные проверки, верифицирующие, что все покрыто. Тут и начинается структурирование логических тестов: они хотят превратить логические тесты в структурные.

Типичный пример – когда люди хотят узнать покрытие кода интеграционными или end-to-end тестами. Это возможно, но очень сложно и дорого, да и смысла особенного не несет.

Автор: Наталья Баранова, Аурига

Некоторое время назад у нас появился интересный проект по созданию сервиса, генерирующего документы в формате PDF. И появилась задача — написать тесты, которые проверят документ в мельчайших деталях, включая и содержимое, и вёрстку. В данной статье мы расскажем, каким образом справились с этой задачей.

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В профессиональных кругах есть расхожая шутка, что консультанта легко опознать – он всегда отвечает на любые вопросы одинаково:

«Зависит от ситуации».

(иногда за этим следует «а если вы хотите более полезный ответ, то карточка к номеру привязана»).

Отставим шутки – в этой конкретной есть доля истины. В тестировании и разработке ПО крайне, крайне мало абсолютных истин.

Однако это не так легко понять, просматривая, скажем, мою ленту LinkedIn. Я где-то даже понимаю. Люди любят мыслить абсолютными категориями и говорить о них. Это простейший способ найти ответ на вопрос или сформулировать его.

Оригинальная публикация
Автор: Андрей Шушаков

Кэширование — это эффективное архитектурное решение, которое сегодня используется на всех уровнях вычислительных систем, начиная от кэша процессора и жесткого диска до кэша веб-сервера и обратных прокси-серверов. Именно о последних пойдёт речь.

В этой статье мы рассмотрим атаки обмана и отравления кэша, сконцентрировавшись на последнем: проследим историю возникновения и развития уязвимости, поговорим про кэш-движки и связанные с ними последние CVE. Также попробуем разобраться, как следует искать отравление кэша на реальных целях. Распишем методологию пентеста, оценим риски и последствия эксплуатации, обозначим общие подходы к защите.

Статья написана в рамках стажировки июль-август 2024 в компанию "Бастион". Выражаю благодарность куратору от Бастиона, Тимофею Брылеву, а также моему знакомому, Евгению Чикачёву, за совет

Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

Что делает тестировщика великим?

Недавно я видела ряд дискуссий, побудивших меня задуматься:

• Что делают тестировщики?
• Чем ISTQB-тестировщик отличается от «гибкого» или «современного»?
• Отвечает ли тестировщик за определение влияния и/или приоритета бага?
• Почему люди используют термин «ручной тестировщик» (а также споры о терминологии, сопутствующие этому вопросу)?
• Насколько широка пропасть между великим и ужасным тестировщиком; кто из них чаще встречается?

Отвечая на один из этих вопросов, я упомянула три вещи, которыми заняты хорошие тестировщики, начиная с буквы “I”. Я вновь и вновь возвращалась к этой мысли, и думаю, что на самом деле великое тестирование состоит из пяти “I”. Если вы тестировщик, не занятый ни одной из “I”, то самое время начать.

Опубликован выпуск рассылки за ноябрь.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

Оригинальная публикация

Меня зовут Ксения Сергеева, я QA-инженер в компании SM Lab, IT-компания Спортмастера. Сейчас работаю с мобильным приложением для продавцов, а за последние несколько лет успела потрудиться на благо финтеха и сервисов топливной компании. И, конечно, на каждом из проектов я сталкивалась с проведением регрессионного тестирования.

Что самое креативное в работе QA-инженера? Тестировать новую функциональность. Что самое скучное в работе QA-инженера? Гонять регресс. Здесь со мной могут не согласиться нелюбители писать документацию, но и в таком случае прохождение регресса занимает почетное второе место в списке самых занудных активностей QA.

Регрессионное тестирование (от латинского regressio — движение назад) — это совокупность проверок ранее протестированной программы с целью убедиться в том, что внесенные в программу изменения и доработки не привели к появлению дефектов и несоответствий во всех остальных частях программы.

А еще регрессу как правило сопутствует куча ограничений. Сдвинулись сроки передачи фичи в тест? Время на регресс уменьшилось. Близится конец периода, а мы не все успеваем? Режем регресс. Коллега ушел на больничный и рук не хватает? Ну, вы понимаете.