Испытательный срок закончился только вчера, а уже завтра вы приступаете к сложному проекту? Тестировщик Валентина Суслова расскажет, как не подвести команду и заказчика.
В тестирование я попала, окончив курсы по тестированию. Затем я успешно прошла стажировку и закрыла испытательный срок. Но настоящим испытанием и своеобразным посвящением в тестировщики стал один из моих первых проектов. На нем мне было поручено тестировать сложную программно-аппаратную систему. Не буду вдаваться в подробности. Скажу лишь, что у меня было три дня на изучение продукта, а далее – полноценная работа с отчетами заказчику.
Конечно, потом я была лишь благодарна за такое быстрое погружение в работу. Пройдя огонь, воду и медные трубы, теперь я готова ко всему. Однако поначалу было страшно и не хватало уверенности в том, что справлюсь. Но обо всем по порядку.
Немного расскажу про сам проект. Он связан с персональными видеорегистраторами для полиции США (камеры, похожие на те, с которыми ходят контроллеры в транспорте). Команда тестировщиков обеспечивала качество трех мобильных приложений, каждое из которых поддерживается на платформах iOS, Android, WindowsPhone; веб-приложения, шести десктопных приложений и программно-аппаратного комплекса под управлением Raspbian.
Для качественного тестирования всех компонентов необходимо было уметь пользоваться вспомогательными инструментами, иметь достаточно технических знаний и навыков. Например, для тестирования веб-сайта помимо навыков тестирования UI и функциональности нужно уметь работать с базами данных, понимать, как работает API и как тестировать веб-сервисы. Поскольку сайт располагался на облачном сервисе (Microsoft Azure), то также нужно было уметь управлять сайтом и его конфигурационными настройками через Azure. Кроме того, я должна была настраивать вручную расписание запуска функций, мониторить логи и нагрузку на виртуальную машину.
А для тестирования одного из десктопных приложений надо понимать, как устроены домены, Active Directory, уметь управлять пользователями и группами домена, уметь настраивать различные отношения между доменами.
Работа с таким количеством продуктов и технологий требует немалого объема знаний и умений. Но что делать, если ты никогда не работал на таких больших проектах или если ты новичок в тестировании, если у тебя нет достаточного количества технических знаний, а надо тестировать и писать отчет заказчику?
Совет 1. Задавайте вопросы
Самое важное, на мой взгляд, – это понимать, как и в каком окружении продукт используется реальными пользователями. Зачем тестировать дырку в стакане, если им никто не будет пользоваться? В тестировании как в физике: если сначала понять и увидеть физический процесс, то разобраться в уравнении будет интереснее и проще, чем если просто заучивать уравнение, не понимая, что оно описывает. Поэтому не стесняйтесь задавать уточняющие вопросы заказчику, чтобы сделать тест-кейсы максимально приближенными к реальным сценариям использования.
Совет 2. Тщательно изучайте продукт
На нашем проекте есть веб-сайт, на который можно загружать видеофайлы как с компьютера, так и с различных клиентов. В какой-то момент нам нужно было изменить метод загрузки файлов под один клиент. Если просто это сделать и при этом не учесть, что изменения могут сказаться на работе остальных клиентов, то может оказаться, что они просто перестанут работать. Необходимо изучать архитектуру проекта и взаимосвязь продуктов, проводить интеграционные проверки со всеми клиентами, с которыми планируется работа продукта, думать на пару шагов вперед.
Обсуждайте будущий продукт с разработчиками. У вас в голове должно быть четкое понимание всех функций и архитектуры программного обеспечения. Если есть какая-то проектная документация по архитектуре – обязательно изучите ее.
Совет 3. Общайтесь с коллегами
Своевременно заданный вопрос коллегам-тестировщикам или команде разработки поможет вам избежать фадов (от англ. FAD – functions as designed, т.е. спроектированная функция, которая по ошибке принимается за дефект). Очень часто начинающие QA-инженеры увидят лишнюю линию в 1 пиксель другого цвета в своем продукте и сразу же бросаются заводить дефект. А потом выясняется, что это был гениальный ход дизайнера со стороны заказчика.
Чтобы избежать подобных неловкостей, задавайте вопросы коллегам и разработчикам. Так и лишних дефектов не заведете, и ваш проактивный подход будет оценен заказчиком.
Стоит оговориться. Спрашивать нужно о том, что нигде не задокументировано и никак не гуглится. Излишние вопросы могут дать повод усомниться в вашей самостоятельности. Многие новенькие ребята часто дергают своих опытных коллег по поводу и без него. Это очень отвлекает. Поэтому прежде чем задавать вопрос, убедитесь, что ответа на него нигде нет.
Совет 4. Изучите все особенности процессов на проекте
Если вы окончили курсы по тестированию, то вы точно знаете стандартные правила описания дефектов. Однако каждый проект имеет свои особенности, и их нельзя упускать из виду.
Например, у нас на проекте есть правило: при заведении дефекта в баг-трекинговой системе нужно проставлять текущий спринт. Не раз у нас были случаи, когда инженеры забывали ставить спринт, и баг выпадал из всех фильтров. Обязательно узнайте, как на проекте описываются дефекты, какие есть обязательные поля, какая шкала используется для выставления приоритета и критичности.
Также разузнайте, откуда брать билды и как определять правильную версию, чтобы не пришлось делать двойную работу.
Совет 5. Предлагайте улучшения
Если процессы общения, отчетности, планирования на проекте настроены плохо, вероятность сорвать сроки релиза высока. Кроме того, специалисты устают от беспорядка. Поэтому если вам что-то не нравится или есть позитивный опыт с других проектов, то не молчите и предлагайте улучшения коллегам, менеджерам, заказчикам. Хорошее предложение не проигнорируют.
Например, на нашем проекте мне не нравилось, как настроены статусы задач в JIRA. Из “In Progress” (разработка) задача сразу попадала в статус “Waiting for QA”, даже если еще не была предоставлена на тесты. Однажды кто-то озвучил эту проблему, и её быстро решили. Тут пришло понимание того, что не нужно страдать молча. Нужно обсуждать.
Совет 6. Радуйтесь сложным задачам
Конечно, гораздо легче тестировать форму логина, а не разворачивать Active Directory и настраивать домен. Но тот, кто ищет легкие пути, никогда не вырастет профессионально. Радуйтесь сложным задачам, не отказывайтесь от них.
Во-первых, вы прокачаете свои технические навыки. Во-вторых, потом вам будет легко разобраться в более простых вещах. В-третьих, проекты со сложной бизнес-логикой помогут вам развить аналитическое мышление. Например, вы сможете написать 50 тест-кейсов вместо 10, обеспечив нужное покрытие.
Совет 7. Не переставайте учиться
Не все проекты требуют специфических технических навыков. Но никто не знает наверняка, когда и какие знания и умения вам пригодятся. Поэтому если в вашей компании есть возможность проходить обучающие курсы – не упускайте ее!
В свое время, начиная с испытательного срока, я активно посещала курсы в компании (изучала мобильное тестирование, тестирование веб-сервисов и т. д.), хотя в тот момент эти знания не требовались. Но когда пришла задача по тестированию методов API, знания с курсов по веб-сервисам очень пригодились.
Совет 8. Восхищайтесь!
Для меня это один из самых важных советов. Восхищайтесь. Восхищайтесь логикой проекта, восхищайтесь тем, кто придумал продукт, разработчиками, которые смогли идею превратить в реальное, работающее решение.
Если вы полюбите свой проект, то будете выполнять работу с удовольствием. Это и станет своеобразной защитой от выгорания.
Заключение
Подводя итоги, хочется сказать, что сложности – это не повод для паники.
Если вы будете понимать, как работает продукт и чего ждут пользователи; если вы будете любить проект и вносить свои предложения по улучшению; если вы будете общаться с коллегами и заказчиками, то сможете уверенно справиться со сложными задачами, заслужить уважение коллектива!