К вопросу о любимой многими теме “приехал в США без профессии, щас быстро-быстро стану тестировщиком у портнова - и жизнь наладится”
Поиск багов не инженерная работа.Работа тестера (для понятности - quality engineer), должна начинаться как можно раньше и состоит в том, чтобы багов внесено было как можно меньше.
Искать баги постфактум это дорого и немного бессмысленно, примерно как писать юнит тесты на готовый код. 90% найденных постфактум багов отправляется в трэш или зависает в бэклоге годами. Либо у вас вотерфолл в худшем смысле этого слова. Поэтому и задания для тестировщиков должны быть другими.
Не протестить готовое ПО и не решить задачку из книжки про Фудзи.
Например я предлагаю кандидатам протестировать банкомат. Те, кто начинает с нажимания кнопок - джуниор-миддл, те, кто начинает задавать вопросы типа есть ли кэш-ин, где будет стоять - миддл-сеньор.
А когда человек начинает выстраивать модель системы с транзакциями, бэкендом, сетевыми протоколами тут уже совсем другой уровень. А поиск багов просто опускает их всех на один и тот же уровень плинтуса. Преимущество получают только те, кто на практике работал с похожим ПО.
Я очень со многими и много раз дискутировал на тему задания “поищите баги в нашей программе” и слышал эти аргументы миллион раз.
Я в принципе не понимаю, какое мнение можно составить о кандидате оставив его наедине с ПО без какого-либо контекста на несколько часов и получив в результате некий список дефектов, тоже в свою очередь вырванный контекста.
Не мне вам рассказывать, сколько времени иногда может занимать воспроизведение и локализация проблемы. Если вы считаете, что ваш проект сложный или ищете заранее лояльных к компании\продукту людей, дайте задание на дом с вменяемым сроком.
Мне, например, Skype давал на дом довольно объемное задание с развертыванием окружения на виртуалках, с сетями, шифрованием и скриптами - выполнять его было очень интересно. А вообще, лично мне хватает часа-полутора пообщаться с кандидатом над 3-4 задачками не связанными с нашим проектом, чтобы понять, что кандидат из себя представляет как инженер и как тестировщик.
Шо ви такое гойворите, какая область, какие специализации!
Введение: История возникновения профессии, в чем ее суть, наш курс
Тестирование Graphic User Interface в Windows и ВЕБ приложениях
Учебный проект: ResumeBuilder. Спецификация, тестирование Graphic User Interface, bug reports
Учебный проект: ResumeBuilder. Функциональное тестирование, Bug Reporting rules
Bug Tracking Databases: Elementool. bug reporting form; creating custom views; bug life cycle
Документация в тестировании ПО. Тест План, Тест кейс, Тест Дизайн.
Учебный проект Energy-Telecom: требования, назначение, GUI и функциональное тестирование
Energy-Telecom project: Testing WEB forms Американское резюме - формат, структура, типичные ошибки при написании
Сопроводительное письмо и вопросы на собеседовании
Например я предлагаю кандидатам протестировать банкомат. Те, кто начинает с нажимания кнопок - джуниор-миддл, те, кто начинает задавать вопросы типа есть ли кэш-ин, где будет стоять - миддл-сеньор.
Пример улыбнул… Я 3 года тестировала в том числе банкоматы. Ни разу, ни в каких сценариях не имело значения, где будет стоять банкомат
Хмм, не берусь утверждать, с wireless банкоматами я не сталкивалась. Это очень консервативная отрасль, а wireless - не самый надёжный способ передачи информации.
Ещё подумалось, что банкоматы, встроенные в стену, обслуживают сзади, а отдельностоящие - со всех сторон. Но это всё равно не важно в ситуации, когда вас поставили перед банкоматом и сказали “Тестируй”.
В любом случае, мне кажется, что автор не вполне корректен. Видимо, этим примером он пытается сказать, что даже для самого элементарного тестирования нужно знать параметры. А вот не всегда! Например, при smoke testing достаточно знать основные функции, а в случае с банкоматами мы все их знаем.
Ещё как имеет. Я вчера в уродском First Merit Bank извивался ужом, чтобы нажать нужную кнопку вверху-справа экрана, сидя в машине в их drive-in. Плюс какие-то уроды спрятали опцию “Cash withdrawal” в пункт меню “Other transactions”… фу.
По-поводу “где будет стоять”… Первое что пришло на ум - наличие и качество освещения. Если темно, то будет ли подсветка тех же клавиш? Если просто в открытом месте, то в определенное время суток, будет ли достаточно яркости экрана чтобы пробиться через блики? И это только так, навскидку…
Еще в свое время ходили байки, как проводят (проводили???) интервью в Майкрософт. Давалось задание - узнать погоду наибольшим количеством способов. Естественно, первое, что практически все говорили - выглянуть в окно. Потом “посмотреть на компьютере” (или телефоне). Позвонить знакомым. Спросить у входящих. Постепенно вводились ограничения, типа “ты в комнате без окон”, “компьютеры не имеют выхода в Интернет” и так далее. Тест чисто на то, что называется “мышление вне коробки”.
Мне кажется, автор текста банально гнет пальцы и никогда не руководил проектами. Говорить о сферическом тестировщике в вакууме, в отрыве от бюждета на оплату, времени на найм и реально доступных на рынке кандидатов, смысла нет.
Представьте директора школы, который на место физрука ищет олимпийского чемпиона, а на места учителя физики - нобелевского лауреата. Или представьте Сталина осенью 41-го, который вместо переброски “сибирских” дивизий просматривает горы резюме в поиске спейс труперов.