Руководитель QA-отдела компании STH Махеш С. в своей недавней статье рассказал, как он прошел путь от начинающего тестировщика до менеджера.
Все началось довольно неожиданно. Я пришел на собеседование с мыслью о том, что в дальнейшем непременно перейду на должность разработчика. Как и многие выпускники кафедры информатики, к тестированию я относился скептически. Но все же решил попробовать. Я не мог не спросить у представителей компании, будет ли у меня возможность перейти в отдел разработки, если тестирование мне не понравится? Но впоследствии даже не задумывался над тем, чтобы оставить работу в тестировании ПО.
Во время первого теста я знал только теоретические основы. Сложилось впечатление, что нас новичков оценивали с точки зрения логики, а не теории. Сегодня и я прибегаю к такой технике, когда нанимаю вчерашних выпускников. В первую очередь обращаю внимание на их логическое мышление и подход к решению проблемы.
Я стал работать в Zycus в качестве практиканта в отделе QA. На третий или четвертый день мне выдали продукт. Это была одна из самых амбициозных разработок компании (точнее, ее концепт). Проработал три недели — и мне понравилось. За первые два года я в общей сложности обнаружил около 3 тысяч дефектов в таких категориях: функциональность, производительность, безопасность, UI, юзабилити, мультиязычность, мультиарендность и пр.
Тестированием занимаюсь уже шесть лет. Работаю старшим QA-менеджером, сейчас мы тестируем 5-6 программных продуктов и модулей. Но больше всего мне нравится то, что я возглавляю команду из 30 энтузиастов. Конечно, мне помогали, но все же знания и опыт я приобрел благодаря упорному труду.
Содержание
«Опыт — лучший учитель»
Как я действовал в различных ситуациях
#1) Важность понимания бизнеса
В тестировании важно предвидеть каждый из возможных сценариев, даже самых редкие. Для этого, ко всему прочему, необходимо понимание бизнеса в целом. В моей работе важно иметь представление о сложных сценариях.
Прежде чем прийти на встречу для обсуждения требований, я заранее составлял список возможных сомнений/исправлений/спорных моментов. Я записывал сценарии, которые хотел бы опробовать или составить на их основе тест-кейсы. Часто мне помогало простое описание на листке. Когда вы записываете сценарии, они становятся более понятными. Затем, исходя из этой информации, составляете дополнительные сценарии, еще и еще. До тех пор, пока не возникнет ощущение сделанной работы.
#2) Работа в сложных условиях
Однажды я тестировал продукт, над которым в течение трех лет работала команда из 30 инженеров. На начальном этапе разработчиков было 15-20 человек: junior, mid-senior и senior. Все они неустанно добавляли новые элементы. Параллельно работала команда тестировщиков, которая оценивала жизнеспособность всех этих новшеств. На то время я еще не был знаком ни с одной методологией, передовыми решениями или пособиями, которые облегчали бы работу.
Я лишь повторял раунды исследовательского тестирования (тогда еще даже не знал этого названия) для каждой функциональной особенности. Нужно было делать все очень быстро. Но такой подход был вполне эффективен.
Пример. Тестирование текстового окна
Что можно проверить:
- Сохраняются ли вписанные данные
- Валидация типа данных
- Валидация максимальной длины
- Реакция на ввод специальных символов
- Пустые поля/отсутствие данных
- Ввод данных на других языках
- XSS
- Поведение кнопок tab и enter
- Обработка ошибок (в разных браузерах)
- Выравнивание интерфейса (в разных браузерах)
- Функция копировать/вставить данные /перенос ссылок в текстовое окно
- Как ведет себя поле относительно других разделов программы (автозаполнение этими данными других форм)
#3) Эффективность подсчитывается, опыт — нет
Поначалу руководство сравнивало меня с опытными тестировщиками. Думаю, многие оказывались в подобных ситуациях.
Но единственным верным решением было — двигаться вперед и эволюционировать, не задумываясь о том, что опыта мало. Мне помогла книга Робина Шармы «The Leader Who Had No Title». Благодаря ей я смог раскрыть свой внутренний потенциал. Если описать мой опыт в нескольких предложениях, это будет выглядеть примерно так:
«Любопытство, внимание к деталям, дисциплина, логическое мышление, работоспособность и аналитические способности — главное в работе тестировщика. Если вы обладаете такими качествами, успех придет».
Но вместе с тем я не утверждаю, что личные качества важнее глубоких теоретических знаний. Просто хочу сказать, что успех зависит не столько от информации, которую приходится усваивать, сколько от внутренних качеств человека. Но чтобы зайти достаточно далеко в какой-либо сфере, нужно извлекать уроки из полученного опыта.
В моем случае приходилось учить терминологию, концепции, теории. Ведь тестировщики используют специфические термины и профессиональный жаргон.
Учиться новому
Мне приходилось учиться новым видам тестирования и тому, как объяснять определенные вещи своей команде. Нужно было правильно оценивать новые идеи, инструменты. Руководители в обязательном порядке осваивают новые концепты и методологии.
Вывод
В тестировании довольно сложно подобрать нужные определения, чтобы все доступно объяснить. Некоторые превосходно тестируют программные продукты, но не могут найти подходящие слова, благодаря которым другие могли бы осмыслить их работу.
Определений тестирования множество. Я остановился на таком: «Тебе дают вещь — ты находишь ошибки и делаешь эту вещь лучше».
Не обязательно знать громадный объем теоретического материала, сложные метрики или ISTQB, чтобы быть хорошим тестировщиком. Куда важнее пытливый ум, целеустремленность, энтузиазм, логическое мышление и аналитические задатки. Но, конечно, дополнительные знания никогда не помешают.
Важно уметь планировать тестовые сессии, выбирать верный подход. Как следствие, приходится осваивать новые инструменты, техники и методологии.
Тестирование не стоит на месте. Значительная часть организаций, которые этим занимаются, применяют более практические методики, такие как, например, исследовательское тестирование.
