Home

Автор: Майкл Болтон (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. В этой статье я расскажу о нашем опыте внедрения автотестов и сокращении связанных с ними издержек. Надеюсь, эта информация окажется полезной для команд, которые сталкиваются с трудностями при переходе на автоматизированное тестирование.

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

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

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

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

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

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

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

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