Автор: Ekaterina Noga, оригинальная публикация

Мы поздравляем вас с наступающим Новым Годом и Рождеством, и желаем вам карьерного продвижения, интересных задач, зажигательных докладов, и чтобы баги попадали в ваши сети до релизов!

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

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

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

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

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

По мере роста компаний, разрабатывающих ПО, зачастую возникает необходимость что-нибудь измерять. Если в компании всего пара-тройка десятков человек, легко заметить, хорошо или плохо работает тестировщик. Однако когда компания разрастается до сотен и даже тысяч, все тяжелее и тяжелее отслеживать, как у всех сотрудников дела.

На этом этапе менеджмент растущей компании приходит к выводу, что надо отслеживать метрики, чтобы понимать, как работает команда. Зачастую будет предложено подсчитывать свои баги. Но что означает количество багов? В этой статье обсудим, что эта метрика расскажет вам, а о чем умолчит.

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

В предыдущей части статьи мы рассмотрели общие подходы к тестированию PDF и познакомились с тем, как библиотеки pdfminer и PDFQuery помогают нам получать детальную информацию об объектах. Достаточно ли нам этой информации? Далеко не всегда. В этой статье мы расскажем о решении некоторых интересных технических проблем.

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

Недавно я разговаривала с коллективом и предположила, что тестирование – не всегда решение вопроса. Они были озадачены.

Не поймите меня неправильно, я работаю с качеством, это моя страсть, я не буду отговаривать вас от него, но бывают трудные времена, когда стоят другие приоритеты, и, думаю, неправильно советовать просто тестировать, несмотря ни на что.

У тестирования и автоматизации два основных принципа, и если вы меня знаете, то, возможно, уже про них слышали:

1. Тестирование – это про верный баланс.

2. Автоматизация – это про экономию времени.

Оба связаны с издержками: в первом случае, если тестировать дороже, чем продолжать без тестирования, то лучше пропустить этот тест (или тесты).

Во втором случае, если автоматизация займет больше времени, чем общее время на ручное тестирование, автоматизировать не нужно.

Принципы, возможно, звучат очевидно, но в реальности не так-то просто принять решение не тестировать или не автоматизировать. Это контринтуитивно, и в голове звучат панические «А что, если».

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

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

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

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

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

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

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

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

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

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

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

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