5 оправданий всех тестировщиков

Примечание: Я не имею в виду, что это относится к каждому тестировщику и каждой организации. Но я встречал достаточно примеров, чтобы так утверждать.

#1) Мы не контролируем нашу тестовую среду, мы имеем (читаем «очень») ограниченный доступ

Я часто слышу заявления / оправдания: «У нас есть только доступ для чтения». Или еще хуже: «У нас есть доступ только к журналам и ничего больше». Все остальное делается либо командой разработчиков, либо другой командой.

Работа, которая даст нам так много прекрасных и плодотворных идей в тестировании и многих других технических вещах, не делается нами. И, может быть, мы радуемся этому, но мы не должны.

Укажите мне одну причину, почему вы не должны контролировать свою тестовую среду и максимально использовать ваши преимущества.

Вот несколько возможных преимуществ, если вам интересно, о чем я говорю:

  1. Вы полностью контролируете свою тестовую среду, чтобы убедиться, что она точна или близка к копии производственной среды. Это поможет вам избежать сюрпризов, по крайней мере, когда ваши результаты достигнут определенного уровня.
  2. Вы знаете обо всех задействованных компонентах, программном обеспечении необходимого для работы вашего продукта. Со временем, поверьте мне, у вас будет много информации об их работе, ограничениях и возможных ошибках.
  3. У вас достаточно доступа для выполнения отладки хотя бы на начальном уровне. Например: установка работает медленно, проверка процессора, использование памяти — все это не наука о ракетах.
  4. У вас есть полный контроль, поэтому вы знаете, что вы меняете, и какую сборку вы развертываете. Вы будете гораздо увереннее, чем раньше, в своем продукте.

В этом есть смысл? Позвольте мне продолжить, если вы хотя бы согласились с тем, что есть хотя бы какие-то преимущества.

Теперь вопрос заключается в том, какие изменения вы можете внести в свою команду/ организацию для этого. И как именно вы это сделаете.

Ну, я не знаю. Я не знаю вашей команды, ваших лидеров / менеджеров и вашей организации, поэтому я не смогу вам помочь в этом. Я могу с уверенностью поделиться несколькими вещами, которые могут сработать. Вы должны пытаться работать очень тесно с вашей командой разработчиков и смотреть, что и как они делают. Все.

Способ входа в среду (сервер), способ выхода из системы и все с этим связанное. Когда вы получаете какие-то знания, вы сможете предпринять какие-либо действия, либо проконсультировать кого-либо, если что-то подобное произойдет снова.

Очевидно, что рано или поздно ваша уверенность будет замечена вашими разработчиками / руководителями / менеджерами. Это время, когда вы можете запросить контроль. И скажите мне одну серьезную причину, почему они вам этого не дадут? Они будут более, чем просто рады сделать это, если вы продемонстрировали необходимые способности.

Поверьте мне, у них гораздо больше работы, поэтому им не должно быть трудно дать контроль. По крайней мере, я надеюсь.

#2) Мы не развертываем сборку, какая-то другая команда делает это за нас

Вы приходите в офис утром в понедельник. Вы заметили, что в сборке возникает несколько проблем с блокировщиком. Вам нужна новая сборка из репозитория Build. Вы поднимаете запрос или связываетесь со своей командой разработчиков. Но они заняты чем-то. Они справляются со своим заданием и выполняют вашу просьбу через некоторое время.

Теперь скажите мне, почему все так происходит? Это не так сложно, как кажется.

Когда вам просто нужно сделать элементарные вещи, почему вы должны ждать или зависеть от кого-то.

Наличие возможностей и полномочий для развертывания в тот момент, когда вам это необходимо, облегчает вашу работу, без каких-либо ожиданий. Понимаете? Это также увеличит время выполнения вашей работы при ежедневном тестировании.

Позвольте мне рассказать вам кое-что из моего личного опыта. Речь идет не только о времени. Развертывание учит вас многим вещам, которые вы не можете себе представить. Приложение иногда перестает работать из-за нового кода. Много раз само развертывание терпит неудачу. И каждый раз, когда что-то терпит неудачу, это подталкивает вас к отладке. Это подталкивает вас искать что-то в Google или задавать кому-то вопрос или, лучше, задавать себе вопрос.

Это заставляет вас думать.

Конечно, это не тестирование программного обеспечения, но это, безусловно, проверяет ваши способности.

  • Я скажу, что большая часть моего обучения, помимо чистого тестирования программного обеспечения, связана с развертыванием и обслуживанием продукта.
  • Я не помню, сколько попыток проб и ошибок я выполнил для чего-то,  но количество должно приближаться к нескольким сотням.
  • Я не помню, сколько раз я перечитывал руководства по выпуску некоторых программ.
  • И я не помню, сколько раз я ударил эту кнопку поиска Google или перешел на эту ссылку.

Все, что я знаю, это многое мне дало, многому меня научило.

#3) Мы не отлаживаем проблему, мы находим шаги и регистрируем ее

Я не буду делать серьезный упор на этом. Но как в одном из интервью вы не получите шанс на повторное обсуждение конкретного дефекта из собственного опыта кандидата и поиска, отладок проделанных им / ее.

Однако я могу с уверенностью сказать, что не все из нас бросают себе вызов, прежде чем передать дефект разработчику на исправление.

Поэтому, пожалуйста, задавайте себе несколько вопросов прежде всего, а не помогайте разработчикам, делайте это для повышения скорости выполнения тестовых циклов, а также для собственного роста.

Ты здесь средство. Никто другой.

#4) Я не знаю, почему так вышло. Разработчик решил эту проблему, а я просто провел тест

Ох, да ладно. Извините, но это меня очень раздражает.

Каждый раз, это раздражает меня, когда я спрашиваю у тестировщика: почему был встречен конкретный дефект или что такое RCA (анализ корневых причин), и он / она отвечает «Я не знаю».

Как можно не спросить разработчика о том, что именно он исправил?

Поверьте мне, зная точное исправление, модуль, в котором было выполнено исправление, будь то во фронтенде или в бэкенде, независимо от того, было ли оно введено в любую конструкцию или какое-либо другое исправление дефекта, знание всегда поможет вам в тестировании. Всегда.

Помимо этого, эта информация поможет вам узнать много технических понятий, которые могут быть вам полезны, даже если вы никогда не столкнетесь с подобными проблемами.

Как дефект был исправлен? Интересуйтесь. Требуйте. Любыми путями.

#5) У меня не было другого выхода, кроме как работать с ручным тестированием

Возможно, это оправдание действительно в некоторой степени, учитывая возможную нагрузку на вас или ограниченные обязанности, но не в полной мере.

Проблема здесь заключается в том, что мы не имеем возможности выполнять нефункциональные типы тестирования, или мы не должны это делать, или у нас нет времени.

Понятно, обучение всегда требует времени. Но разве вы ничего не можете изменить?

  • При тестировании этой новой функции или при тестировании API, разве вы не можете следить за временем отклика?
  • Можете ли Вы спросить своего бизнес-аналитика о нагрузке, которую эта конкретная функция / модуль / API должна обрабатывать на производстве, чтобы вы могли ее протестировать?
  • Можно выполнить хотя бы базовые проверки безопасности, такие как время истечения сеанса, теневое копирование URL-адресов или обработка XSS в этой форме веб-сайта, которую вы должны проверить.
  • Можно протестировать кнопку «Отправить» или «Справка». Разве Вы не можете начать с чего-то незначительного, а затем продолжать изучать его все больше и больше?

Ответ: ДА, однозначно стоит.

Если это не входит в ваши обязанности (потому что для этого есть какая-то другая команда), никто не скажет Вам: “Хватит заниматься саморазвитием!”. Думаю, что самообучение в дополнительное или свободное время всегда возможно. Поэтому найдите это дополнительное время и начните делать это. Прямо сейчас.

Я обожаю QA и тестирование. Считаю, тестирование ПО является перспективным направлением в сфере IT, получить необходимые знания Вы можете на курсах тестирования ПО в Минске.

Записаться сейчас / Бесплатная консультация





Ваше имя (обязательно)

Ваш телефон (обязательно). В формате +375XXXXXXXXX