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

Я ожидала получить достаточно много вопросов по этой теме. Однако обратных вопросов – «Как его проходить?» - на почту и на форум «Лаборатории Качества» валилось значительно больше. Следуя спросу, продолжаю цикл ответной статьёй.

Введение

2. Протестируйте лифт!

Итак, Вы рассказали, что такое классы эквивалентности и граничные значения. Пришло время проверить, умеете ли Вы их использовать. И вот, Вас просят протестировать лифт. Или карандаш. Или калькулятор, джинсы, чашку. Неважно что. Задача – скорее всего непривычная и нестандартная. Что ждёт от Вашего ответа работодатель?

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

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

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

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

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

3. Расскажите, как создавать тест-кейзы

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

Я не буду давать длительных советов по этому вопросу – или напишу отдельную статью. Просто убедитесь, что Вы знаете, как отвечать на этот философский вопрос.

Этот вопрос, как и предыдущий, тоже распространён достаточно часто. Google поможет Вам быть к нему готовым.

В мои планы в рамках этой статьи не входят рассказы про настройку DNS и запросы к базам данных. Но есть некие общие советы, которых стоит придерживаться:

Во-первых, нехватка технических знаний быстро компенсируется и работодатели редко уделяют очень серьёзное внимание этому вопросу. Во-вторых, неудачно скрываемое незнание всегда вызывает недоверие: можно ли верить остальным словам кандидата? А в-третьих, потенциальный работодатель может разделять моё мнение о том, что защищающие неправильную точку зрения люди чаще допускают ошибки в работе. По крайней мере, сотрудника, который хорошо разбирался в тестировании, но старательно доказывал что «в Windows нет поддержки динамических дисков», я на работу не взяла. Скорее всего, если бы он честно признался, что не знает, что это такое, решение было бы другим.

2. Если видите, что не очень удачно ответили на предыдущие вопросы – инициируйте ответы сами, но по темам, которые знаете лучше.

К примеру, если Вы неудачно ответили на вопрос про MS SQL, скажите сами, что зато Вы имеете опыт работы с Oracle и поэтому быстро сможете «перепрофилироваться».

Способность быстро и самостоятельно разобраться в незнакомой технологии или инструменте ценятся выше, чем имеющиеся знания. Не стесняйтесь хвалить себя. Если после Ваших слов о том, что Вы не разбираетесь в Rational Robot, собеседующий немного поник – гордо скажите, что зато в Silk Test Вы разобрались всего за неделю и сумели многое (конкретизируйте) в нём сделать. Естественно, здесь тоже говорить нужно правду!

Главное – не бояться. Вы ищете работу, а работодатель ищет грамотного сотрудника. Вы оба заинтересованы в результате. Быть принятым на неподходящую работу – значительно хуже, чем получить отказ. Пробуйте, не нервничайте, учитесь! И развивайтесь для себя – а не для «галочки» на собеседовании. Удачи !

Иногда общение на собеседовании не ограничивается беседой. Соискателю предлагается пройти один или несколько тестов. Какие тесты бывают на собеседовании? Тесты могут определять уровень компетентности соискателя (профессиональное тестирование). Кандидату могут предложить пройти психологическое тестирование – для того чтобы работодатель получил более полное представление о чертах характера, мотивах, поведенческих особенностях претендента на должность. В отдельную группу можно выделить тесты на логику.

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

Формулировки вопросов могут показаться абсурдными. Например, что слоны – это книги. Не давайте сбить себя с толку – это просто слова для обозначения групп объектов. Отключите образное мышление, не пытайтесь представить слонов-мутантов; используйте для решения только логику.

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

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

Ниже приводим 12 вопросов на логику : с подобным тестом вы можете столкнуться при трудоустройстве. Ответы приводятся в конце. Постарайтесь ответить самостоятельно, не подглядывая в результат. На собеседовании время может быть ограничено, но, как правило, его достаточно – важно не быстрее думать, а расслабиться и успокоиться.

1. Некоторые кролики являются деревьями. Все деревья любят собак. Значит, все кролики любят собак.

б) Неверно.

2. Все книги умеют бегать. Все слоны являются книгами. Значит, все слоны могут бегать.

б) Неверно.

3 . Две морковки никогда не бывают, похожи одна на другую. Березы и каштаны выглядят совершенно одинаково. Значит, березы и каштаны не являются двумя морковками.

б) Неверно.

4 . Некоторые картофелины – автомобили. Некоторые автомобили играют на бубне. Значит, некоторые картофелины играют на бубне.

б) Неверно.

5 . Никто из птиц не может стать министром, если у него голубой нос. У всех птиц нос голубой. Значит, никто из птиц не может стать министром.

б) Неверно.

6 . Все соловьи собирают бананы. Некоторые собиратели бананов сидят в собачьей будке. Значит, некоторые соловьи сидят в собачьей будке.

б) Неверно.

7 . Только умные люди крадут или обманывают. Света – глупая.

а) Света обманывает.

б) Света не крадет.

в) Света крадет.

г) Света крадет и обманывает.

д) Нет верного ответа.

8 . Все лебеди не умеют ползать. У всех лебедей есть билеты.

а) Без билетов лебеди не могут ползать.

б) Некоторые лебеди не имеют билетов.

в) Лебеди не могут ползать, потому что у них есть билеты.

г) Все лебеди, у которых есть билеты, не могут ползать.

д) Лебеди не могут ползать, и у них нет билетов.

е) Нет верного ответа.

9 . Некоторые кошки – китайцы. Китайцы имеют три лапы.

а) Кошки с четырьмя лапами не являются китайцами.

б) Китайцы, которые являются кошками, иногда имеют три лапы.

в) Китайцы с четырьмя лапами иногда являются кошками.

г) Кошек не китайцев с тремя лапами не бывает.

д) Кошки имеют три лапы, потому что они китайцы.

е) Нет верного ответа.

10 . Деревья – это зеленые кошки. Деревья пьют пиво.

а) Все зеленые кошки пьют пиво.

б) Все зеленые кошки являются деревьями.

в) Некоторые зеленые кошки пьют пиво.

г) Зеленые кошки не пьют пиво.

д) Зеленые кошки не являются деревьями.

е) Нет верного ответа.

11 . Умные руководители падают с неба. Глупые руководители могут курить.

а) Глупые руководители падают с неба вниз.

б) Умные руководители, которые умеют падать – могут курить.

в) Некоторые глупые руководители не могут курить.

г) Некоторые умные руководители – глупые, так как они умеют курить.

д) Нет верного ответа.

12 . Каждый треугольник квадратный. Все треугольники оранжевые.

а) Б ывают треугольники с оранжевыми углами.

б) Б ывают треугольники с квадратными углами.

в) Б ывают треугольные оранжевые углы.

г) У глы и треугольники – квадратные и оранжевые.

д) Нет верного ответа.

Правильные ответы :

1б, 2а, 3а, 4б, 5а, 6б, 7б, 8г, 9а, 10в, 11д, 12д.

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

Тесты на логику на собеседовании was last modified: Август 28th, 2017 by Елена Набатчикова

Доброго времени суток, дорогой друг!

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

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

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

Соискатель для такого работодателя, — вполне подходящая мишень, чтобы урвать себе хоть что-то на ровном месте. А именно — бесплатно сделанную работу.

Один из моих клиентов, Павел, обратился за советом:

Пригласили на собеседование в компанию оборонного сектора. Руководитель HR- отдела, ближе к концу собеседования, — начал живо интересоваться личными разработками моего клиента и попросил выслать по почте.

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

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

Еще пример:

В одной из компаний всем кандидатам на должность тестировщика предлагают такой тест: „Протестируйте сайт нашей компании“. При этом предлагать работу, как оказалось, — никому не собираются. Зачем платить, если работают бесплатно?

Подобные «тесты», которые, по сути, являются полноценными проектами, — время от времени встречаются в компаниях IT сектора, маркетинга, медиа.

При всем при этом не очень понятно, водят тебя за нос или нет.

Очевидно, что при таком подходе репутационные потери компании будут значительно превышать “прибыль” от облопошивания кандидатов. Но разве им объяснишь? Так или иначе, важно выбрать свою тактику поведения,

Основная мысль: найдите баланс между своим желанием работать именно в этой компании и временными и моральными издержками на выполнение тестов.

Об этом чем чуть ниже, а пока сделаем краткий обзор:

Какие бывают тесты

Условно все тесты можно классифицировать на следующие группы:

1. Психологические тесты. Этой теме мы с вами посвятили отдельную .
2. Задачи. Обычно абстрактные и сообразительность.
3. Профессиональные кейсы.

Об этой группе тестов подробнее. Профессиональные кейсы также можно классифицировать.

а) Абстрактные ситуационные кейсы

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

б) Тест-опросники

Что-то типа анкеты, содержащей вопросы и варианты ответов по профессиональной тематике. Применяются не так часто и в специфических случаях.

в) Реальные практические кейсы

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

Иногда тесты оправданы

Иногда работа имеет выраженную специфику и тестовое задание, — наиболее адекватный способ оценки кандидата. При этом обе стороны понимают это.

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

Является ли предложение сделать бесплатную работу жульничеством? Пожалуй нет. Вам же не обещают оплатить эту работу или после окончания работы выдать джобоффер. А по сему, — решать вам.

Когда выполнять тест, а когда отказаться?

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

1. Ваше желание работать именно в этой компании

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

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

2.Затраты времени

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

Если задание больше похоже на проект, или концепцию, на которые потребуется пару дней, а то и больше, — рекомендую поступить так:

• Сделать план реализации проекта и оставить за кадром подробности. Это сродни предварительной консультации.
• Если спросят почему не до конца, — скажите, что уровень компетентности можно определить и по лайт-версии. Полная версия — это уже консалтинг, готовое решение. А за готовое решение... сами понимаете.

Воспользуйтесь ситуацией, чтобы вызвать интерес. Интерес появляется от недосказанности.

3. Стадия подбора

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

Если тест предлагается после того, как вы прошли собеседование с линейным руководителем, и у вас есть подозрения, что вас «разводят», — рекомендую поинтересоваться:

1. По каким критериям будет оцениваться тест?
2. Если тест сделан хорошо — вы получите предложение о работе?
3. Можете ли вы сделать «облегченную» версию, из которой будет понятен ваш уровень компетентности?

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

Оптимальная задача для вас — вызвать интерес при минимальных затратах времени.

Например, показать план действий по выполнению той работы, которая предложена в кейсе. Какой-то пункт можно расписать подробнее для примера.

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

Если просят прислать ваши разработки.

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

Не платите!

Некоторые особо ретивые работодатели или их “предприимчивые”представители из стремятся урвать хоть что-то на пустом месте. Например: обязательные платные тесты на полиграфе, разные платные обучающие программы и т.п. Вариантов может быть много.

Возьмите за правило: Не платить. Это почти всегда 100% развод.

Существует негласное правило: на рынке труда платит работодатель . Это общепринятая практика. Если работодатель ее игнорирует, значит он не только нарушает правила игры, но и попросту не уважает потенциальных сотрудников. А значит, — нам не по пути.

Благодарю за интерес к статье.

Если вы нашли ее полезной, сделайте следующее:

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

Удачного вам дня и хорошего настроения!

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

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

Вступление

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

На собеседовании я всегда задаю одни и те же вопросы:

1. Что такое ошибка?
2. В чем цель тестирования?
3. Какие бывают требования?
4. Автоматизированное тестирование - отдельный вид тестирования?
5. Какой тип/вид класс тестирования имеет смысл автоматизировать?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть маленький грех за мной: я отрицаю существование негативных проверок, поскольку:

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

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

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

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

Внешняя документация:

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

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

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

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

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

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

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

1. инициация,
2. выявление требований прямых и косвенных,
3. генерация тестовых случаев,
4. отбор показательных тестовых случаев,
5. проведение проверок,
6. фиксация результатов,
7. анализ результатов,
8. передача информации о соответствии проверенного продукта требованиям.

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

Для производства ПО требования включают:

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы на сообразительность

• Сколько необходимо произвести кукол, чтобы удовлетворить спрос в куклах 1 млн города?
• Сколько теннисных мячей влезет в автобус?
• Как будете тестировать эскалатор/верёвку/будильник?
• Подсчитайте примерную площадь застройки г. N в % от площади РФ
• Как объясните свою работу человеку, не знакомого с тестированием?
• Напишите формулу вычисления угла между часовой и минутной стрелками на часлах?
• Как вы готовились для интервью?
• Сколько ступенек на лестнице, по которой вы поднимались к нам?

Ситуационные вопросы

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

Ситуация: вам необходимо протестировать кнопку "старт" в веб-приложении, кнопка находиться на 3-ей по счёту странице, начиная со стартовой? Как вы будете тестировать этот функционал?

Ситуация: Есть проект, для которого написано 500 тестов. Приходит заказчик и говорит, что хочет продать продукт и должен быть уверенным, что он рабочий. И хочет, чтобы вы прогнали все эти тесты. Как вы оцените трудозатраты (кол-во дней/часов) и как будет общаться с заказчиком по этому поводу?

Ситуация: Вы попали на новый проект и вы единственный тестировщик на нём. С чего вы начнёте в первую очередь?

Ситуация: У вас есть приложение, которое вычисляет среднее значение оценок студента. Какие входные параметры нам необходимо будет проверять?

Ситуация: Представте, что вы Менеджер, как вы будетете оценивать работу тестировщика на ревью? По каким критериям?

Общие вопросы на темы

• Как вы планируете тестирование приложения?
• Жизненный цикл разработки приложение и тестирование в нём. Когда необходимо начинать тестировать?
• Дизайн тест кейсов, планов и прочих артефактов. Приходилось ли их разрабатывать?Что такое тестирование сверху вниз и снизу вверх?
• Анализ требований, тест кейсов, результатов тестирования, отчётов об ошибках. Как вообще определяете, что необходимо тестировать?
• Знаете ли что-нибудь о классах эквивалентности?
• Как определить, что тестирование закончено?
• Типы тестов (exploration/script, ручное/автоматизир, функц/нагруз/безопасности). Какие из них применяли? В чём они выражались?
• Жизненый цикл дефектов (ошибок). Что включаете в ошибку при её описании?
• Как будете тестировать приложение, если для продукта нет документации?
• Как вы определяете эталонные результаты?
• Что такое тестовое окружение?
• Расскажите о методологиях тестирования
• Опишите любой дефект, который вы помните. Вспомнитие ваш самый "лучший" баг.
• Каков смысл тестирования в процессе разработки?
• В чём разница между валидацией и верификацией?
• Что по вашему является хорошим требованием?
• В чём смысл автоматизации тестирования? Когда она необходима и что необходимо тестировать? Каковы на неё трудозатраты? Нужна ли автоматизация вообще?
• Каковы минусы полной автоматизации тестирования?
• Что вам нравиться/не нравиться в вашей работе?
• Как вы организуете свой процесс работы?
• В чём различие тестирования методом чёрного/белого/серого ящика? Какой из методов лучше?
• Необходимо ли нам тестировать все возможные комбинации/сценарии для программы?
• В чём смысл unit тестов?
• Знаете ли вы какие-либо техники/методологии разработки приложения, которые основываются на тестировании(BDD, TDD)?
• Необходим ли тестировщику общаться с разработчиками? Зачем?
• Есть ли смысл в баг-трекинг системах?
• Как вы производите приоритезацию дефектов?
• Что такое тестирование граничных значений?
• Использует ли ваша команда CI? Если да, то зачем?
• Где вы черпаете новые знания о методологиях тестирования и о самом тестировании?
• Что вы будете делать, когда устанете делать монотонную работу (тестировать к примеру один модуль несколько месяцев подряд) ?
  P.S.: Это всего лишь вершина айсберга, для собеседования более серьёзных кандидатов необходимо влкючать логические задачи, алгоритмы, знание языков программирования и пр. и т.д.

Do different tests instead of repeating the same tests