Тыщу лет назад.
Осень.
Я, безработный, «словно птица на сносях», иду собеседоваться в большую компанию.
А там на входе две анкеты «на адекватность».
Дадада, давайт сюдайт, адекватность — это же моё второе имя!
Первая анкета скучна, как радио «Шансон» в киевском варианте. Сто насущнейших вопросов из области программирования.
Что такое ООП, а вот предположим, что мы намазываем на бутерброд наследуемый полиморфизм, а в чем же насущная суть абстрактной сущности, а вот найди неправильный тэг в предлагаемом html-коде, а что б ты сделал, если б ты увидел молдавских коммунистов в церкви (ничего, это же неправильные коммунисты, они делают неправильный мёд), а кто такой тов. Стучка (один из организаторов коммунистической партии в Латвии с 1919 г.), а где теперь живет Карл Маркс (в сердцах пролетариата), и прочее…
Я отвечал этой занудной анкете честно, обстоятельно и неторопливо, мол, не брал я на душу покойников, и не испытывал судьбу, и не знаю я никаких ваших ООП, а вот этот тэг на html надо безусловно закрывать вот здесь, а тут тоже не знаю, и это пропущу, и тут я хз, а тут я вообще хз, и я начальник, спал спокойненько, и весь ваш МУР видал в гробу…
Вторая анкета поживее — сто вопросов про тестирование ПО. Там я тоже отвечал честно, обстоятельно и неторопливо, но тут уже, в отличе от первой, незаполненным не оставил ни одно поле.
Итого странная ситуация: коньдидатЪ продемонстрировал исчезающе мало знаний в программировании, но ВНЕЗАПНО оказался невероятно хорош в тестировании, набрал ~90% правильных ответов, каг же таг?
Разбираться со феноменом явилось двое тест-манагеров. Мое сопротивление было смелым, как атака кавалерии Келлермана под Ватерлоо, но таким же ненужным. Не суть, конечно, дело прошлое, но по итогу беседы мне был нанесён самый мощный coup de grâce в моей тестировщицкой жизни, о котором не забывается. Речь пошла про тестирование проекта, который вот-вот надо сдавать.
А именно: «А вот у вас проект, который вот-вот надо сдавать. Что вы предложите делать тестировщикам: проверять по тест-кейсам, или в свободном режиме потыкать проект, может и найдутся какие-нибудь баги?«
Я крепко подумал.
И ты подумай.
Саспенс же, ёпта.
Если проект уже надо сдавать, это означает, что времени — с гулькин, мгм, нос.
Будет ли возможность выпуска следующей версии ПО, в которой будут исправлены все баги, которые будут обнаружены после выхода на продакшн? Не знаю, молчат, не говорят.
Да, и непонятно, что в данном случае означает «выход на продакшн», бо я ж ни здоб ни здуб о том, какого рода проект происходит — он на сервере появится, или будет передан в разные офисы и установлен на разном оборудовании, а я ж хз, тестировались ли варианты «разного оборудования», и…
Ок, считаем, что другого шанса «сдать адекватный проект» не будет.
Можно заняться аналитикой: ещё раз пройтись по проекту и выяснить, все ли возможные сценарии работы приложения были продуманы и протестированы? Наверняка же не все… Но заниматься аналитикой перед финалом работы по проекту вобще?…
А если проект уже «надо сдавать» — это означает, что времени на багфиксы не будет?! Если в свободном поиске тестировщик найдёт что-то СТРАШНОЕ, то его свои же манагеры закопают у озера на Скулянке, лишь бы не сообщать в последний момент о том, что выходить в прод опасно…
Что-то хорошее в этой ситуации тоже нашлось — если проект «уже надо сдавать», это значит, что до сих пор тестировщики что-то в этом проекте ковыряли, и вероятно, уже не первый день, и вероятно, уже знают его очень хорошо. Знают сильные места, знают слабые места, знают то, о чем никому не надо говорить, знают то, что хочется развидеть, но без армии психоаналитиков мистер Крюгер все равно будет каждую ночь посещать и несчастного тестировщика, и несчастного девелопера, который всё это надевелоперил…
Но в свободном поиске уже изрядно переспавшие с этим проектом тестировщики найдут, скорее всего, тот самый гулькин, мгм, нос, бо какие перлины можно найти, если начать перелопачивать всё ту же кучу навоза, которую сами наделали и сполна перелопатили?!
Подскажу бесплатно: или найдутся какие-то безумно идиотские экзотические сценарии перехода с одного экрана на другой, или какие-то безумно идиотские экзотические сценарии выполнения каких-то расчетов, которые закрэшат софтину, и тогда манагеры поедут на Скулянку выкапывать из благословенного молдавского чернозема тестировщика, который хотя бы что-то да знает о том, где у этой софтины слабое место, в которое НЕ НАДО тыкать…
Нехорошее соображение: программисты не рекомендуют тестировщикам находить экзотические баги под самый финал проекта.
Некстати подумалось, что если рискнуть, то можно дальше не читать, просто знайте, что убийца — не садовник…
Поэтому вариант «А давайте в режиме свободного падения покопаемся в программе, может быть, и найдём что-то…» мне не нравится КОТЭГОРИЧЕСКИ. Многовато экзотики. Потенциально можно доказать, что программа обладает страшными недостатками, но можно ли доказать, что она делает то, что…
А, кстати, программа уже делает то, что должна делать, без ошибок? Нет информации. Предположим, что я заказчик, который не врубается в градации экзотичности багов, и хочет, соппсно, получить софт, который будет делать то, что ему нужно… И как водится, предположим, что тестировщиков в проект пригласили просто потому, что кто-то убедил заказчика в том, что тестировщики — прекрасные эмуляторы «конечного пользователя». Следовательно, самая важная информация, которая должна приходить от тестировщиков — будет ли удовлетворён конечный пользователь, а он будет удовлетворён в принципе потому, что программа будет делать то, что она должна делать…
Вернёмся к исходникам:
- проект «вот-вот» надо сдавать,
- дальнейшая работа над проектом не объявлена,
- у тестировщиков есть ТОЛЬКО две возможности:
- или проверять проект по тест-кейсам,
- или «тыкать проект» в поисках ранее пропущенных багов.
Ваше решение, фельдмаршал?
Решение такое: проверять проект по тест-кейсам.
Если есть время, то следует методично и последовательно убедиться ЕЩЁ раз в том, что программа делает то, что она ДОЛЖНА делать.
Палюбасу эта информация важнее всего.
Итого: мне сказали, что в последний момент перед сдачей проекта надо тыкать в свободном режиме в надежде поймать какой-нибудь неведомый баг.
Я отказался.
Мне отказали.
А удалось таки узнать какой был ожидаемый ответ? 🙂
Я не тот человек, которому сообщают причину отказа о найме ))
Да и если бы было о чем говорить, я все равно предложил бы в указанных обстоятельствах проверять проект по тест-кейсам, а не как они там сказали, что «нет, надо в свободном режиме».
Вопрос из серии «Стоят два стула: на одном пики точеные..». Если они ожидают на этот вопрос однозначный ответ, который они выбрали заранее, — то они «очень интересные люди», как любят выражаться англичане (наши обычно говорят «мудаки»).
Есть разные ситуации и разные решения для ситуаций.
Может, им мой нос не понравился. А может, суждение (оно не безусловно верное, хотя и сегодня мне оно кажется верным). А может, хз что ещё.
Всё это не делает этих мудаков мудаками 🙂 Может, сегодня там уже другие тест-манагеры, другие подходы, и вопросы на собеседованиях другие.
Хм. Я бы в первую очередь, наверное, сросил бы, а что от тестировщика, приглашенного к концу проекта, все-таки ожидают. Дальше старался бы попасть в ожидаение. Или отказался бы наотрез, если бы увидел, что по тем или иным причинам не потяну.
Так что я бы ответил(сделав умный вид и надув щеки, хотя я ни разу формально такой деятельностью не занимался), наверное, что начал бы я с написания краткого тест-плана и согласования его с заинтересованными лицами. Чтоб потом не получить негатива из-за того, что ожидаемую работу я не выполнил.
А то из такой постановки задачи вообще ничего не понятно. Тест-кейсов, допустим, вообще может не быть.
Подобные вопросы (с ограничением по предоставляемой информации) хороши тем, что можно наблюдать за поведением кандидата практически в естественной среде. О чем подумает? О чем спросит? На чём будет настаивать? Что постарается предусмотреть? Почему?
Тест-планы я в ту пору презирал 🙂
наверное они имели в виду только Positive testing в свободном режиме.
Имели бы ввиду, так и сказали бы, не?!
А было подозрение, что тест-менеджерам просто поставили задачу подготовки (и может еще и проведения) презентации работающего продукта перед представителями заказчика?
И что-бы не сфейлиться как в этом видео: https://www.youtube.com/watch?v=W0UaVwnOCmo# они, не долго думая, решили что потыкать в вободном поиске хорошая идея, вдруг чего-то да найдется…
Хотя, даже при постановке задачи проведения презентации, если подольше подумать, то правильным будет выполнять тесты по тесткейсам: прогнать тесты на презентационном окружении и скомпилить презентацию из шагов и данных тест-кейсов.