— Бери лопату и копай!
— Есть, капитан!
На собеседовании я даю кандидатам задачу с подвохом. В ней специально опущена часть требований. Я хочу посмотреть, будет кандидат задавать вопросы или бросится сразукопать яму писать тесты.
8 кандидатов из 10 начинают писать тесты и даже отмахиваются от моих ненавязчивых подсказок:
— А я Заказчик, можете задавать мне вопросы.
— Да зачем? Все понятно же! Сейчас напишу...
Это должно показать кандидата с лучшей стороны, вон какой старательный, вон как быстро может тестов придумать. Но это не так.
Придумать десяток тестов — легко.
Придумать десяток правильных тестов — намного сложнее.
Правильные тесты проверяют ровно то, что нужно. Ничего лишнего из того, что мы додумали по исходной постановке задачи, не уточнив правдивость своих размышлений.
Думаете, мы просто издеваемся над кандидатами, а в реальной жизни такого не бывает? Как раз наоборот!
Всё просто. Заказчик находится внутри контекста своей проблемы и думает, что все знают то же, что и он.
Отличный пример был в летней школе тестировщиков в виде ролевой игры.
Заказчику надо решить конкретную проблему — сотрудников в фирме много, он не помнит все дни рождения и прочие важные даты. И хочет, чтобы исполнитель сделал систему, которая будет оповещать его об:
Более того, Заказчик не будет говорить о том, что у него, кроме русских, есть китайцы и корейцы, он ведь об этом знает — исполнитель тоже должен знать! Или выяснять.
Разработчики не стали ничего уточнять и пошли решать проблемы, которые давно решены. Они продумали форму создания нового сотрудника и ее редактирования (которая у Заказчика уже есть и менять он ее не будет). Зато забыли про часть исходных требований, проигнорировав стаж работы сотрудника в фирме или второе письмо про отпуск.
Задача тестировщика — выяснить, что действительно нужно Заказчику.
Задача простейшая – проверить загрузку файла. Принимаемые форматы — Excel, csv. Нажимаем на кнопку “Выбрать файл”, загружаем файл, и по его данным сервер строит отчет. Данные представляют собой табличку: первая колонка — ФИО поставщика, потом телефон.
Уже можно бросаться писать чек-лист? НЕТ!
Сначала надо выяснить, что от нас требуется проверить, и какие данные есть на входе.
Обратимся к Заказчику:
— А что происходит с содержимым файла после загрузки?
— Данные о поставщиках сохраняются в базу, по ним потом будут строиться отчеты.
Ага, есть некая база с поставщиками, отлично! Это наводит на новые мысли и появляются новые вопросы:
— Что будет, если такой поставщик уже есть в базе?
— Неважно, дубли будем схлопывать потом, в следующей итерации.
— А если вместо ФИО или телефона передан беспорядочный набор символов?
— В следующих релизах будем с этим разбираться. Пока сохраняем как есть.
Важное замечание, иначе тестировщик может кинуться проверять десятки негативных тестов "что можно ввести в эти поля", которые не имеют смысла.
Ок, на выходе у нас ровно то, что и на входе, без дополнительных проверок, удаления мусора и прочего. А что у нас на входе? Достаточно ли данных?
— ФИО лежит в одной ячейке или в разных?
— В одной, всегда в первой.
— Телефон может быть только один?
— Нет, сколько угодно, вторая и последующие ячейки записываются как телефоны.
— Ограничение на их количество есть?
— Планируется, что их будет 1-2 в основном, но ограничения нет.
— Значит, первая ячейка в таблице - это ФИО, потом идут телефоны?
— Да, все верно
— Получается, что в файле нет "шапки" с комментарием, что в какой колонке хранится?
— Хм, да... Точно! Надо сделать так, чтобы первая строка вообще игнорировалась, пусть там будет комментарий
-—Данные могут быть только на одном листе excel файла или на разных?
-—Только на одном.
Уточним еще и ограничения на формат файла:
— Какие форматы excel-файлов должны поддерживаться?
— Все xls и xlsx.
— А в csv-файлах какие будут разделители?
— Любые — запятые, точки с запятой, "бомбочки" (ALT+0164 = ¤)...
— Хорошо, спасибо!
Вот теперь можно начинать тестировать
— Есть, капитан!
На собеседовании я даю кандидатам задачу с подвохом. В ней специально опущена часть требований. Я хочу посмотреть, будет кандидат задавать вопросы или бросится сразу
8 кандидатов из 10 начинают писать тесты и даже отмахиваются от моих ненавязчивых подсказок:
— А я Заказчик, можете задавать мне вопросы.
— Да зачем? Все понятно же! Сейчас напишу...
Это должно показать кандидата с лучшей стороны, вон какой старательный, вон как быстро может тестов придумать. Но это не так.
Придумать десяток тестов — легко.
Придумать десяток правильных тестов — намного сложнее.
Правильные тесты проверяют ровно то, что нужно. Ничего лишнего из того, что мы додумали по исходной постановке задачи, не уточнив правдивость своих размышлений.
Зачем все это нужно?
Думаете, мы просто издеваемся над кандидатами, а в реальной жизни такого не бывает? Как раз наоборот!
Всё просто. Заказчик находится внутри контекста своей проблемы и думает, что все знают то же, что и он.
Отличный пример был в летней школе тестировщиков в виде ролевой игры.
Заказчику надо решить конкретную проблему — сотрудников в фирме много, он не помнит все дни рождения и прочие важные даты. И хочет, чтобы исполнитель сделал систему, которая будет оповещать его об:
- отпусках (письмо за неделю до отпуска и в первый день);
- днях рождения;
- юбилеях (юбилей сотрудника + стаж его работы в компании).
Более того, Заказчик не будет говорить о том, что у него, кроме русских, есть китайцы и корейцы, он ведь об этом знает — исполнитель тоже должен знать! Или выяснять.
Разработчики не стали ничего уточнять и пошли решать проблемы, которые давно решены. Они продумали форму создания нового сотрудника и ее редактирования (которая у Заказчика уже есть и менять он ее не будет). Зато забыли про часть исходных требований, проигнорировав стаж работы сотрудника в фирме или второе письмо про отпуск.
Задача тестировщика — выяснить, что действительно нужно Заказчику.
Как выяснять?
Задавайте вопросы. Тестировщик должен понимать:- Какие данные есть на входе?
- Какие данные должны быть на выходе?
- Как эта штука должна работать?
Пример
Задача простейшая – проверить загрузку файла. Принимаемые форматы — Excel, csv. Нажимаем на кнопку “Выбрать файл”, загружаем файл, и по его данным сервер строит отчет. Данные представляют собой табличку: первая колонка — ФИО поставщика, потом телефон.
Уже можно бросаться писать чек-лист? НЕТ!
Сначала надо выяснить, что от нас требуется проверить, и какие данные есть на входе.
Обратимся к Заказчику:
— А что происходит с содержимым файла после загрузки?
— Данные о поставщиках сохраняются в базу, по ним потом будут строиться отчеты.
Ага, есть некая база с поставщиками, отлично! Это наводит на новые мысли и появляются новые вопросы:
— Что будет, если такой поставщик уже есть в базе?
— Неважно, дубли будем схлопывать потом, в следующей итерации.
— А если вместо ФИО или телефона передан беспорядочный набор символов?
— В следующих релизах будем с этим разбираться. Пока сохраняем как есть.
Важное замечание, иначе тестировщик может кинуться проверять десятки негативных тестов "что можно ввести в эти поля", которые не имеют смысла.
Ок, на выходе у нас ровно то, что и на входе, без дополнительных проверок, удаления мусора и прочего. А что у нас на входе? Достаточно ли данных?
— ФИО лежит в одной ячейке или в разных?
— В одной, всегда в первой.
— Телефон может быть только один?
— Нет, сколько угодно, вторая и последующие ячейки записываются как телефоны.
— Ограничение на их количество есть?
— Планируется, что их будет 1-2 в основном, но ограничения нет.
— Значит, первая ячейка в таблице - это ФИО, потом идут телефоны?
— Да, все верно
— Получается, что в файле нет "шапки" с комментарием, что в какой колонке хранится?
— Хм, да... Точно! Надо сделать так, чтобы первая строка вообще игнорировалась, пусть там будет комментарий
-—Данные могут быть только на одном листе excel файла или на разных?
-—Только на одном.
Уточним еще и ограничения на формат файла:
— Какие форматы excel-файлов должны поддерживаться?
— Все xls и xlsx.
— А в csv-файлах какие будут разделители?
— Любые — запятые, точки с запятой, "бомбочки" (ALT+0164 = ¤)...
— Хорошо, спасибо!
Вот теперь можно начинать тестировать
См также:
Тогда я вижу как минимум еще один вопрос. про конфигуратор csv, где то же мы разделитель должны установить.
ОтветитьУдалитьНе поняла вопрос :(
УдалитьЕще важно уметь задать вопрос так, чтобы Заказчик его понял. Иначе он ответит что-то типа "да это ненужно", чтобы не признаваться в том, что не понял, о чем речь
q
УдалитьЕсли б мне дали задание как у тебя в примере озвучено- я б тоже не стала задавать вопросов пока не перешла б тестам и не увидела сам продукт.
ОтветитьУдалитьКогда я проходила похожий собес меня настучали по голове за вопросы, хотя тоже говорили задавать можно.
А они как раз проверяли, насколько самостоятельно ты сможешь изучить продукт. Вы ж не первые и последние у кандидата- может его уже также настучали где-то и он просто пишет тесты строго по ТЗ.
Это тоже стоит учитывать, мне кажется.
Я опубликовала не наше задание, а другой пример :)
УдалитьМожно начать писать тесты, увидеть места потенциальных дыр в требованиях, записать себе вопрос, продолжить... В итоге задать в самом конце все вопросы разом. Но тут зависит от вопросов. Иногда задают вопросы, которые уже описаны в требованиях или которые можно самому найти, за такое можно и настучать по голове :) А в целом компании разные, но, если тестировщику стучат по голове за вопросы, я бы не хотела там работать...
Ольга, будет свободное время исправьте...
ОтветитьУдалить"исполнитель тоже доже знать!"
"Какие фораты excel-файлов должны поддерживаться?"
спасибо! поправила)
УдалитьЕще опечаточка
ОтветитьУдалить— Все xls и xlxs.
Поправила, спасибо)
УдалитьНа картинке землекоп лопату держит задом наперед))
ОтветитьУдалитьДа да, показывает неоптимальность своей работы!
Удалить"исполнитель тоже должне знать! Или выяснять"
ОтветитьУдалитьвыше комментарий был о поправке слова ДОЛЖЕН, но не "доправили" :)
значит было несколько)
Удалить