Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: Саймон Найт (Simon Knight)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Но как же вы попали в эту область системы? Каким маршрутом вы шли, что вы могли упустить по дороге?

Что, если вместо того, чтобы прямой наводкой идти к этой области, вы бы свернули в совершенно ином направлении?

Что вы могли бы найти?

Автор: Рози Шерри (Rosie Sherry)
Оригинал статьи
Перевод: Ольга Алифанова

Вам когда-нибудь ставили задачу распланировать ваше тестирование? Чувствовали ли вы, что что-то упустили? И вследствие этого беспокоились ли, что ПО начнет падать, и все начнут обвинять вас?

Использование этого чеклиста по планированию тестирования поможет вам справиться с волнением.

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

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

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

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

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