Тестирование — это процесс оценки программного приложения, а тестировщики — это профессионалы, которые участвуют в этом процессе. Они решают множество задач: пишут тест-кейсы, сообщают о найденных багах, настраивают среду, работают с требованиями и так далее. По данным исследования, рынок тестирования программного обеспечения уже превысил 40 миллиардов долларов США и, как ожидается, к 2027 году вырастет ещё на 7%. Тестировщики должны знать языки программирования, инструменты управления тестированием, инструменты автоматизации тестирования, обладать навыками управления проектами и многими другими навыками.
Теперь давайте обсудим, почему тестировщики нужны? Почему разработчики не могут сами тестировать свой код? Ответ на этот вопрос аналогичен тому, почему студенты не проверяют и не оценивают свои ответы на экзаменах самостоятельно. В этом случае вопроса «почему» не возникает, ведь студенты не смогут самостоятельно оценить свои ошибки. Точно так же и разработчики не могут найти ошибки и просчёты, которые они могли допустить. В этой статье поговорим на эту тему более подробно.
Причины, по которым разработчики не могут быть хорошими тестировщиками
1. Отсутствие большого опыта работы с типичными багами
Это одна из самых важных причин. Опытный тестировщик имеет чёткое представление о типичных багах, которые могут вызвать проблемы в будущем и на которые необходимо проверить продукт в первую очередь. Если у разработчика нет такого опыта, он будет просто делать «случайные выстрелы», которые могут помешать работе всего приложения. Таким образом, отсутствие опыта непосредственно в тестировании — первая причина, по которой разработчики не могут быть хорошими тестировщиками.
2. Разница в подходах
Разработчики работают из перспективы создания приложения. Обычно они анализируют проблему и разбивают её на более мелкие части, чтобы найти наилучшее решение. В то время как тестировщики работают из перспективы что-то сломать или найти недостатки в приложении. А значит, тестировщики должны мыслить нестандартно и проверять все возможные варианты развития событий, ставя себя на место клиента. Их действия направлены на то, чтобы приложение не сломалось, как только оно начнёт работать.
3. Материнская привязанность к своему коду
Будучи обычными людьми, мы испытываем привязанность ко всему, что создаём. Лучше понять это можно на практическом примере: с точки зрения вашей матери, вы — самый лучший. Если вы сделаете что-то не так, она начнёт ссылаться, например, на плохое влияние ваших друзей, ведь в её глазах вы идеальны. Это может показаться глупым, но разработчики испытывают привязанность к своему коду, а это затрудняет поиск недостатков или багов.
4. Разные люди будут выполнять тесты по-разному
Это ещё одна причина, по которой нам нужны независимые тестировщики для тестирования приложения. Разработчик может действовать по одной и той же схеме:
Ввести имя
Ввести адрес электронной почты
Ввести почтовый адрес
Добавить номер телефона
Проверить и нажать OK
Подобный подход использовался при создании приложения. Но тестировщик может действовать нестандартно (как и реальный пользователь), например:
Пропустить имя
Добавить адрес электронной почты в поле адреса
Добавить адрес в поле почтового индекса
Оставить какое-либо поле пустым
И затем нажать кнопку OK
Тестировщик будет пробовать различные комбинации, чтобы проверить, работает ли приложение в соответствии с ожиданиями или нет. Другой тестировщик проведёт тесты по-другому и убедится, что приложение безопасно, не содержит багов и готово к релизу.
5. Фокус на позитивных сценариях
Разработчики обычно работают над реализацией и редко находят ошибки в существующем коде. Они позитивно относятся к коду, и их неспособность найти баги приводит к тому, что они не могут быть хорошими тестировщиками; в то время как тестировщики работают над проверкой кода в негативных тест-кейсах и над повторной проверкой. Тестировщики размышляют о том, что может пойти не так. Разработчики — полная противоположность тестировщикам.
Итак, мы постарались объяснить причины, по которым разработчики не являются по умолчанию хорошими тестировщиками. Но нет такого навыка, которому мы не могли бы научиться. В следующем разделе мы поговорим о том, как разработчики могут внести свой вклад в процесс тестирования.
Как разработчики вносят вклад в процесс тестирования?
Чтобы уменьшить количество ошибок, разработчикам стоит придерживаться в своей работе некоторых практик.
1. Относиться к тестированию серьёзно
Agile-подход подразумевает, что код тестируют и разработчики, и тестировщики. Это обеспечит высокое качество кода и надёжность приложения. Начните относиться к тестированию серьёзно и посвятите некоторое время изучению необходимых навыков.
2. Работать над своими слабыми местами
Будучи разработчиком, вы по-другому относитесь к своему коду. Постарайтесь проанализировать свои слабые места и начните работать над ними — это поможет вам выполнять свою работу гораздо лучше. Если необходимо, обращайтесь за помощью к тестировщикам.
3. Постоянно пополнять свою базу знаний
Лучший способ удержаться в ИТ-индустрии — постоянно совершенствовать свои знания. Ваш код — это как ваш ребёнок, поэтому вы должны заботиться о нём. Старайтесь расширять свои знания в области тестирования, чтобы свести к минимуму количество багов и повысить производительность.
Итак, надеюсь, мне удалось прояснить, почему разработчики не являются хорошими тестировщиками по умолчанию и как они могут внести свой вклад в процесс тестирования. Ведь разработчики и тестировщики — это две разные стороны монеты с разными навыками.
В заключение приглашаем всех начинающих тестировщиков на открытые уроки, которые пройдут в Otus в рамках онлайн-курса "QA Engineer. Basic":
4 июля: Как тестировать веб-приложение. Запись по ссылке
17 июля: Тестирование серверной части (бэкенда). Запись по ссылке
Комментарии (9)
AnotherAnkor
02.07.2024 10:20+1Тестировщик не должен проверять всё. Иначе протестировано будет ничего. Писал кто-то не из профессии?
onets
02.07.2024 10:20В школе еще было - «передайте тетради соседу по парте и проверьте на ошибки».
Когда проверяешь сам у себя - глаз замыливается, чсв не позволяет («да тут все норм должно быть»), скучнее, чем кодить.
Vitimbo
02.07.2024 10:20Не знаю, работает ли это на тестировании ПО, но с соседом по парте всегда можно договориться :D
metalidea
02.07.2024 10:20+1На самом деле работает схема - тестировщик написал тест кейсы, по которым проверять, а разработчик прошелся по ним и проверил.
Тест кейсы можно писать до разработки (или во время) по макетам фигмы и/или спекам.
s37
Забыли важный момент: разработчик получает за написание кода (символы, строки, часы, проектно и т.п.), а тестировщики за тестирование (найденные баги, часы, проектно и т.п.). Вряд ли эти два формата можно совместить так, чтобы разработчик остался не в накладе. На начальных и простых задачах, возможно, что это будет работать, а на сложных вряд ли. К тому же в пункте 1 «Отсутствие большого опыта работы с типичными багами» вы сами написали о том, что фактически человеку нужно как бы освоить одновременно две профессии, а это тяжело. А где-то после такого вот «повышения квалификации» можно скатиться до it-разнорабочего, пускай и с большой зп (это я и личного опыта знаю).