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

Огромное спасибо всем, кто принял участие в опросе. Также у опроса была первая часть - почти идентичная, но название опроса было: "Как вы отвечаете на эти вопросы на собеседовании?" и отвечали на них тестировщицы и тестировщики разного профессионального уровня. Вот здесь можно увидеть результаты первого опроса.

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

А вот список заданных вопросов (ответы на каждый из них под спойлером).

Что такое тестирование и каковы его цели?
👤
Проверка соответствие продукта предъявляемым к нему требованиям. Требования могут быть как функциональные, так и не функциональные
👤
Комплекс мероприятий направленных на улучшение качества, и восприятия от продукта
👤
Тестирование - процесс сверки ожидаемого результата и фактического, цель - понять текущее состояние проекта, найти и локализовать баги, дать стейкхолдерам инфу, с которой они могут принимать дальнейшие решения.
👤
жду понимания места тестирования в жц разработки. не жду: тестировщики отвественны за качество, цель - найти баги, в пропущенных багах виновато тестирование и тп
👤
Процесс исследования программы с целью определения её уровень качества; определить уровень качества.
👤
В зависимости от условного грейда. От начинающих и мидлов я жду формулировки своими словами, что цель тестирования собрать информацию о продукте и доставить ее заинтересованным лицам, а про тестирование приемлемы разные варианты. И то, что это исследование, и то что это сравнение фактического результата с ожидаемым (но тут я буду разворачивать разговор про то, что такое фактический результат и что такое ожидаемый и откуда мы знаем, что ожидать). Для синьоров и выше я бы хотела услышать про контекст и рассуждение про то, что что в разных условиях тестирование бывает разным и цели его тоже различны. Если кандидат углублялся в это и например может поговорить про школы тестирования или разницу тестирования в Agile и условно функционально-матричной структуре - то это огонь и зашибись. Если может прорефлексировать свою работу в разных местах и сделать выводы - тоже ок. Если кандидат спросит, а что же я думаю по этому поводу и зачем тестирование в моей организации - от меня будет жирный плюс в карму.
👤
Один из процессов обеспечения качества, где мы сверяем полученные результаты тестов с ожидаемыми. Цель - донести до команды и ЛПР информацию об актуальном состоянии продукта
👤
Тестирование это процесс проверки и исследования продукта, в результате которого можно принять решение о его готовности и управлять рисками. Цели у тестирования могут различаться, чтобы их различать придумали делить на виды. Основания для оценки - соответствие явным и неявным требованиям. Результат тестирования должен отвечать на вопросы о том, что работает, что не работает, а также прямо или косвенно показывать ограничения проведённого тестирования.
👤
Проверка соответствия результата спецификациям. Контроль выпуска максимально качественного продукта в установленные сроки.
👤
Тестирование - процесс проверки продукта на предмет соответствия ожидаемого результата и фактического. Дальше уходим в сторону «откуда берётся ожидаемый результат». Из этого блока обсуждений вижу насколько человек понимает жизненный цикл ПО и думает ли он, отвечая, что тестировщики нужны, чтобы обеспечить качество продукта.
👤
Жду осознанного ответа, который покажет, что человек вообще понимает, зачем нужна его работа для команды, бизнеса и компании. Без "задача тестирования все сломать"
Какие виды и уровни тестирования вы знаете?
👤
Unit-тестирование, интеграционное, системное(е2е), приемочное. смоук, регресс, полный регресс(рассказать чем отличается от обычного регресса), функциональное, не функциональное, черный/белый/серый ящики и т.д.
👤
интеграционное, системное, компонентное
👤
Тестирование нового функционала, регресс, смоук, санити. Автоматизированное, мануальное. Функциональное, UI/UX, т-е производительности, нагрузочное, т-е локализации. Юниты, компонентное, интеграционное, e2e тестирование.
👤
стандартную классификацию функц/нефункц, пирамида тестирования (но не задаю этот вопрос никогда)
👤
Функциональное и нефункциональные; нефункциональные - юзабилити, нагрузочное, безопасности, отказоустойчивости, интерфейса, локализации, производительности и др.; юнит, интеграционное, системное; черного, серого, белого ящика; статическое и динамическое; приемочное, регрессионное и др.
👤
Тут мне хватит любой внятной классификации, при этом часть вещей кандидат может забыть и мне будет норм. Тут в зависимости от грейда интереснее будет, что из этого кандидат трогал сам. Я обычно этот вопрос не спрашиваю совсем.
👤
Ожидаю услышать хотя бы основные функциональные виды - смоук, регресс, ретест, тестирование нового функционала. И понимание что это такое и какая между ними разница. Если автоматизатор, то круто было бы услышать про пирамиду, её уровни, какие виды пирамид еще бывают (мороженка, песочные часы и т.д.) и как это применимо в работе.
👤
По уровням я бы разделила на системное, интеграционное и приёмочное, также специфичные для разработчиков юнит-тестирование, профайлинг, кодревью, также есть специфичные для других ролей, например mvp я бы посчитала отдельным уровнем. По видам спрашиваю примерно, но жду не простого перечисления, а связи с целями. Один и тот же вид может быть функциональным и нефункциональным в зависимости именно от цели и продукта (например тестирование безопасности). В общем я не жду полного совпадения с моими представлениями, мне важнее что у кандидата сформирована целостная связанная картина и он понимает что это, зачем, чем это ему поможет в работе, а если ищется middle+, то какие проблемы решает разделение на виды и уровни.
👤
тк их 100500 и голосом это описывать дело весьма неблагодарное, достаточно структурированного начала рассказа типа функциональное/нефункциональное, белого/черно/серого ящика, позитивное/негативное и пр - дальше можно задавать вопросы на понимание
👤
Все никогда не прошу рассказать, говорим о тех, что человек вспоминает. Обычно это смоук, регресс, пирамида, нагрузочное, стресс, ящики. На самом деле, что бы человек ни сказал, я попрошу рассказать подробнее, иногда даю пример и прошу сказать смоук-тест. И куда важнее, если человек назовёт 4-5 видов, но объяснит каждый из них, чем если назовёт 15, но не расскажет что они из себя представляют.
👤
Жду не заученных терминов, а понимания, что есть разные подходы и задачи, и что в разных случаях мы применяем разные виды и уровни. То есть в целом жду умения поддержать разговор.
Какие виды тестовой документации вы знаете?
👤
чек-лист, тест-кейсы, тест-сьюты, баг-репорт, план тестирования
👤
тест-план, тестовая стратегия, тест-кейсы, чек-листы, баг-репорт (если он к документации относится)
👤
Тест-кейсы, чек-листы, тест-планы, тестовая стратегия. Просто мануалы, ноу-хау. Доки по бизнес-логике, апишкам, майнд карты - всё, что облегчает понимание и тестирование.
👤
спрашиваю, с чем работали, жду ответа о практическом опыте. если ни с чем, то жду понимания разницы применимости тк и чл, знания о существовании верхнеуровневой документации
👤
тест-план, тест-кейсы, known issues / ограничения
👤
От джунов я жду рассказа в основном про тест-кейсы и чек-листы. От мидлов и выше я жду разговора о контексте - про уместность применения тех же тест-кейсов и чек-листов, про формат отчетов о тестировании (и их необходимости), про тестовую стратегию (от мидлов что она бывает, от синьоров и выше - какая она бывает и что там может быть)
👤
Документирование тестов: тест-кейсы, чек-листы; документирование багов - баг-репорты; документирование результатов тестирования - отчеты о тестировании; документирование планов на тестирование - тест-план, тестовая стратегия
👤
Тестирование производится по чек-листам, тест-кейсам. Документами также являются отчёты о тестировании, постановка задачи, тест-план, план приёмки, который может быть в виде чек-листа или тест-кейсов, но отличается по содержанию целью. В тестировании участвует и другая документация - источники требований.
👤
тест-кейсы, чек-листы, тест-планы, инструкции - вообще больше интересно умение выбирать документацию под нужды проекта
👤
Чек-лист, тест-кейс, баг-репорт, сценарий, тест-план. Этот вопрос не задаю, слишком лёгкий
👤
Для начала - понимания, что это вообще такое, зачем надо, и как применяется. Конечно же, нужна база в виде тк, чек-листов, баг-репортов и прочего, но и понимания, какие правила составления и тд. Тут сильно зависит от грейда.
Какие техники тест-дизайна вы знаете?
👤
Классы эквивалентности, доменный анализ, попарное тестирование, граничные значения
👤
граничных значений, исследовательское, эквивалентное
👤
Граничные значения, классы эквивалентности, диаграмма переходов состояний, таблицы принятия решений, pairwise. Наверное с натяжкой можно и "туры тестирования" сюда отнести.
👤
жду ответов из практики, минимум: кэ и гз, в идеале переходы-состояния и табл принятия решений. всегда даю практическую задачу на тд
👤
классы эквивалентности, граничные значение, попарное тестирование, тестирование по ГПУ, исследовательское
👤
От джунов хвататит уверенного владения граничными значениями и классами эквивалентности (проверяю обычно на простой задачке), про остальное норм просто знать что это бывает - попарное тестирование, таблицы решений, диаграммы состояний и переходов. От мидлов хочу разговоров о том, что и как они применяли в своей работе. Отлично если поговорят об эвристиках. От синьоров и выше хочу рефлексии о том, что методы тест-дизайна не Священный Грааль, ограничениях и границах применимости.
👤
Классы эквивалентности, граничные значения, диаграмма состояний и переходов, попарное тестирование, причина-следствие и т.д. - если собеседуемый опытный тестировщик, то круто, если расскажет как применял техники в работе, в каких ситуациях и почему именно их.
👤
Разделение сущностей на классы эквивалентности. Анализ граничных значений. Тестирование на основе юзкейсов. Анализ переходов состояний. Pairwise и таблица принятия решений. Мнемоники и эвристики кроме вышеперечисленных хотя бы с одним примером
👤
ГЗ, КЭ, как минимум, далее матрицы связности, pairwise как минимум и умение их применять (потому что это оказывается не так очевидно)
👤
Граничные значения, классы эквивалентности, попарное тестирование. Этого мне хватает, т.к. дальше увожу разговор в более подробный рассказ о каждом из видов (точнее о первых двух, т.к. по ним уже всё понятно становится). Главное, что хочу услышать - зачем каждая из техник нужна Обычно их практическое применение проверяется у нас чуть позже не небольшой задачке для тестирования
👤
Опять же, важно не только знание техник, но и понимание, когда они используются, как, и когда нет. Это в целом боль)

© 2021 YU-GO.RU