Home

Автор: Максим Бугров, начальник отдела тестирования Департамента разработки клиентских систем и сервисов, Московская биржа

Для организации разработки и тестирования сегодня принято выстраивать пирамиду тестов, это считается мейнстримом. Существуют десятки, если не сотни, вариаций пирамиды, опубликовано много докладов и статей о том, как она должна выглядеть. И почти все эти материалы помогут ответить на вопрос «Как мне построить пирамиду тестирования в новом проекте?».

Но что делать, если вы приходите в проект, в котором исторически применялся подход «мороженки» тестирования, когда основную часть проверок закрывали ручным тестированием? При этом компания проходит трансформацию, и от вас ждут, что вы приведёте процессы в соответствие современным практикам и ускорите их?

Меня зовут Максим Бугров, я больше 8 лет работаю в тестировании ПО. На Московскую биржу я пришел летом 2021 года на позицию начальника отдела тестирования. Наш департамент преимущественно разрабатывает софт, который связывает клиентов и торгово-клиринговые системы Биржи. И я расскажу, как мы начали превращать мороженку в пирамиду — нас ждал огромный ледник задач.

Автор: Владислав Тарасенко

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

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

Я часто подхожу к тестированию как к игре в шахматы. Это делает процесс поиска проблем не монотонным, порой даже увлекательным и полезным. В научной и технической литературе у этого метода тестирования есть название: Shift-Left тестирование, но всегда ли нужен такой подход?

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Тестировщики часто задают мне два вопроса:

Как мне продемонстрировать ценность тестирования менеджменту?

Как получить больше времени на тестирование?

Начнем со второго вопроса. Чувствуете ли вы себя очумевшим от объема продукта, который вам надо покрыть, в сравнении с выделенным на это временем? Беспокоитесь ли вы, что вам не хватит времени на поиск значимых проблем?

Автор: Деннис Мартинез (Dennis Martinez)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я наткнулся на твит Бена Доуэна (известного как Full Snack Tester, основателя сайта Tester Of The Day). В твите был опрос:

Как вы относитесь к тест-планам?

- необходимы всегда (21,3%)

- опциональны, но полезны (50%)

- пустая трата времени (15,7%)

- просто покажите мне результаты опроса (13%)

Как правило, я не обращаю внимания на неформальные опросы в Твиттере, потому что выборка там невелика, и результаты не заслуживают доверия. Однако этот опрос меня слегка удивил. Из более чем сотни проголосовавших 70% считает тест-планы важными или полезными, и всего 15% полагает, что это пустая трата времени.

В чем разница между завершением и прекращением тестирования? Как выбрать стратегию тестирования и верно рассчитать трудозатраты? Своими мыслями о разных подходах к управлению тестированием поделится Александр Александров, эксперт по управлению качеством ПО, управлению тестированием, анализу и совершенствованию инженерных процессов Luxoft, кандидат физико-математических наук.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

Схожим образом автоматизированные проверки тоже багов не находят. Баг находит тестировщик, а проверка может сыграть роль в поиске бага.

Тест-инструмент не находит багов. Это делает тестировщик, а инструмент может сыграть роль в нахождении бага.

Автор: Санжит Хохар (SunjeetKhokhar)
Оригинал статьи
Перевод: Ольга Алифанова

По моему опыту, пороки QA и тестирования, как и пороки кода, попадают под четыре больших категории первопричин:

1. Апатия – игнорирование тестирования как функции/ремесла.
2. Гонор – слепые пятна, вызванные талантом или позицией, которые ведут к ошибкам в принятии решений.
3. Невежество – никто не показал, как сделать лучше, или же членам команды не хватает определенного (тестировщицкого) образа мышления.
4. Беспомощность – когнитивное истощение из-за постоянной борьбы с незрелыми практиками разработки или организационной дисфункцией.

Я составил список из цитат и виданных мною "пороков", с которыми я столкнулся в своей карьере тестировщика – включая те, которым поддавался сам!

Дополняйте в комментариях, спасибо заранее.

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

Совсем не весело стартовать рабочий день с открытия, что некоторые (или все) ночные автотесты упали. Это особенно бесит, когда вы выясняете, что они упали, так как кто-то поменял ваши тестовые данные.

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

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

В ходе карьеры мне задавали массу вопросов о тест-архитектуре: как начать тестировать, если ничего не делалось годами? Сколько тест-проектов должно быть? Сколько различных типов тестирования нам нужно? Кто должен отвечать за тестирование в процентном соотношении? Как масштабировать тестирование? Как разобраться с большими приложениями? Как разобраться с существующими тестами, если в них черт ногу сломит? Какими инструментами пользоваться? В каком количестве браузеров надо тестировать (их что, больше двух?!)

Начнем с начала: все приложения уникальны, каждая компания имеет свою структуру, свои ресурсы и бюджет, и все компании находятся на разных стадиях зрелости (это не значит, что они должны стремиться на следующую ступень – возможно, они находятся именно там, где должны). Тут не существует универсальных решений, и поэтому я рекомендую проконсультироваться с экспертом. Но я хочу поделиться своим прошлым опытом на случай, если вам это поможет.

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

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

Меня зовут Мария Снопок, я менеджер направления автоматизации в Отделе тестирования Департамента разработки и сопровождения продуктов больших данных X5 Retail Group. В этой статье я расскажу о нашем опыте внедрения автотестов и сокращении связанных с ними издержек. Надеюсь, эта информация окажется полезной для команд, которые сталкиваются с трудностями при переходе на автоматизированное тестирование.