Каких ответов я жду на собеседовании по тестированию

Я провожу собеседования на тестировщиков. У меня иногда болит голова.

Долго собирался написать статью… И вот, наконец, выполнил свое намерение. Вопросы, поднимаемые в статье, обсуждались уже не раз и не два, но усердные поиски компиляции ответов на эти вопросы так и не увенчались успехом. Но, как подсказывает мой опыт, такая компиляция очень нужна. Прежде всего она требуется юниорам, ибо в сети по запросу «тестирование» на них (соискателей) обрушивается огромный объем информационного мусора, который плохо структурирован и часто противоречит сам себе.

Вступление


Сначала несколько слов о себе. На данный момент являюсь начальником отдела тестирования и сопровождения компании, занимающейся корпоративными ГИС. До этого работал руководителем группы тестирования в компании, разрабатывающей коммерческие СДО (Системы дистанционного обучения). А еще раньше ведущим инженером по тестированию в компании, которая обеспечивала электронные торги по ФЗ №94. А начинал я свою карьеру более 11 лет назад в роли системного администратора (в трех различных организациях). Стажером-программистом был чуть меньше двух лет (вначале нулевых – VB). Фрилансил инженером-программистом: писал собственный баг-трекер для госкомпании… Исходя из сказанного, можно утверждать, что определенный опыт (тестирования — суммарно более 5 лет) наработан…

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

На собеседовании я всегда задаю одни и те же вопросы:
  1. Почему вы решили стать тестировщиком?
  2. Что такое тестирование? В чем его суть как процесса?
  3. Что такое ошибка?
  4. В чем цель тестирования?
  5. Что вы знаете о жизненном цикле ПО?
  6. Какие бывают требования?
  7. Какие виды/типы/классы/методы тестирования вы знаете, и чем они различаются?
  8. Расскажите о тестовой документации: виды, цели.
  9. Из каких этапов состоит процесс тестирования?
  10. Автоматизированное тестирование – отдельный вид тестирования?
  11. Какой тип/вид класс тестирования имеет смысл автоматизировать?

Соискатель, который доходит за полтора часа беседы до восьмого вопроса, – редкость, такого я возьму на работу юниором. Доходящий за то же время до 11 вопроса может быть принят на должность ведущего тестировщика, однако за 240 проведенных собеседований таких оказалось только 5 человек!

Может, я слишком требователен к ответам? Нет, я просто жду от соискателя понимания того, чем ему придется заниматься. Вот как проходит собеседование: я начинаю разговаривать с соискателем предпочтительно в форме диалога, задавая ему указанные вопросы. Если получаю ответ, правильный или близкий к правильному, то перехожу к следующему вопросу. Если соискатель «блуждает», приводит заученную формулировку или просто не может ее обосновать, я пытаюсь подвести его к правильному ответу и почему этот ответ правильный. Пытаюсь заставить рассуждать. Последний год вместо собеседований у меня получаются импровизированные лекции. И дело не только в том, что соискатели менее осведомлены или у них мало опыта. Имели место и собеседования на должность ведущего инженера по тестированию с претендентами с 10 летним опытом… результат почти всегда удручает. По-моему, дело в том, что очень много противоречивой информации и «неполезного» опыта, ведь очень многие российские компании строят процесс тестирования по модели С. Канера – когда два – три высококвалифицированных тестировщика полностью генерируют, отбирают и описывают кейсы, а проверки проводят 10 -15,100, 500+ «тестеров» не особо вникая в саму суть процесса.

Этим текстом я попытаюсь немного подвести вчерашних, сегодняшних и завтрашних соискателей на позицию тестировщика к пониманию, а что же все-таки такое «тестирование». Далее я отвечу на некоторые из вопросов собеседования и обосную свое мнение, а также приведу некоторые из наиболее частых ответов соискателей и объясню, почему считаю их неправильными.

Почему вы решили стать тестировщиком?


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

Второй по частоте ответ: «потому что я хочу работать в IT и тестирование – самый простой путь» (читай: у IT специалистов высокая зп, а в тестировании не нужно ни знаний, ни навыков, но зп тоже достаточно высокая!).

Бывали и ответы: «меня мама/муж/жена заставила идти на собеседование».

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

Что бы я хотел услышать? Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».

Что такое тестирование? В чем его суть как процесса?


Наиболее частый ответ (напрямую прописан у С. Канера и Р.Савина) – «поиск ошибок». И во всей литературе по тестированию почему-то никто не указывает, что это упрощение и весьма грубое, и вообще, этот ответ просто неверен!

Тестирование – комплекс мероприятий, направленный на проведение проверок на соответствие производимого продукта требованиям, к нему предъявляемым (прямым и косвенным).

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

Что такое ошибка?


Ну, здесь, слава Богу, почти все отвечают: «некорректная работа программы…». А вот дальше начинается хаос, когда спрашиваешь: «а как мы узнаем корректная работа или нет?»

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

В чем цель тестирования?


Здесь люди начинают повторять ответ на второй вопрос с разными вариациями. Наиболее внимательные соискатели пытаются пересказать то, что я им подсказывал при ответе на второй вопрос. А ответ крайне простой:

Цель тестирования – предоставление актуальной информации о соответствии производимого продукта требованиям.

Всё. Не больше и не меньше. Ну, конечно же, можно еще сказать, что цель тестирования – предоставление информации о количестве ошибок в продукте. А именно это и неправильно. Почему? Вот просто-таки каждодневный кейс многих тестировщиков/ПМ/аналитиков: звонок заказчика – «как там мой продукт?». «Вы знаете, в нем еще 60 багов!» – ответ тестировщика/ПМ… И что дальше? Это много? Мало? Нормально? Можно, конечно, рассказать подробно о критичности этих багов, их приоритетах, но это не ответ на вопрос заказчика, это выдача сырой необработанной информации ДВП. Теперь тот же кейс. «Как там мой продукт?», – спрашивает заказчик. «35% процентов требований реализовано полностью, еще 5% – с замечаниями и еще 2% – сейчас в реализации», – отвечает ПМ/тестировщик. Как Вам кажется, такой ответ понятнее? И пусть в эти 5% входят, уже упомянутые 60 багов-замечаний… Ответ на вопрос дан настолько точный, насколько это вообще возможно в данном формате. Вот именно это и является целью тестирования. А, соответственно, и сам процесс по своей сути должен сводиться к достижению этой цели.

Что вы знаете о жизненном цикле ПО?


Про ЖЦ ПО сказано много, да и он сильно зависит от организации процесса реализации в целом. Все же есть некоторая «золотая середина», но и здесь умудряются фантазировать дикие вещи, то сводя все к трем пунктам, то разрисовывая схему на три страницы… Всем, кто проводил/проходил собеседование, и так ясно, какие ошибки совершаются и сколько вариантов у правильных ответов. Останавливаться подробнее не буду, скажу только, что есть целый пул кандидатов, которые намертво стопорились на этом вопросе (примерно 7%).

Какие бывают требования?


До этого вопроса за полтора часа доходят только процентов 50 соискателей… Хотя я и не требую ответов «буква в букву», главное, как это называют юристы, сохранить «дух».

Самый частый кейс: соискатели начинают перечислять виды технической документации, которые они знают или о которых слышали… Обязательно выслушаю, покиваю и спрошу: «что-нибудь еще?». Редко кто вспоминает про деление на «функциональные»/«нефункциональные», а кто вспоминает, часто не может объяснить разницу.

Но есть одна категория, про которую забывают. Я в этой статье уже несколько раз упоминал о «…требованиях прямых и косвенных…». На собеседовании я эту фразу произношу раз пять-шесть. Очень малый процент соискателей переспрашивает и тем самым исключает этот вопрос из собеседования. А полный ответ таков: «Требования бывают прямыми (т. е. формализованными в технической документации, спеках, юзер-стори и прочих формальных артефактах) и косвенными (т. е. проистекающими из прямых, либо являющимися негласным стандартом для данной продукции или основывающиеся на опыте и здравом смысле использования данного продукта или продуктах, подобных ему). Все требования также подразделяются на функциональные (описывающие какие функции должен выполнять продукт) и нефункциональные (требования к окружению, поддерживаемости, надежности и прочим характеристикам продукта). Прямые требования всегда приоритетнее косвенных.»

Самый очевидный и «простой» пример: в ТЗ — «кнопка должна быть красного цвета» – прямое требование, из него проистекают косвенные – она не должна быть синей, зеленой, серой или черной и т. д… Естественно, это сильное упрощение, но очень показательное. А главное – такой подход отсекает излишне формальное отношение к тестированию и поднимает планку квалификации тестирования как такового, ибо для грамотного тестирования мало знать только ТЗ и юзер-стори, надо еще изучить прикладную область и специфику потребления производимого продукта. Такое тестирование значительно эффективнее.

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

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

Какие виды/типы/классы/методы тестирования вы знаете, и чем они различаются?


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

Расскажите о тестовой документации: виды, цели.


Тестовая документация – пожалуй, самая большая проблема. По ней идут такие битвы в сообществах, фирмах и т. д.! Про нее столько противоречивой информации. О ней изданы многотомники на разных языках. О ней такая каша в головах… Каких только ответов не приходилось слышать (да-да, включая ТЗ и проектное решение – это тоже тестовая документация)… Поэтому выскажу свои мысли по этому поводу.

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

Внешняя документация:
  • Замечание – короткая записка, комментарий о небольшой неточности в реализации продукта.
  • Баг-репорт – описание выявленного случая несоответствия производимого продукта требованиям, к нему выдвигаемым – ошибки или ее проявления. Он обязательно должен содержать следующие элементы:
    • Идею тестового случая, вызвавшего ошибку.
    • Описание исходного состояния системы для выполнения кейса.
    • Шаги, необходимые для того, чтобы выявить ошибку или ее проявление.
    • Ожидаемый результат, т. е. то, что должно было произойти в соответствии с требованиями.
    • Фактический результат, т. е. то, что произошло на самом деле.
    • Входные данные, которые использовались во время воспроизведения кейса.
    • Прочую информацию, без которой повторить кейс не получится.
    • Критичность и/или приоритет.
    • Экранный снимок (скрин).
    • Версию, сборку, ресурс и другие данные об окружении.

  • Запрос на изменение (улучшение) – описание неявных/некритичных косвенных требований, которые не были учтены при планировании/реализации продукта, но несоблюдение, которых может вызвать неприятие у конечного потребителя. И пути/рекомендации по модификации продукта для соответствия им.
  • Отчет о тестировании (тест репорт) – документ, предоставляющий сведения о соответствии/ несоответствии продукта требованиям. Может так же содержать описание некоторых подробностей проведенной сессии тестирования, например, затраченное время, использованные виды тестирования, перечень проверенных случаев и т. п. В идеальном варианте фраза вида «Тест пройден. Ошибка не воспроизводится/Функционал работает корректно/Соответствует требованиям» означает, что продукт или его часть полностью соответствует требованиям прямым и косвенным (в производстве ПО).

Внутренняя документация:
  • Тест-план (план тестирования) – формализованное и укрупненное описание одной сессии тестирования по одному или нескольким направлениям проверок. Т.е. перечень направлений проверок, которые должны быть проведены в рамках сессии тестирования (и, сообразных этим направлениям, требований). Также может содержать в себе необходимую информацию об окружении, методике, прочих условиях важных для показательности данной сессии тестирования. Под направлением проверок также может пониматься более детализированная тестовая документация (в виде ссылки на нее): чек листы, тестовые комплекты, тестовые сценарии, на которую необходимо опираться при проведении сессии тестирования. Основная цель документа – описать границы сессии тестирования, стабилизировать показательность данной сессии.
  • Тестовый сценарий – последовательность действий над продуктом, которые связаны единым ограниченным бизнес-процессом использования, и сообразных им  проверок корректности поведения продукта в ходе этих действий. Может содержать информацию об исходном состоянии продукта для запуска сценария, входных данных и прочие сведения, имеющие определяющее значение для успешного и показательного проведения проверок по сценарию. Особенностью является линейность действий и проверок, т.е. зависимость последующих действий и проверок от успешности предыдущих. Цель документа – стабилизация покрытия аспектов продукта, необходимых для выполнения функциональной задачи, показательными необходимыми и достаточными проверками. Фактически при успешном прохождении всего тестового сценария мы можем сделать заключение о том, что продукт может выполнять ту или иную возложенную на него функцию.
  • Тестовый комплект – некоторый набор формализованных тестовых случаев объединенных между собой по общему логическому признаку.
  • Чек-лист (лист проверок) – перечень формализованных тестовых случаев в виде удобном для проведения проверок. Тестовые случаи в чек-листе не должны быть зависимыми друг от друга. Обязательно должен содержать в себе информацию о: идеях проверок, наборах входных данных, ожидаемых результатах, булевую отметку о прохождении/непрохождении тестового случая, булевую отметку о совпадении/несовпадении фактического и ожидаемого результата по каждой проверке. Может так же содержать шаги для проведения проверки, данные об особенностях окружения и прочую информацию необходимую для проведения проверок. Цель – обеспечить стабильность покрытия требований проверками необходимыми и достаточными для заключения о соответствии им продукта. Особенностью является то, что чек-листы компонуются теми тестовыми случаями, которые показательны для определенного требования.
  • Тестовый случай (тест-кейс) – формализованное описание одной показательной проверки на соответствие требованиям прямым или косвенным. Обязательно должен содержать следующую информацию:
    • Идея проверки.
    • Описание проверяемого требования или проверяемой части требования.
    • Используемое для проверки тестовое окружение.
    • Исходное состояние продукта перед началом проверки.
    • Шаги для приведения продукта в состояние, подлежащее проверке.
    • Входные данные для использования при воспроизведении шагов.
    • Ожидаемый результат.
    • Прочую информацию, необходимую для проведения проверки.


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

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

Но следует учитывать, что есть и свои недостатки:
  • Стабильность покрытия. Со стремящейся к бесконечности долей вероятности, если проводится тестирование по документации, то будут проведены только те проверки, которые есть в данной документации. Вероятность пропуска ошибки (чаще всего несоответствие косвенному требованию, непокрытому документацией) возрастает.
  • Плохая локализация ошибки тестировщиком. Либо полное отсутствие локализации. Фактический результат не совпал с ожидаемым – ошибка. А что это на самом деле: ошибка; проявление ошибки; инцидент, уже описанной ошибки, тестировщик не проверит (в подавляющем количестве случаев).
  • Высокий требуемый уровень квалификации специалиста для создания и поддержания тестовой документации.
  • Большие временные затраты на создание и поддержание тестовой документации.
  • Слабо прогнозируемое время актуальности тестовой документации.

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

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

Из каких этапов состоит процесс тестирования?


Чаще всего отвечают приблизительно так: «подготовка, тестирование, отчет…» Так-то оно так, только абсолютно любой процесс состоит из этих этапов. И ответ никак не отражает понимание соискателем процессов тестирования. Больше похоже на читерство… Поэтому позволю себе изложение своего видения:
  1. инициация,
  2. выявление требований прямых и косвенных,
  3. генерация тестовых случаев,
  4. отбор показательных тестовых случаев,
  5. проведение проверок,
  6. фиксация результатов,
  7. анализ результатов,
  8. передача информации о соответствии проверенного продукта требованиям.

Более подробная информация об указанных этапах:

Инициация – событие, которое извещает команду тестирования о необходимости сессии тестирования, а также гарантирует выполнение требований к продукту для проведения тестирования.

Для производства ПО требования включают:
  • доступно необходимое тестовое окружение,
  • доступен билд/ресурс/предмет тестирования,
  • код, БД, прочие компоненты объекта тестирования «заморожены», т. е. не изменяются в период всей сессии тестирования,
  • модификация требований (хотя бы прямых) «заморожена»,
  • известно направление тестирования,
  • известны сроки на сессию тестирования.

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

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

Генерация тестовых случаев – выявление всех возможных случаев использования продукта, его характеристик и особенностей в процессе эксплуатации. Это значит: всех случаев, которые тестировщик может «придумать» на основе прямых и косвенных требований, известных ему. Этот  этап требует высокой квалификации специалиста по тестированию.

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

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

Проведение проверок – тут все понятно. Либо согласно документации, либо ad hoc (интуитивно, свободный поиск, без документации). В любом случае это проводится согласно списку отобранных проверок. Почему-то большинство именно этот пункт называет тестированием. И в голове обывателя, незнакомого с профессией, только один этот пункт и содержится J.

Фиксация результатов – создание внутренней и внешней тестовой документации в формализованном виде или в виде записей и т. п. На данном этапе отчет о тестирование даже если и создается, то не считается законченным.

Анализ результатов – вынесение решения о соответствии проверенного продукта требованиям. Формализация данного решения и его обоснование в виде отчета о тестировании. Сюда также входят процедуры по оценке покрытия требований проверками, тайм-шитинг и пр. Таким образом, проводится анализ не только результатов, но и самой сессии тестирования.

Передача информации о соответствии продукта требованиям. Формально: передача внешней тестовой документации заинтересованным в ней сторонам, зачастую инициатору сессии тестирования. В общем случае: помимо документации предоставляется информация о рисках, которые были выявлены в продукте, требованиях, процессах, передаются рекомендации по отработке этих рисков и т. п. Но это – уже QA J!

Вместо послесловия


Внимательный читатель заметил, что вопросы набирают сложность от начала к концу беседы. Вместе с тем, стоит отметить, что все эти вопросы не должны затруднить специалистов по тестированию, то есть тех, кто не «просто кликал мышью – тестировал», а пытался разобраться в сути того, чем он занимается, тех, кто не остановился на одной книжке или одном ресурсе, а продумал и обосновал свои действия… хотя бы для самого себя.

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

Comments 67

    0
    Наш QA тимлид порадовал вопросом который он всегда задаёт на собеседованиях: Представте ситуацию, вам дали 2 одинаковых проекта, т.е с одинаковым приоритетом, одинаковые по сложности и т.п., с какого проекта вы начнёте?
      +1
      ИМХО. С любого из этих двух. Если нет дополнительных условий.
        +19
        Каких ответов я жду на собеседовании по тестированию
        другой вариант 'правильного' ответа

          +11
          На последней картинке уволили тест менеджера, который дает сразу два одинаковых проекта не уточняя с какого начать?
            +1
            Ну что ж… Если все решает тест — менеджер, то наверное и правда до-свидания :) при том, что решать предоставили абстрактному «мне». А в целом:
            Пост так и называется, каких ответов Я жду.
          0
          Какой больше вдохновляет, если нет, как уже сказали, дополнительных условий.
            0
            Как-то вы сильно напряглись на "я жду". Коммент-то чуть отвлечённый, как дополнительная пища для размышлений. А вопрос сводится к тому, что если работаешь в команде не надо боятся спрашивать если что-то не знашь или не понимаешь. Этот навык тоже полезный, таже порой полезней некоторых технических навыков.
              –6
              Бага:
              >>таже порой
              Слово пишется с буквой «д»
                0
                Полностью согласен. Даже более того, во время испытательного срока, да и на собеседовании тоже обязательно обращаю внимание, как задают вопросы. Ибо зачастую по вопросам видно насколько человек «грокнул» смысл.
                +1
                а когда мне давали два проекта, то кто определил, что они одинаковые по признакам приоритет/сложность/прочее? если это было мне озвучено, то да, я определяю с какого начать — тут хоть монетку кидай, если иначе никак. А если постановщик проектов, то с какого фига я виноват оказался? А если два проекта поступили от разных людей, то должен быть кто-то, кто разрулит конфликтную ситуацию с проектами — например мой непосредственный руководитель либо же они между собой разберутся и выставят мне для более критичного проекта приоритет выше
                  0
                  Вы заморачиваетесь, а вопрос-то простой. Это то же самое, что начинать рассуждать на тему насколько форма и содержание лампочки соответствует груше из известной загадки.
                    0
                    разве тестировщик не должен, как вы выразились, заморачиваться?
                      0
                      Есть хорошее выражение: не делать из мухи слона, оно подходит и для тестировщика и для слесаря и вообще для всех. А уменее правильно оценить задачу одно из самых важных, а то так можно заморачиваться на тестирование поведение софта во время солнечных затмений и разных фаз луны, но ведь это уже перебор, согласитеьсь.
                        0
                        как по вашему должна выглядеть «муха», если мой комментарий это «слон»?
                          0
                          Так был ответ уже: спрошу у менеджера.
                  0
                  На мой взгляд абсолютно фиалетово одинаковы или нет проекты. Есть у проекта Product-owner. Те кто ближе к нему те и решают какой проект в первую очередь, а какой во вторую. От тестировщика не требуется решать судьбу проекта, он лишь может высказать мнение «Я вот тут нашел ошибку и мне кажется это ...», но не более!

                  Так что самый правильный ответ на этот вопрос, на мой взгляд, это спросить у своего руководителя\его зама\руководителя проекта и т.д. и т.п.
                    0
                    Если перефразировать «проект» -> «задача» (task), то вопрос собственно каждодневный:
                    приходит две задачи по одному проекту — реализованный функционал передали в тестирование. Приоритеты, критичность, сроки и прочая одинаковые, пометок ПМ в комментариях о срочности нет. Какую делать?
                    1. Спросить у тест лида.
                    2. Я сам тест лид. Спросить у ПМ.
                    3. Я тест лид. ПМу фиолетово. Любую.
                    4. Я тест лид. ПМу не фиолетово, он обозначает. Вставить ему «люлей» за то, что тратит чужое время.
                    5. Я тест лид. Решаю сам, ибо никаких отметок о срочности нет.
                    6. Я тест лид. Отдаю команде тестирования в разработку обе одновременно, разным людям.
                    Я так думаю, что холивары можно прекратить?
                    0
                    С проекта, имеющего бОльшую стратегическую ценность для существования компании. Если один проект — очередной договор с крупным постоянным заказчиком, а второй — полуслучайный, то начинать надо с первого.
                    0
                    Спасибо!
                    Я пока не представляю где есть централизованное хранилище методик воспитания такого специалиста и его рабочего цикла.
                    Можно надеяться, на то, что вы дадите хабровцам своё целостное видение?

                    Можете чуток прояснить разницу между тестовым сценарием и тестовым комплектом, состоящим их тестовых случаев?
                      0
                      В тестовый комплект собираются тестовые случаи по какому — то общему признаку: например «Комплект по проверке текстовых полей» — т.е. туда войдут те кейсы, которые проверяют различные поля на различных формах системы с различными входными данными. Эти кейсы заведомо не будут зависеть друг от друга, скорее всего будут покрывать части совершенно разных пунктов требований (пунктов ТЗ, мокапов и т.д.) и никак не увяжутся в единый БП использования системы. Тем не менее, появись такая надобность — вот они — в комплекте.
                      Тестовый сценарий — все же проверки увязанные с БП использования системы, например «БП управление доступом», в рамках которого производится и проверяется CRUD на учетной записи… Я бы не сказал, что в сценарий попадают кейсы в чистом виде: там именно набор действий пользователя, разделенный вехами проверок, что все идет как надо. И все шаги сценария зависят один от успешности другого.
                      0
                      Должен ли, по Вашему, тестировщик знать, что такое OWASP Top 10 и делать какой-то минимальный набор проверок базового функционала перед каждым релизом?
                        0
                        Тут вопрос скорее политический. Правильно их делать, но!.. тестировщик как лицо наемное не может диктовать свое видение лицам ответственным за продукт. Сиречь: надо предложить ПМу, тех. директору, owner`у проводить эти проверки, хотя бы с определенной периодичностью, обосновать эту необходимость. Далее решение за ними. Отвечая на вопрос:
                        1. Он должен суметь найти информацию по OWASP в случае возникновения необходимости и понять ее.
                        2. Перед каждым релизом… Нет. Скорее раз в определенной время. (период не обязательно должен быть привязан к релизам).
                        Любая проверка — деньги компании и задача сотрудников — экономить, но не забывая о функциональных обязанностях.
                        +1
                        Хорошая статья! Но возникает сразу вопрос: а что делать, если есть продукт, который кажется, полностью готов, но по нему нет ни одного документированного требования? В чем будет состоять тестирование в этом случае? В чем будет заключаться его цель? Ведь требований нет, проверять на соответствие, — если рассуждать формально, — нечего.
                          +2
                          Ну как же нечего? Если нет прямых требований, то всегда ВСЕГДА есть косвенные. На соответствие им и проверять. И не забывать, что «здравый смысл» — тоже источник косвенных требований :)
                            0
                            Это же страшно неформально. Мне кажется, что если человек собирается самостоятельно тут понапридумывать требования, то надо его остановить. Как Вы сами сказали, есть заказчик. Правильнее будет того формализовать сначала требования, а потом уже тестировать. Верно ведь?
                              0
                              Где? Где тот злодей, что хочет придумывать требования? Выявлять! Батенька, и только выявлять. Грань действительно очень тонкая, но ведь в этом и заключается квалификация — выявить существенное и отбросить несущественное. Хороший пример: есть движок карт ArcGis. Там по умолчанию настройка на работу с роликом мыши «реверсивная» (от себя — отдаление от подложки, на себя — приближение). Если Вы откроете публичные ресурсы с картами (Yandex, Google и пр.), то увидите, что «средний» пользователь в РФ «привык» к обратному. Ни одно ТЗ (кроме написанного военным в пятом поколении) не будет содержать прямого требования о направлении вращения ролика мыши и соотносить его с изменением масштаба. Что получается? Требование косвенное. Ухудшит отношение пользователей к приложению на этом движке, если вовремя не выявить и не исправить? Да. получается, что никто ничего не «придумал», а профит хороший.
                              Ну и есть такие люди, которые говорят — «пользователь привыкнет»… Думаю, что не надо объяснять почему это неправильно.
                                0
                                Тут дело не в формальности процесса, а в выпуске качественного решения. Тестирование одних косвенных требований не закроет риск того, что в прямых дыра.

                                Мое мнение здесь совпадает с вашим: целью тестирования должно быть в этом случае восстановление требований. Лучше сразу подключать к процессу аналитика и тестировщика, чтобы они работали в паре.

                                Вообще, случай для практики тестировщика наверное не самый типичный, поскольку команды, практикующие разработку без спецификаций, обычно стараются обходиться и без формального тестирования.
                              0
                              Продукт реализует какие либо БП, к БП предъявляются определённые требования и собственно эти самые требования предъявляются и к продукту реализующему процессы, а так-же есть косвенные требования.
                                0
                                Ощущение от сообщения такое, будто это был итеративный процесс, и в данный момент он успел пройти несколько внедрений у Заказчика.

                                В таком случае я понимаю, что все протоколы встреч с Заказчиком, где он просил развить/исправить/добавить функции, по каким-то причинам сожжены.

                                Другим безумным вариантом такой ситуации является авторская разработка без персонализированного Заказчика — например, попытка толкнуть на рынок коробочный продукт.

                                Но даже в таком случае должен был существовать дизайн-замысел «стартапера» в письменном виде, хотя бы и без свистелок и перделок, добавленных в реализации.

                                В отсутствии спецификации требований программистам всё равно придётся описать словами то, что они пытались реализовать, то есть написать спецификацию для существующего софта. Что, в общем, тоже не поздно — тестировщику как раз удобно присутствовать при создании или «создании» спецификаций.
                                +2
                                не боишься, что теперь соискатели будут тебе отвечать заученными вопросами из твоей статьи? :)
                                  0
                                  Сразу будет видно… и потом я же обосновать прошу.
                                  +5
                                  Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».

                                  По-моему, это не ответ на вопрос. Мало ли что без чего невозможно, но выбирает человек что-то одно, почему именно тестирование-то?

                                  Ошибка – несоответствие производимого продукта требованиям, прямым или косвенным.

                                  Ну так с учётом этого, «поиск ошибок» раскрывается в «поиск несоответствия производимого продукта требованиям, прямым или косвенным».
                                  Чем это отличается от «комплекс мероприятий, направленный на проведение проверок на соответствие производимого продукта требованиям, к нему предъявляемым (прямым и косвенным).»?
                                    +2
                                    Поиск несоответствия и проверка на соответствие абсолютно разные, с точки зрения анализа результата, процессы…
                                      0
                                      Ну, несколько разные, но, на мой взгляд, не абсолютно. А ответ «проверка отсутствия ошибок» вы бы сочли за удовлетворительный? И как проверить (в рамках тестирования, ибо можно доказать формально, но это уже не тестирование), кроме как поиском тех самых ошибок?
                                        +1
                                        разворачиваем: проверка отсутствия несоответствия требованиям = полное соответствие требованиям, но это недостижимо :( ибо всех косвенных требований не учтешь. И да, проверку отсутствия ошибок сочли бы на 0,75 правильным, но попросил бы развернуть ответ, объяснить, что имеется ввиду.
                                    +8

                                    >Почему вы решили стать тестировщиком?

                                    Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».

                                    Вы отлично описали зачем необходимо тестирование, но на вопрос не ответили, т.к. верного ответа как вы и сказали здесь нет.
                                      –1
                                      Скорее вопрос на отсеивание неправильных… да и посмотреть на реакции человека, попытаться установить контакт с ним…
                                        +4
                                        Вопрос из серии «а почему хотите работать»? Или «почему вы любите яблоки, а не груши»? Я считаю такие вопросы некорректными. Если вы хотите отсеять «заблудившихся», то так и говорите, что есть требования по усидчивости, внимательности, способности к монотонному труду, и спрашивайте — готов ли соискатель с этому. Если человек понимает на что подписывается, то и проблем с этим будет меньше.
                                      +2
                                      Кстати, среди вопросов вы совсем не озвучивали владение инструментарием.
                                      Вы интересуетесь чем тестировщики уже умеют пользоваться (напр. питон, selenium, git, etc)?
                                      Как опыт работы с ПО влияет на собеседование?
                                        +1
                                        Я — немного идеалист в этом плане. Я верю, что при возникновении необходимости любой адекватный человек сумеет освоить инструмент за обозримое время. В рамках собеседования интересуюсь, но решения на основе этих данных не принимаю. Причины две:
                                        1. Заявить, что умею пользоваться «вот этим вот всем» может каждый, а на деле умения не ушли дальше двух кликов по меню оснастки.
                                        2. Это выясняется в процессе работы на испытательном сроке. И осваивается тоже: элементарные навыки за три месяца адекватный человек приобретет.
                                        +9
                                        «Соискатель, который доходит за полтора часа беседы до восьмого вопроса, – редкость, такого я возьму на работу юниором. » — а зачем юниору знать что-то больше, чем ответ на первый вопрос?
                                          +6
                                          Затем, что работодатели желают нанимать профессионалов за еду.
                                          +5
                                          Второй по частоте ответ: «потому что я хочу работать в IT и тестирование – самый простой путь» (читай: у IT специалистов высокая зп, а в тестировании не нужно ни знаний, ни навыков, но зп тоже достаточно высокая!).

                                          Единственно правильного ответа нет, но вот указанные три и их производные – точно неправильные


                                          Почему Вы не хотите, чтобы будущий тестировщик был честным?
                                          Если человек может выполнять некое множество видов деятельности, а хочет работать там, где больше заплатят, то что в этом зазорного?
                                            +5
                                            Последний год вместо собеседований у меня получаются импровизированные лекции

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

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

                                            Интересно, вы не пробовали задавать вопрос: кто такой тестировщик? Мне кажется, что ответы будут очень разными, и скажут много о кандидате.

                                              +17
                                              Дзен-интервью:
                                              — Почему вы решили стать тестировщиком?
                                              — Воротник застегните, пожалуйста.
                                                +2
                                                Я думаю первый вопрос нужно переформулировать.
                                                Например, я стал тестировщиком, совершенно случайно — брату понадобилась помощь в проекте, где он был программистом, а мне нечего делать было на летних выходных. Другое дело, почему я после этого опыта все еще остался в тестировании — вот тут да, это интересно.
                                                Может потому, что я делать ничего не умею, кроме этого; может потому, что это очень легко, а платят много; как-то мне встретился потрясающий ответ: «потому что мне нравится указывать другим на их недостатки».

                                                В общем, причина стать тестировщиком может быть любой и даже вполне глупой и той, которая сразу же вешает неприятный ярлык. Но если речь не про первую работу у человека, а человека с опытом, гораздо интереснее, почему он все еще работает и ищет работу тестировщиком.
                                                  +4
                                                  Что бы я хотел услышать? Возможно, что-то вроде: «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя».

                                                  это ответ на вопрос зачем вообще нужно тестирование.
                                                  а вы спрашиваете, почему кто-то решил стать тестировщиком. имхо, вы не то ожидаете.
                                                  ответ на вопрос, почему выбрана та или иная профессия никогда не будет привязан к отрасли. это всегда личный опыт по жизни или личные взгляды.
                                                    +1
                                                    Соискатель, который доходит за полтора часа беседы до восьмого вопроса, – редкость, такого я возьму на работу юниором. Доходящий за то же время до 11 вопроса может быть принят на должность ведущего тестировщика, однако за 240 проведенных собеседований таких оказалось только 5 человек!
                                                    Может, я слишком требователен к ответам?

                                                    Скорее всего, вы просто давно или маловато были собеседуемым :)

                                                    Вы учитываете факторы ниже или ищете чуть ли не идеальных кандидатов?
                                                    • Человек может волноваться, особенно в условиях ограниченного времени.
                                                    • Человек может плохо владеть речью, плохо излагать свои мысли. Некоторые хорошо делают, но плохо объясняют.
                                                    • Области его и ваших знаний могут плохо пересекаться.
                                                    • Вы одни и те же вопросы постоянно спрашиваете, что означает, что вы их хорошо разобрали и хорошо помните данную часть предметной области, но это не значит, что другие сделали акцент на этом.
                                                    • Как давно человек работал с технологией, о которой вы его спрашиваете. Может он когда-то был в ней экспертом, но забыл ее, так как не приходилось ей пользоваться последние несколько лет.

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

                                                    Ниже конечно, только мое мнение, но может и другие будут с ним согласны.
                                                    Попробуйте предложить собеседуемым выбирать – устно или письменно отвечать на вопросы. В случае письменного варианта предоставить им час-полтора времени без вашего присутствия, оставив возможность обратиться к вам в случае непонимания, о чем спрашивается в вопросе. А также в случае кандидатов с опытом, сначала задавать вопросы 7-11, потом 5-6, а потом остальные. 3-ий вопрос и из него вытекающее я бы вообще убрал или оставил на последок, т.к. только из кольи выбьете подобными вопросами.
                                                    Глядишь, и на поиск 5 человек на должность ведущего тестировщика, нужно будет опросить 50 человек, а не 240.
                                                      +1
                                                      Доброго дня!
                                                      Возможно Вы невнимательно читали статью. Я поясню:
                                                      • Человек может волноваться, особенно в условиях ограниченного времени.

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

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

                                                      Этому человеку придется владеть речью и формализовать свои мысли в той форме, в которой его поймут разработчики, ПМ и прочие. Это проблема, которую должно было решить среднее образование. Я денег за обучение юниоров, опытных и прочих не беру. Я набираю людей, которые с первого дня работы начинают получать зарплату, в том числе и юниоры — среднюю по СПб, а то и выше.

                                                      • Области его и ваших знаний могут плохо пересекаться.

                                                      Это абсолютно точно так, но я и не требую от него четкого знания буква в букву. Тоже писал об этом. Я согласен брать людей с другим набором знаний, но вот они не согласны работать на правах и зарплате стажера. Поэтому я жду, что они проведут хотя бы минимальную подготовку по той области, в которой собираются работать.

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

                                                      Хм, по моему все вопросы относятся к весьма и весьма базовым по тестированию. Я не спрашиваю устройство сетей, особенности картографических проекций, знания API google карт или еще какую-то специфику… Я спрашиваю, а чем Вы, собственно, пришли сюда заниматься?

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

                                                      Что мешало освежить свои знания и навыки перед собеседованием?

                                                      Вообще, я благодарен за Ваш ответ, он действительно конструктивен и вопросы, которые Вы в нем поднимаете — бич собеседований в IT. Отвечая на Ваше утверждение: я каждые полгода обязательно хожу на пару — тройку собеседований — это хорошо дает понять в какую сторону развивается рынок труда, что интересует работодателей. И стараюсь избегать общих ошибок, которые вижу на этих собеседованиях. И форма собеседования именно поэтому и построена в форме беседы, а не экзамена. Именно поэтому я стараюсь объяснять свою точку зрения и слежу за «откликом» на нее. А самое главное — я не считаю, что те, кто не прошел собеседование — плохие или ничего не знают, я считаю, что мы не сработаемся, вот и все. «Нет плохих специалистов, есть не на своем месте» (с) Вот и я стараюсь избежать людей не на своем месте, так как это принесет проблемы не только мне, но и им самим.
                                                        0
                                                        Доброго времени суток!

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

                                                        Если у соискателя на вакансию тестировщика базовые вещи вызывают такое количество затруднений, значит он не особо готовился.

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

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

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

                                                        Я согласен брать людей с другим набором знаний, но вот они не согласны работать на правах и зарплате стажера.

                                                        И скорее всего правильно делают. Вы им на данном этапе делаете встречное предложение платить соответствующую зарплату, если их знания окажутся выше ожидаемых вами, или выдавать им премию если на испытательном сроке от них будет пользы больше ожидаемой вами? Я ни разу не слышал подобного предложения, а хотелось бы.
                                                        Допустим в Вашем направлении стало неперспективно работать (направление устарело или зарплаты стали низкими). Но у вас есть неплохая финансовая подушка. Вы согласитесь устроиться джуниором на длительный срок в соседнем направлении, где немалая часть ваших знаний вполне актуальна, но вам скажут, что им чихать на ваш опыт в соседнем направлении?
                                                        Лично я – нет. Либо устроюсь временно и сбегу сразу, как найду компанию, где меня устроят условия работы. Хотят – пусть ищут дальше или набирут студентов, потратят года 3 на их обучение тому, что человек из соседней области за полгода освоит на том же уровне.
                                                        Скажу на примере программистов — senior в одной области примерно равен midle в той, с которой он не работал. Переобучиться под другую область программирования обычно не занимает слишком много времени. Так как хоть и технологии другие, многие вещи пересекаются, да и есть понимание, как надо работать, что от тебя хотят, как решать проблемы.

                                                        Что мешало освежить свои знания и навыки перед собеседованием?

                                                        Время, объем знаний, работа на которой приходится колбасить по 12 часов в сутки, пятеро детей :)
                                                        Освежите за недельку-две перед собеседованием все то, на что вы потратили десяток лет жизни. Кто знает, что собеседующему придет спросить в голову.
                                                      +9
                                                      Больше похоже, что вам не люди в отдел нужны, а просто на желание поднять свое ЧСВ. И вопросы больше похожи на вопросы препода из бурсы какой-нить, оторванного от реальности того-же тестирования в реальности. Знаете, я не мало в жизни повидал теоретиков с подвешенным языком, но вот ни одного из них не могу припомнить как продуктивного сотрудника. Зато обратных ситуаций пруд пруди.
                                                        +1
                                                        +100500, маладца, наш чувачок.
                                                          0
                                                          Мой фильтр тестироващика (ДА/нет)

                                                          1. Тесты надо ПИСАТЬ на основе TDD и существующего API
                                                          2. Исходный код вам НЕ ДАДУТ
                                                          3. Готов писать один и тот же тест и выполнять его же сто раз БЕЗ использования средств АВТОМАТИЗАЦИИ
                                                            +1
                                                            Разница только в том, что я практикую :)
                                                            И должность руководителя получил не за то, что сын директора. Вообще не родственник (ни на прошлом месте, ни на этом). Более того руководителя первый раз увидел на собеседовании. И он (мой непосредственный руководитель) вырос из разработчиков и неплохих, так как его софтом для внутреннего назначения вовсю пользуются до сих пор. А начинал в одиночку. Более того, можно много высказываться в общем смысле, но мой отдел из 4 человек (включая меня) справляется с 9 проектами разного направления, без задержек сроков и срыва метрик по уровням качества. В то время, как многие компании вынуждены нанимать по 7-9 человек на один такой проект. Так что позволю все таки себе заметить, что ЧСВ у меня обосновано. А людей я на собеседованиях не унижаю, а пытаюсь вытянуть до нужного уровня. И даже те, кого я не взял к себе работать, в конечном итоге говорят: «спасибо».
                                                            –2
                                                            тестировщик, выпей йаду и успокойся.

                                                            программист со стажем 25 лет
                                                              +5
                                                              Рискну не согласиться сразу по нескольким пунктам. Для начала, с определений.
                                                              Определений в сфере тестирования масса, и куча противоречит друг другу. Ввиду отсутствия общепринятого стандарта (хотя есть и ISO, ГОСТ и ISQTB), к примеру, понятие тестирование/специалист по тестированию может отличаться от одной компании/проекта, как боинг от москвич 412.

                                                              Начнем с определения тестирования.
                                                              Тот же ISQTB, де факто стандарт в Заходней Европе, считает что тестирование — процесс как определения соответствию требований, так и по поиску дефектов. Гост (основан на ISO) — указывает, что тестирование, это операция, которая заключается в определении одной или нескольких характеристик продукта (пруфлинк: testrussia.ru/doc/12119_2000.pdf)

                                                              Так что, в определении тестирования, понятно лишь одно — это процесс (ну или, комплекс мероприятий, если вам угодно). Цель — неизвестна, т.к. не указан тип тестирования. В процессе тестирования мы можем как определять соответствия требованиям, так и просто выяснять реальное поведение системы — и это тоже будет тестированием.
                                                              К примеру, мы можем не знать ожидаемую нагрузку на сетевое приложение, но это не мешает нам провести нагрузочные и стресс тесты — чтобы знать(задокументировать) пределы возможностей. Мы не знаем, сколько будет пользователей (ну стартап у нас, ща модно). Но мы знаем, что если больше чем Х, то нужно срочно бежать за новым сервером. Пример преувеличенный, для наглядности.

                                                              С целью тестирования — все вообще не просто. И по хорошему, я бы не выяснял про сферическую цель тестирования в вакууме. Цель тестирования должны сказать заказчики тестирования (проектный менеджер, разработчик, в общем тот, кто это тестирование просит. Заказчик программы, на худой конец).
                                                              И если специалист грамотный, он знает — что целей тестирования может быть тыщи. Но в основном — что-то да выяснить. Количество багов, или что-то еще — покажет вскрытие ретроспектива.

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

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

                                                              Каких ответов жду я на собеседовании по тестированию? Не сферических в вакууме, а дающих понять, соответствует ли конкретный кандидат на конкретную позицию, и как у нас с бюджетом. И как он вольется в команду. А какую книжку он читал — Канера, или учебное издание «Теоретические основы тестирования программных продуктов» — не важно, в общем. Во многих компаниях до старшего тестировщика вообще не требуется понимать что-либо кроме бизнес-домена и умения работать с баг-треккером и тестируемым приложением. И главное, ловить, таки, баги.
                                                              Есть, таки есть! спецы, которые книжек не читали. И не хотят. Но ловят баги, собаки, а рядом сидят дипломированные тестеры, и пишут грамотные тест планы, которые ничего не дают. Но это уже лирика.

                                                              Сумбурно как-то вышло, простите :)
                                                                0
                                                                Тест план — это огромный документ, описывающий в основном стратегию, видение, цели, риски.

                                                                И в той же (или очень похожей на ту) компании тест-кейс — это сценарий использования приложения конечным потребителем ранжированный по частоте использования.
                                                                До сих пор стыдно, как я на собеседовании в нормальную компанию пытался вспомнить эту формулировку и разочарование на лицах собеседовавших когда после минуты вспоминания я выдал ЭТО.
                                                                  0
                                                                  К сожалению, Вы бы не прошли собеседование на тестировщика с Вашими знаниями…
                                                                    0
                                                                    По сути — верно. Только вот и статья-то написана о том, чего именно мне и нужно. А по факту: тот же ISQTB — сам себе противоречит в терминах и является, по сути своей, просто компиляцией всех терминов и их определений, сводкой методологий. Я же пытаюсь предложить то, что построено самим на основе опыта работы в данной профессии и применимо к 95% проектов, как по тестированию ПО, так и по тестированию любой предметной области, в том числе бизнес- процессов. Для меня в итоге важно, чтобы человек понимал куда пришел — для этого беседа и вопросы. Важно, чтобы я понимал насколько мы с человеком будем говорить на одном языке и одними терминами. Как-то так.
                                                                    +5
                                                                    После первого пункта не читал. Такую неадекватность на главной давно не видел.
                                                                      +2
                                                                      Разработчик с пятнадцатилетним стажем.
                                                                      Многие моменты крайне спорны. Пожалуй, соглашусь с другими комментаторами в том, что первый же вопрос отбивает желание читать дальше, поскольку совершенно нелогичен.

                                                                      — Почему вы решили стать тестировщиком?
                                                                      — «потому что без тестирования невозможно выявить истинное состояние производимого продукта, и насколько он соответствует ожиданиям потребителя»


                                                                      Автор перепутал мотивацию кандидата с причиной организации собеседования. Выявление качества продукта — это не причина почему человек решил стать тестировщиком, это причина наличия вакансии тестировщика. Это необходимо разработчику.
                                                                      А тестировщику как раз должен быть интересен сам процесс тестирования. Мозги у него должны быть так устроены. Ему должно быть интересно раз за разом тыкать одну и ту же кнопку, раз за разом начинать все тесткейсы сначала и не сойти при этом с ума.
                                                                        0
                                                                        А как ждать от человека адекватности, который не может объяснить зачем пришел?
                                                                        0
                                                                        korvinriner
                                                                        А можете прояснить в чем отличие «тестового сценария» от «тестового случая»? На первый взгляд, из Вашего описания выше, они одинаковы!
                                                                          0
                                                                          Кратко: сценарий проверяет набор идей и содержит много ожидаемых результатов, каждый из которых критичен для реализации одного завершенного БП пользователя (например ЖЦ учетной записи пользователя).
                                                                          Тестовый случай — проверяет только одну идею и содержит один ожидаемый результат, т.к. проверяет только одну функцию продукта (например работу валидатора на поле в форме).
                                                                          +2
                                                                          судя по первому вопросу, лучшим ответом на должность программиста будет «потому что без программирования невозможно разработать качественный продукт, выполняющий все условия, представленные заказчиком»
                                                                          если вы хотели бы услышать это, а не «мне просто это нравится», то хороших специалистов найти будет сложно
                                                                            0
                                                                            А вот это, кстати, хороший вариант: «мне нравится этим заниматься». Жаль звучит очень редко.
                                                                            0
                                                                            Добрый день!
                                                                            Очень жду продолжения статьи.

                                                                            Only users with full accounts can post comments. Log in, please.