Первая глава книги "Искусство тестирования программ" Гленфорда Майерса начинается с предложения пройти тест для самооценки. Задача состоит в том, чтобы проверить некоторую программу. Для этого предлагается написать на листе бумаги набор тестов (то есть специальные последовательности данных), которые будут адекватно проверять программу. Затем Гленфорд приводит примеры тестов, которые позволят оценить читателю эффективность самостоятельно придуманных тестов. Автор подводит итог главе, что если вы не программист, то вы не очень хорошо справитесь с составлением теста. Опытные профессиональные программисты набираются в среднем только 7-8 очков из 14 возможных. "Выполненное упражнение показывает нам, что тестирование даже тривиальных программ, подобных приведенной, - непростая задача".
О том, как неправильно можно использовать эту задачу рассказал mike1999 в форумной теме Задача - тестирование подсчета типа треугольника. В рассказе не столько про тестирование треугольника, сколько про правильный подход про процедуру решения тестовых задач на собеседованиях:
Я вот в тестировании 8 лет, на текущей работе уже тест-лид, сам собеседовал не раз. Решил сменить компашку, до этого собеседования нигде не проходил. И что вы думаете - на первом же интервью мне выдают задачу (дословно): "- Составьте, пожалуйста, список тестов для функции на входе которой три параметра, а на выходе треугольник". Повторяю - это была дословная постановка задачи. И с умным видом он откинулся на спинку кресла.
Это мне предложил технарь из компании "Открытые технологии"... Я вот конкретно эту задачу не встречал, и догадаться что за параметры передаются в функцию не мог. Попробовал было задать наводящие вопросы, что мол за значения в параметрах? (ну там длины это или тройки координат в пространстве) на что был ответ - типа "...вы мне скажИте какие это параметры..." ... Что за параметры, что за треугольник на выходе? Попробуй догадайся.... Ну я ему совставил кейсы для троек координат в пространстве (отголоски текущей работы)...
К чему это я... А да... товарищи собеседующие кандидатов, прежде чем тестить кандидата потрудитесь вникнуть в суть задач. Оригинальная задача звучит так: "Составьте список тестов для функции, в которую передается три значения длин, а на выходе функция выдает - одно значение boolean - true, если существует треугольник со сторонами такой длины, и false если не существует".
В случае если функция до кучи определяет тип треугольника - половина ответов, что тут написана - полная бредятинаю. 50 кейсов это заява от кого? Кто-нибудь вообще слышал об избыточности тестов? С таким подходом тестирование по стоимости будет в несколько раз дороже всего остального проекта + все как макаки уперлись в этот треугольник, никто даже не заикнулся про проверки максимальных значений, про проверку требований, явных, неявных, производительность... мы функцию проверяем, а не треугольник...
Опять же к чему это я... а да... на собеседовании постарайтесь не бросаться на составление максимального числа перестановок и конкретных значений. При любой задаче на составление тестов уточните непонятные моменты, составьте микро тест-план, составьте микро-список требований, разделите их на приоритетные и нет, постройте в голове маленькое оглавление для сценария, например: смок, функционал, производительность, юзабилити (+ эргономика), безопасность, окружение... И тд, все виды и подвиды, какие вспомните, далее по каждому пункту определите нужен он или нет. Далее наиболее критичные тесты. Не бойтесь записывать. При таком подходе грамотный собеседующий технарь увидит что вы умеете думать, а не тупо выписываете все возможные комбинации из трех чисел.
Как пример, периодически даем на проверку кандидату форму доступа путем ввода пятизначного цифрового пароля, для сенсорного терминала, и просим "на лету" протестировать и составить отчет. Форма намеренно заторможена на нажание кнопки "0" - пауза секунд 5. Правильный пароль известен. На форме цифры, спецсимволы,"Отмена", "Вход", "Язык", у тестера есть возможность задать правильный пятизначный пароль обычным апдейтом на рядом стоящем компе. Все кидаются проверять и перебирать пароли.
Как результат : Половина не замечают тормозов, другая половина, замечает, матерится на тормоза, но в отчете не указывает. Половина вводит только пятизначные значения. Половина вводит только цифры. 95% не проверяют вход при пустом пароле и вход с пустым паролем. О комбинациях (0/NULL) я уже не говорю. 95% не проверяют кнопку "Отмена". 95% не уточняют может ли пароль содержать спецсимволы с клавиатуры терминала. Один человек за три года проверил смену языка. Никто не проверяет добавление к правильному паролю других цифр и спецсимволов. Никто не проверяет обрезанный с конца пароль.
И при этом все кандидаты надрочены на логические задачи про треугольники и лампочки, а если задачек не дают, то на лице истинное разочарование - как же так я ведь весь интернет прочитал, а вы меня совсем не то спрашивали...
Ох скока я понаписал...
19.08.2017