[Из песочницы] Каких ответов я жду на собеседовании по тестированию
Я провожу собеседования на тестировщиков. У меня иногда болит голова.Долго собирался написать статью… И вот, наконец, выполнил свое намерение. Вопросы, поднимаемые в статье, обсуждались уже не раз и не два, но усердные поиски компиляции ответов на эти вопросы так и не увенчались успехом. Но, как подсказывает мой опыт, такая компиляция очень нужна. Прежде всего она требуется юниорам, ибо в сети по запросу «тестирование» на них (соискателей) обрушивается огромный объем информационного мусора, который плохо структурирован и часто противоречит сам себе.
Сначала несколько слов о себе. На данный момент являюсь начальником отдела тестирования и сопровождения компании, занимающейся корпоративными ГИС. До этого работал руководителем группы тестирования в компании, разрабатывающей коммерческие СДО (Системы дистанционного обучения). А еще раньше ведущим инженером по тестированию в компании, которая обеспечивала электронные торги по ФЗ №94. А начинал я свою карьеру более 11 лет назад в роли системного администратора (в трех различных организациях). Стажером-программистом был чуть меньше двух лет (вначале нулевых — VB). Фрилансил инженером-программистом: писал собственный баг-трекер для госкомпании… Исходя из сказанного, можно утверждать, что определенный опыт (тестирования — суммарно более 5 лет) наработан…Кроме того, по долгу службы мне постоянно приходится подбирать сотрудников в отдел тестирования. И чем больше я этим занимаюсь, тем больше убеждаюсь, что иногда проще взять претендента без опыта, чем человека с опытом тестирования в российской компании (впрочем, не без исключений). Попутно следует отметить, что соискатели без опыта в подавляющей массе используют следующие источники информации о профессии: интернет — ресурсы, книги, мнение знакомых тестировщиков.
На собеседовании я всегда задаю одни и те же вопросы:
Почему вы решили стать тестировщиком? Что такое тестирование? В чем его суть как процесса? Что такое ошибка? В чем цель тестирования? Что вы знаете о жизненном цикле ПО? Какие бывают требования? Какие виды/типы/классы/методы тестирования вы знаете, и чем они различаются? Расскажите о тестовой документации: виды, цели. Из каких этапов состоит процесс тестирования? Автоматизированное тестирование — отдельный вид тестирования? Какой тип/вид класс тестирования имеет смысл автоматизировать? Соискатель, который доходит за полтора часа беседы до восьмого вопроса, — редкость, такого я возьму на работу юниором. Доходящий за то же время до 11 вопроса может быть принят на должность ведущего тестировщика, однако за 240 проведенных собеседований таких оказалось только 5 человек! Может, я слишком требователен к ответам? Нет, я просто жду от соискателя понимания того, чем ему придется заниматься. Вот как проходит собеседование: я начинаю разговаривать с соискателем предпочтительно в форме диалога, задавая ему указанные вопросы. Если получаю ответ, правильный или близкий к правильному, то перехожу к следующему вопросу. Если соискатель «блуждает», приводит заученную формулировку или просто не может ее обосновать, я пытаюсь подвести его к правильному ответу и почему этот ответ правильный. Пытаюсь заставить рассуждать. Последний год вместо собеседований у меня получаются импровизированные лекции. И дело не только в том, что соискатели менее осведомлены или у них мало опыта. Имели место и собеседования на должность ведущего инженера по тестированию с претендентами с 10 летним опытом… результат почти всегда удручает. По-моему, дело в том, что очень много противоречивой информации и «неполезного» опыта, ведь очень многие российские компании строят процесс тестирования по модели С. Канера — когда два — три высококвалифицированных тестировщика полностью генерируют, отбирают и описывают кейсы, а проверки проводят 10 -15,100, 500+ «тестеров» не особо вникая в саму суть процесса.
Этим текстом я попытаюсь немного подвести вчерашних, сегодняшних и завтрашних соискателей на позицию тестировщика к пониманию, а что же все-таки такое «тестирование». Далее я отвечу на некоторые из вопросов собеседования и обосную свое мнение, а также приведу некоторые из наиболее частых ответов соискателей и объясню, почему считаю их неправильными.
Наиболее частый ответ: «потому что это просто и интересно (!)». Т. е. кандидат считает, что ему будут платить деньги за щелканье мышкой в вк… Или дадут софт и скажут — сломай его… Или он просто не готовился к этому вопросу и имеет весьма слабое представление о профессии.Второй по частоте ответ: «потому что я хочу работать в IT и тестирование — самый простой путь» (читай: у IT специалистов высокая зп, а в тестировании не нужно ни знаний, ни навыков, но зп тоже достаточно высокая!).
Бывали и ответы: «меня мама/муж/жена заставила идти на собеседование».
Единственно правильного ответа нет, но вот указанные три и их производные — точно неправильные, т. к. тестирование — это сложно и однообразно, оно требует определенных навыков, по которым нет учебников, и ведет к профессиональной деформации мировоззрения.
Что бы я хотел услышать? Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».
Наиболее частый ответ (напрямую прописан у С. Канера и Р.Савина) — «поиск ошибок». И во всей литературе по тестированию почему-то никто не указывает, что это упрощение и весьма грубое, и вообще, этот ответ просто неверен! Тестирование — комплекс мероприятий, направленный на проведение проверок на соответствие производимого продукта требованиям, к нему предъявляемым (прямым и косвенным).
Да, действительно, в ходе проверок выявляются ошибки/инциденты/замечания, но это лишь побочный продукт процесса. Основным является информация о соответствии продукта требованиям, которые к нему предъявляются.
Ну, здесь, слава Богу, почти все отвечают: «некорректная работа программы…». А вот дальше начинается хаос, когда спрашиваешь: «а как мы узнаем корректная работа или нет? «Правильный ответ есть почти на всех известных мне ресурсах о тестировании: Ошибка — несоответствие производимого продукта требованиям, прямым или косвенным.Чтобы не блуждать в противоречиях/предположениях и т. п., — это единственно правильный ответ.
Здесь люди начинают повторять ответ на второй вопрос с разными вариациями. Наиболее внимательные соискатели пытаются пересказать то, что я им подсказывал при ответе на второй вопрос. А ответ крайне простой: Цель тестирования — предоставление актуальной информации о соответствии производимого продукта требованиям.
Всё. Не больше и не меньше. Ну, конечно же, можно еще сказать, что цель тестирования — предоставление информации о количестве ошибок в продукте. А именно это и неправильно. Почему? Вот просто-таки каждодневный кейс многих тестировщиков/ПМ/аналитиков: звонок заказчика — «как там мой продукт?». «Вы знаете, в нем еще 60 багов!» — ответ тестировщика/ПМ… И что дальше? Это много? Мало? Нормально? Можно, конечно, рассказать подробно о критичности этих багов, их приоритетах, но это не ответ на вопрос заказчика, это выдача сырой необработанной информации ДВП. Теперь тот же кейс. «Как там мой продукт?», — спрашивает заказчик.»35% процентов требований реализовано полностью, еще 5% — с замечаниями и еще 2% — сейчас в реализации», — отвечает ПМ/тестировщик. Как Вам кажется, такой ответ понятнее? И пусть в эти 5% входят, уже упомянутые 60 багов-замечаний… Ответ на вопрос дан настолько точный, насколько это вообще возможно в данном формате. Вот именно это и является целью тестирования. А, соответственно, и сам процесс по своей сути должен сводиться к достижению этой цели.
Про ЖЦ ПО сказано много, да и он сильно зависит от организации процесса реализации в целом. Все же есть некоторая «золотая середина», но и здесь умудряются фантазировать дикие вещи, то сводя все к трем пунктам, то разрисовывая схему на три страницы… Всем, кто проводил/проходил собеседование, и так ясно, какие ошибки совершаются и сколько вариантов у правильных ответов. Останавливаться подробнее не буду, скажу только, что есть целый пул кандидатов, которые намертво стопорились на этом вопросе (примерно 7%). До этого вопроса за полтора часа доходят только процентов 50 соискателей… Хотя я и не требую ответов «буква в букву», главное, как это называют юристы, сохранить «дух».Самый частый кейс: соискатели начинают перечислять виды технической документации, которые они знают или о которых слышали… Обязательно выслушаю, покиваю и спрошу: «что-нибудь еще?». Редко кто вспоминает про деление на «функциональные»/«нефункциональные», а кто вспоминает, часто не может объяснить разницу.
Но есть одна категория, про которую забывают. Я в этой статье уже несколько раз упоминал о »…требованиях прямых и косвенных…». На собеседовании я эту фразу произношу раз пять-шесть. Очень малый процент соискателей переспрашивает и тем самым исключает этот вопрос из собеседования. А полный ответ таков: «Требования бывают прямыми (т. е. формализованными в технической документации, спеках, юзер-стори и прочих формальных артефактах) и косвенными (т. е. проистекающими из прямых, либо являющимися негласным стандартом для данной продукции или основывающиеся на опыте и здравом смысле использования данного продукта или продуктах, подобных ему). Все требования также подразделяются на функциональные (описывающие какие функции должен выполнять продукт) и нефункциональные (требования к окружению, поддерживаемости, надежности и прочим характеристикам продукта). Прямые требования всегда приоритетнее косвенных.»
Самый очевидный и «простой» пример: в ТЗ — «кнопка должна быть красного цвета» — прямое требование, из него проистекают косвенные — она не должна быть синей, зеленой, серой или черной и т. д… Естественно, это сильное упрощение, но очень показательное. А главное — такой подход отсекает излишне формальное отношение к тестированию и поднимает планку квалификации тестирования как такового, ибо для грамотного тестирования мало знать только ТЗ и юзер-стори, надо еще изучить прикладную область и специфику потребления производимого продукта. Такое тестирование значительно эффективнее.
Есть маленький грех за мной: я отрицаю существование негативных проверок, поскольку:
их тяжело обосновать перед руководством, на них трудно получить время, их практически невозможно обосновать экономически перед заказчиком при составлении сметы на тестирование. Опираясь на концепцию косвенных требований этого делать не надо, т. к. все проверки становятся позитивными, но часть из них — на соответствие прямым требованиям, часть — на соответствие косвенным. И квалификация специалиста как раз и выявляется пониманием косвенных требований для каждого конкретного продукта. О классификации тестирования имеется очень много информации, вариантов правильных ответов тоже очень много. Я задаю этот вопрос, чтобы увидеть, готовился соискатель хоть в малой степени или вообще не удосужился. Дело в том, что на предыдущие вопросы можно ответить, просто рассуждая и имея общее представление о сфере в целом. Данный вопрос требует элементарного знания терминов. Возможно, я рассмотрю его в других статьях, ибо он достаточно большой и заслуживает отдельной статьи. Тестовая документация — пожалуй, самая большая проблема. По ней идут такие битвы в сообществах, фирмах и т. д.! Про нее столько противоречивой информации. О ней изданы многотомники на разных языках. О ней такая каша в головах… Каких только ответов не приходилось слышать (да-да, включая ТЗ и проектное решение — это тоже тестовая документация)… Поэтому выскажу свои мысли по этому поводу.Тестовая документация бывает двух видов: внешняя и внутренняя. И та, и другая — инструмент, облегчающий жизнь проектной команде. Не более и не менее.
Внешняя документация:
Замечание — короткая записка, комментарий о небольшой неточности в реализации продукта. Баг-репорт — описание выявленного случая несоответствия производимого продукта требованиям, к нему выдвигаемым — ошибки или ее проявления. Он обязательно должен содержать следующие элементы: Идею тестового случая, вызвавшего ошибку. Описание исходного состояния системы для выполнения кейса. Шаги, необходимые для того, чтобы выявить ошибку или ее проявление. Ожидаемый результат, т. е. то, что должно было произойти в соответствии с требованиями. Фактический результат, т. е. то, что произошло на самом деле. Входные данные, которые использовались во время воспроизведения кейса. Прочую информацию, без которой повторить кейс не получится. Критичность и/или приоритет. Экранный снимок (скрин). Версию, сборку, ресурс и другие данные об окружении. Запрос на изменение (улучшение) — описание неявных/некритичных косвенных требований, которые не были учтены при планировании/реализации продукта, но несоблюдение, которых может вызвать неприятие у конечного потребителя. И пути/рекомендации по модификации продукта для соответствия им. Отчет о тестировании (тест репорт) — документ, предоставляющий сведения о соответствии/ несоответствии продукта требованиям. Может так же содержать описание некоторых подробностей проведенной сессии тестирования, например, затраченное время, использованные виды тестирования, перечень проверенных случаев и т. п. В идеальном варианте фраза вида «Тест пройден. Ошибка не воспроизводится/Функционал работает корректно/Соответствует требованиям» означает, что продукт или его часть полностью соответствует требованиям прямым и косвенным (в производстве ПО). Внутренняя документация: Тест-план (план тестирования) — формализованное и укрупненное описание одной сессии тестирования по одному или нескольким направлениям проверок. Т.е. перечень направлений проверок, которые должны быть проведены в рамках сессии тестирования (и, сообразных этим направлениям, требований). Также может содержать в себе необходимую информацию об окружении, методике, прочих условиях важных для показательности данной сессии тестирования. Под направлением проверок также может пониматься более детализированная тестовая документация (в виде ссылки на нее): чек листы, тестовые комплекты, тестовые сценарии, на которую необходимо опираться при проведении сессии тестирования. Основная цель документа — описать границы сессии тестирования, стабилизировать показательность данной сессии. Тестовый сценарий — последовательность действий над продуктом, которые связаны единым ограниченным бизнес-процессом использования, и сообразных им проверок корректности поведения продукта в ходе этих действий. Может содержать информацию об исходном состоянии продукта для запуска сценария, входных данных и прочие сведения, имеющие определяющее значение для успешного и показательного проведения проверок по сценарию. Особенностью является линейность действий и проверок, т.е. зависимость последующих действий и проверок от успешности предыдущих. Цель документа — стабилизация покрытия аспектов продукта, необходимых для выполнения функциональной задачи, показательными необходимыми и достаточными проверками. Фактически при успешном прохождении всего тестового сценария мы можем сделать заключение о том, что продукт может выполнять ту или иную возложенную на него функцию. Тестовый комплект — некоторый набор формализованных тестовых случаев объединенных между собой по общему логическому признаку. Чек-лист (лист проверок) — перечень формализованных тестовых случаев в виде удобном для проведения проверок. Тестовые случаи в чек-листе не должны быть зависимыми друг от друга. Обязательно должен содержать в себе информацию о: идеях проверок, наборах входных данных, ожидаемых результатах, булевую отметку о прохождении/непрохождении тестового случая, булевую отметку о совпадении/несовпадении фактического и ожидаемого результата по каждой проверке. Может так же содержать шаги для проведения проверки, данные об особенностях окружения и прочую информацию необходимую для проведения проверок. Цель — обеспечить стабильность покрытия требований проверками необходимыми и достаточными для заключения о соответствии им продукта. Особенностью является то, что чек-листы компонуются теми тестовыми случаями, которые показательны для определенного требования. Тестовый случай (тест-кейс) — формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным. Обязательно должен содержать следующую информацию: Идея проверки. Описание проверяемого требования или проверяемой части требования. Используемое для проверки тестовое окружение. Исходное состояние продукта перед началом проверки. Шаги для приведения продукта в состояние, подлежащее проверке. Входные данные для использования при воспроизведении шагов. Ожидаемый результат. Прочую информацию, необходимую для проведения проверки. Цель — зафиксировать сгенерированную и отобранную показательную проверку в виде, позволяющем тестировщику любой квалификации ее провести и суметь проанализировать полученные результаты.Как видно, каждый последующий вид внутренней тестовой документации в определенной мере детализирует предыдущий. У каждого документа есть свое назначение и все вместе они — инструмент для облегчения генерации, отбора и воспроизведения тестовых случаев. Кроме того хорошо структурированная, поддерживаемая, читаемая, организованная и доступная тестовая документация позволяет в долгосрочной перспективе:
Обеспечить стабильность покрытия требований проверками. Обеспечить показательность всех проводимых проверок. Обеспечить необходимость и достаточность проводимых проверок. Сэкономить время на этапах тестирования, сводя их к проведению проверок и анализу и передаче результатов. Снизить входной уровень квалификации тестировщика для проведения проверок. Повысить прогнозируемость сессий тестирования в части затрат времени и ресурсов. Повысить прозрачность процесса тестирования для других участников процесса производства продукта. Обеспечить базу знаний о продукте и истории его развития. Но следует учитывать, что есть и свои недостатки: Стабильность покрытия. Со стремящейся к бесконечности долей вероятности, если проводится тестирование по документации, то будут проведены только те проверки, которые есть в данной документации. Вероятность пропуска ошибки (чаще всего несоответствие косвенному требованию, непокрытому документацией) возрастает. Плохая локализация ошибки тестировщиком. Либо полное отсутствие локализации. Фактический результат не совпал с ожидаемым — ошибка. А что это на самом деле: ошибка; проявление ошибки; инцидент, уже описанной ошибки, тестировщик не проверит (в подавляющем количестве случаев). Высокий требуемый уровень квалификации специалиста для создания и поддержания тестовой документации. Большие временные затраты на создание и поддержание тестовой документации. Слабо прогнозируемое время актуальности тестовой документации. Списки как плюсов так минусов можно продолжать, я указал только те, которые лежат на поверхности. Но понимание хотя бы этого списка крайне важно для нынешнего или будущего специалиста по тестированию. Вопрос, касающийся тестовой документации, преодолевает очень малый процент соискателей.Естественно, видов документации в тестировании гораздо больше, но без понимания назначения и особенностей этих документов работать в этой профессии очень сложно. И чтобы совсем не увеличивать размеры статьи, рассмотрим последний (для этой статьи) вопрос.
Чаще всего отвечают приблизительно так: «подготовка, тестирование, отчет…» Так-то оно так, только абсолютно любой процесс состоит из этих этапов. И ответ никак не отражает понимание соискателем процессов тестирования. Больше похоже на читерство… Поэтому позволю себе изложение своего видения: инициация, выявление требований прямых и косвенных, генерация тестовых случаев, отбор показательных тестовых случаев, проведение проверок, фиксация результатов, анализ результатов, передача информации о соответствии проверенного продукта требованиям. Более подробная информация об указанных этапах: Инициация — событие, которое извещает команду тестирования о необходимости сессии тестирования, а также гарантирует выполнение требований к продукту для проведения тестирования.
Для производства ПО требования включают:
доступно необходимое тестовое окружение, доступен билд/ресурс/предмет тестирования, код, БД, прочие компоненты объекта тестирования «заморожены», т. е. не изменяются в период всей сессии тестирования, модификация требований (хотя бы прямых) «заморожена», известно направление тестирования, известны сроки на сессию тестирования. Есть и другие условия, но они менее значимы и сильно зависят от конкретного процесса в компании.Выявление требований — пожалуй, один из главных шагов в процессе тестирования. Неизвестны требования — нет тестирования. Необходимо собрать всю доступную информацию о предмете тестирования, вариантах использования и т. п. Первый источник — техническая документация и юзер-стори — это прямые требования. Качество же косвенных требований во многом зависят от добросовестности, ответственности, квалификации тестировщика и всей команды проекта.
Генерация тестовых случаев — выявление всех возможных случаев использования продукта, его характеристик и особенностей в процессе эксплуатации. Это значит: всех случаев, которые тестировщик может «придумать» на основе прямых и косвенных требований, известных ему. Этот этап требует высокой квалификации специалиста по тестированию.
Отбор тестовых случаев — отбор наиболее показательных, значимых и воспроизводимых тестовых случаев. От этого этапа зависит, насколько тестирование будет полезным, эффективным и анализируемым. Например, в «простом» примере с красной кнопкой понятно, что количество косвенных требований стремится к бесконечности, и проверять их все подряд — полный абсурд, но подобные кейсы должны быть сгенерированы хотя бы в голове проверяющего. А для того чтобы они не вошли в проверки, необходимо выполнить соответствующий отбор и проверить только, действительно ли кнопка красная.
Пример примитивный, но после его озвучивания соискатели перестают первым делом пытаться налить в стакан радий на тестовом задании J (кто принимал участие в собеседовании на должность тестировщика, тот знает это нехитрое задание на генерацию и отбор тестовых случаев).
Проведение проверок — тут все понятно. Либо согласно документации, либо ad hoc (интуитивно, свободный поиск, без документации). В любом случае это проводится согласно списку отобранных проверок. Почему-то большинство именно этот пункт называет тестированием. И в голове обывателя, незнакомого с профессией, только один этот пункт и содержится J.
Фиксация результатов — создание внутренней и внешней тестовой документации в формализованном виде или в виде записей и т. п. На данном этапе отчет о тестирование даже если и создается, то не считается законченным.
Анализ результатов — вынесение решения о соответствии проверенного продукта требованиям. Формализация данного решения и его обоснование в виде отчета о тестировании. Сюда также входят процедуры по оценке покрытия требований проверками, тайм-шитинг и пр. Таким образом, проводится анализ не только результатов, но и самой сессии тестирования.
Передача информации о соответствии продукта требованиям. Формально: передача внешней тестовой документации заинтересованным в ней сторонам, зачастую инициатору сессии тестирования. В общем случае: помимо документации предоставляется информация о рисках, которые были выявлены в продукте, требованиях, процессах, передаются рекомендации по отработке этих рисков и т. п. Но это — уже QA J!
Внимательный читатель заметил, что вопросы набирают сложность от начала к концу беседы. Вместе с тем, стоит отметить, что все эти вопросы не должны затруднить специалистов по тестированию, то есть тех, кто не «просто кликал мышью — тестировал», а пытался разобраться в сути того, чем он занимается, тех, кто не остановился на одной книжке или одном ресурсе, а продумал и обосновал свои действия… хотя бы для самого себя.На этом я завершаю данную статью. Если уважаемый читатель найдет предмет для дискуссии в моих утверждениях, буду рад в ней поучаствовать. Если появятся вопросы, то они станут темами для будущих статей. Всегда рад конструктивной критике. В любом случае пишите мне. Если к статье будет проявлен интерес, то продолжу разбор собеседований, а, возможно, попробую осветить и другие аспекты профессии, о которой слышали почти все, но мало тех, кто знает ее изнутри.
