Задача инженера по тестированию — находить ошибки в программах и сообщать о них программистам, чтобы те могли их исправить.
Многие думают, что тестировщики для этого запускают программу сотни раз и пробуют разные варианты действий, но в жизни всё иначе. Рассказываем, что делает на работе инженер по тестированию и какие вообще бывают виды тестирования.
Что в компании ждут от QA-инженера
Задача QA-инженера, или тестировщика, — проверить продукт со всех сторон так, чтобы в нём не было ошибок и чтобы он работал так, как это было задумано.
В идеальной ситуации тестировщик должен заранее находить все недочёты, но в жизни часто бывает так, что ошибка или странное поведение появляется гораздо позже. Это связано с тем, что программой пользуется много людей, и по закону больших чисел кто-то из них сделает так, чтобы скрытая ошибка проявила себя.
Чтобы инженер по тестированию мог найти и описать все эти ошибки, ему нужны профессиональные знания и понимание продукта. С профессиональными знаниями всё просто: нужно уметь пользоваться редактором кода, системой контроля версий, программами для тестов и уметь общаться с разработчиками. С пониманием продукта уже сложнее: иногда, чтобы найти баг, нужно знать, из каких модулей полностью состоит проект и как они влияют друг на друга.
Чем лучше специалист будет знать, как устроена программа в целом, тем проще ему будет понять, что в ней происходит. От новичков этого не требуется, но, чтобы вырасти в профессии, инженеру по тестированию полезно познакомиться с разными командами, узнать, что и для чего они делают и как устроены разные компоненты. А ещё это пригодится для классификации ошибок: иногда баг, который кажется мелким и простым, может повлиять на работу других модулей и всё сломать.
Как проходит тестирование
Задача тестировщика — убедиться в том, что программа работает так, как описано в документации или справочниках. Если документации нет — то как написано в задаче в таск-трекере. Нельзя взять задачу в работу, если непонятно, что именно нужно протестировать. Может оказаться так, что продакт ждёт от тестировщика, что он просто проверит новый модуль сложения чисел, а тестировщик думает, что ему нужно заново составлять и проводить проверку всей программы в целом.
После изучения документации QA-инженер составляет тесты. Это могут быть как очень простые тесты, которые проще провести вручную, так и сложные интеграционные тесты, в которых участвуют все модули. Если до этого программа проходила тестирование и остались старые тесты, то их тоже нужно обновить — старые тесты могут просто не отловить ошибки после изменения кода.
В зависимости от позиции и квалификации тестировщика он либо делает ручные тесты, либо пишет автотесты и прогоняет код через них. После этого он смотрит на результат и записывает в отчёты, что прошло успешно, а где тесты сломались. В процессе инженер часто смотрит в исходный код, чтобы понять, как лучше составить тест и найти слабые места программы.
Виды тестирования
Подход к тестированию зависит от того, что именно и где нужно проверить. Если это новый модуль — подход будет одним, доработанная версия программы — вторым, а для новой версии API — третьим. При этом все такие ситуации можно объединить в четыре категории — иногда они выполняются последовательно, друг за другом, а иногда проводятся как самостоятельные тесты.
Статическое. Это самый начальный уровень тестирования — на нём проверяется документация и исходный код. Отличие этого этапа от код-ревью в том, что на код-ревью смотрится стиль и общий подход к написанию кода, а на статическом тестировании — насколько этот код соответствует документации и задачам. Бывает так, что в спецификации написано одно, а код делает совсем другое. В этом случае нет смысла его прогонять через тесты.
Динамическое. Здесь QA-инженер смотрит, как программа ведёт себя после запуска. Например, всё ли в порядке с потреблением оперативной памяти и процессора, что со временем отклика на запросы и что будет, если запустить сразу несколько копий. Это нужно для того, чтобы понять, адекватно ли работает программа с точки зрения ресурсов. Если в документации написано, что для работы нужно 100 мегабайт оперативной памяти, а программа не запускается даже при 200 свободных — где-то точно проблема.
Функциональное. Это то самое классическое тестирование, о котором все знают. На этом этапе пишут тесты и запускают автотесты, имитируют нажатие 100 000 клавиш в секунду, смотрят на трафик и проверяют работу программы со всех сторон. Сюда же относится и интеграционное тестирование, когда новый модуль проверяют на совместимость со старыми.
Нефункциональное. Сюда входит всё, что не относится к предыдущим этапам, в том числе и тестирование под нагрузкой. Ещё здесь проверяют, как программа работает на разных устройствах, с интернетом и без, с нестабильным интернетом или на очень медленном железе. Также программу могут проверить с точки зрения интерфейса — насколько пользователю будет удобно работать с ней и выполнять нужные действия.
Сколько ошибок в день находит тестировщик
На самом деле эффективность тестировщика зависит не от количества найденных ошибок (хотя это иногда важно), а от того, выполняет ли он поставленные задачи или нет.
Чаще всего всё устроено так: есть тикеты в баг-трекере, которые нужно закрыть, и есть примерный план на день или на неделю. Если во время проверки программы по очередной задаче багов не нашлось — отлично, если нашлись — тоже хорошо: их описывают и передают разработчикам. Если за день QA-инженер не нашёл ни одной ошибки, но выполнил все текущие задачи — он молодец.
Короче, у тестировщиков нет плана по ошибкам — нужно просто методично выполнять задачи и проверять софт.
Где научиться
Всё просто: приходите в Практикум на курс «Инженер по тестированию», и через 4 месяца вы уже тестировщик с опытом, проектами и портфолио. Всё знаете, всё умеете и понимаете, что нужно делать.
