Я тестировщик, и при тестировании я всегда открываю в браузере инструменты разработчика (devtools). В основном я смотрю вкладку “Сеть” (Network): какие запросы уходят, с каким содержимым и что возвращается. Если запросы падают с ошибкой, это тоже видно здесь. Или, если запросы выполняются очень долго, это тоже можно отслеживать.
Реже смотрю “Консоль” – здесь могут быть ошибки JavaScript на фронтенде. Во вкладке “Элементы” виден весь HTML и CSS код. Однако, я редко заглядываю в “Элементы”, так как в моей практике тестирование UI занимает не более 20% времени. Все мои проекты – это веб-приложения с максимально простым интерфейсом, для которых нет детализированных макетов, и где адаптивная верстка практически отсутствует.
Я тестировщик, и при тестировании обычно открываю браузер в режиме инкогнито. Мне важно, чтобы страница загружалась каждый раз заново, а не подтягивала данные из кэша. Кстати, сбросить кэш – это моя мантра перед тестированием UI изменений и в целом фронтенд-части приложения.
Я тестировщик, и у меня всегда открыт Postman – инструмент для отправки запросов на бэкенд. Иногда нужно проверить какой-то запрос отдельно, без фронтенд-части приложения, или дернуть запрос какой-нибудь джобы, или сымитировать интеграционный запрос в приложение.
Я тестировщик, и у меня всегда есть подключение к базе данных. Смотреть в базу данных при тестировании бэкенда – это база. Если с фронтенда уходит запрос на создание или изменение данных, после его успешного выполнения я всегда проверяю, что записалось в базу данных. Если с фронтенда уходит запрос на получение данных, я сравниваю то, что вернул запрос, с тем, что записано в базе данных. Таким образом проверяется логика на бэкенде.
У меня есть файл, в котором я сохраняю полезные запросы, чтобы не писать их каждый раз. А вообще, разбираться в структуре базы данных своего проекта (хотя бы знать основные таблицы, где что хранится) – это тоже база.
Я тестировщик, и я умею тестировать базы данных отдельно. Для кого-то это может быть открытием (как когда-то для меня), но в базе данных тоже можно писать логику. Например, можно создавать процедуры и триггеры. То есть, при изменении одной таблицы будет срабатывать триггер, который будет запускать процедуру, вносящую изменения в другие таблицы по определенной логике. Также процедуры могут запускаться по расписанию. Эти триггеры и процедуры пишет разработчик, и, конечно, их нужно тестировать отдельно, причем можно делать это без бэкенда и тем более фронтенда, только на базе данных.
Я тестировщик, и я умею читать логи, и читаю их. Логи – это очень важная часть для отладки, тестирования и локализации дефектов. Если в коде есть какая-то ошибка, или, тем более, упал запрос с фронтенда, в логах это будет видно. Будет видна сама ошибка и ее стек-трейс. По названию ошибки можно понять ее суть, а по стек-трейсу разработчик может понять, какой именно метод упал первым и какие методы вызывались после него. Также в стек-трейсе может быть указана причина ошибки. Ошибка никогда не возникает изолированно: одна ошибка обычно тянет за собой другую, и по цепочке падает целая группа методов, что в итоге и возвращает ошибку в запросе.
Так вот, разобраться в первоисточнике иногда бывает сложно. Если в логе указана причина падения первого метода в цепочке, это сильно упрощает локализацию. Например, это может быть что-то вроде: “неизвестное значение” (когда фронтенд в каком-то ключе отправляет не то значение, которое ожидает бэкенд), “не удалось преобразовать тело запроса в объекты” (когда структура запроса невалидна), “неверный запрос к БД” (когда, например, в сложном запросе к БД отсутствует какая-нибудь скобка).
Одна из самых частых ошибок – это ошибка, связанная с Null, когда переменную, в которую попал null, пытаются как-то обработать. Null может появиться из базы данных, там, где бэкенд его не ожидает, или прийти с фронтенда, где бэкенд ждет какое-то значение, или появиться в результате неверного выполнения какого-то предыдущего метода в коде. Все это, конечно, нужно изучать в конкретной ситуации и разбираться, кто виноват и что делать.
Также логи могут быть полезны для тестирования сложной логики на бэкенде, даже если ошибок никаких нет, но, допустим, логика отрабатывает неверно. В этом случае, конечно, важно, чтобы разработчик заранее позаботился о том, чтобы самые важные шаги этой логики были залогированы. Так как не все логируется по умолчанию, что-то нужно логировать самому. Это тоже часть работы разработчика при проектировании новой фичи: определить, что, где и в каком объеме залогировать, чтобы самому же потом не сидеть ночами с тестировщиком и бутылкой, пытаясь понять, почему что-то отрабатывает неверно.
Я тестировщик, и я умею пользоваться консолью, знаю основные команды: могу проверить сетевые настройки, могу управлять запущенными процессами, работать с файловой системой и, да, я умею выходить из vim редактора.
Я тестировщик, и знаю основные принципы работы Docker-контейнера и виртуальных машин. Могу подключиться, зайти внутрь контейнера и сделать какие-то базовые действия.
Я тестировщик, и знаю основы программирования. Я изучала Java достаточно глубоко, но принципы объектно-ориентированного программирования работают на любых языках. Я могу написать простой скрипт на Python, на JavaScript (например, в Postman) или написать тест на Java (что я, собственно, изучала).
Я ручной тестировщик, однако я знаю, как пишутся автотесты, на какие проверки они пишутся и для чего в целом они нужны. Я умею их запускать, анализировать результат и вносить какие-то минимальные правки и доработки.
Я ручной тестировщик, но я немного разбираюсь в нагрузочном тестировании. В своей работе мне приходилось сталкиваться с тем, что какие-то сложные запросы к БД или процедуры могут замедлять работу всей СУБД, что сказывается на работе всего приложения: оно будет тормозить и сыпать ошибками. Также какие-то сложные обработки в коде, например, запускаемые по расписанию, могут нагружать оперативную память и процессор, что неизбежно вызовет торможение и, возможно, вообще падение приложения. Все эти узкие места нужно отслеживать и ловить до попадания их в прод. И если не пректе нет нагрузочнрго тестировщика, это работа ручного тестера.
Я тестировщик, и мое слово последнее в вердикте о готовности задачи к релизу. Это, конечно, не значит, что не полностью готовую задачу не пустят в релиз без моего разрешения, так как бизнес есть бизнес, и качество не всегда стоит на первом месте – там еще есть сроки, контракты, деньги, репутация, законы и прочее. Но все же, при прочих равных, мое мнение важно.
Этой статьей мне хотелось бы показать, насколько на самом деле сложная и глобальная профессия — тестировщик. Она требует достаточно обширных технических знаний, определенного склада ума, практических навыков и насмотренности. Заменить тестировщика не так уж и просто. Если на проекте его начинают заменять разработчики или аналитики, то уже после первого релиза это станет заметно из-за увеличения количества пропущенных дефектов.