Пока нет оценок.
Пожалуйста, подождите...

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

Только осознание негатива или плохих факторов позволяет изменить жизнь и/или карьерные достижения.

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

Плохой QA-инженер

Плохой QA-инженер

Как определить, что тестировщик – хороший специалист/человек?

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

Человек с подобными характеристиками всегда будет успешен на проекте и внутри определенного корпоративного сообщества (например, положительное мнение о нем будет звучать далеко за пределами его компании по обеспечению качества).

И наоборот

Теперь рассмотрим другую ситуацию, когда отдел контроля качества состоит из нескольких плохих тестировщиков. Если описывать их несколькими словами и словосочетаниями, то можно использовать такие комбинации, как:

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

Характеристики плохого QA-специалиста

1. Плохой уровень коммуникации с другими сотрудниками

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

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

Ситуации, которые могут привести к плохой коммуникации:

  1. Пробелы в технической документации;
  2. Внутренняя боязнь принятия решений;
  3. Низкий уровень моральной культуры;
  4. Ощущение уязвимости;
  5. Отсутствие необходимого уровня технической подготовки.

2. Пробелы в технических познаниях

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

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

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

В свою очередь, на пробелы в технических познаниях влияют такие факторы:

  1. Отсутствие практических знаний;
  2. Недостаток внутреннего желания технически развиваться;
  3. Отсутствие программ по повышению квалификации.

3. Составление баг репортов без аналитики

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

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

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

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

4. Несоблюдение стадий контроля качества

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

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

Далее будут приведены некоторые примеры подобного несоблюдения стадий контроля качества:

  • Игнорирование установленного шаблона для создания тестовых артефактов;
  • Невыполнение процедуры рецензирования;
  • Использование старой версии технической документации из-за нежелания просматривать версии документов.

5. Выполнение тестирования на основе предположений

Есть масса методик, согласно которым тестировщик выполняет проверку ПО. Подобные постулаты основываются на определенных предположениях технического и нетехнического характера. И если данные предположения будут исходить из ложного представления о корректной работе ПО, есть вероятность, что QA-специалист может пропустить баги.

Никогда не нужно выполнять тестирование веб-продуктов исключительно на собственных предположениях. Стоит четко уяснить технические требования проверки как от разработчиков, так и от привлеченных бизнес-аналитиков.

Если тестировщик не до конца уверен в верности выполняемых манипуляций, он должен переспросить и уточнить. Иначе есть риск, что пропущенный дефект будет стоить проекту больших временных и/или финансовых затрат.

6. Отсутствие подхода “Test to Break”

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

Тестер изначально должен выработать в себе понимание того, что в ПО есть баги и их придется искать с особой тщательностью.

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

На подход “Test to Break” влияют следующие факторы:

  • Отсутствие должного внимания при тестировании;
  • Тестирование только нормального или приемлемого поведения ПО;
  • Неиспользование методик исследовательского тестирования.

7. Застой технических навыков тестирования

Область IT трансформируется каждый день и очень много новшеств в сфере тестирования становятся общепринятой практикой. Полная ответственность за слежением в области тестирования ПО ложится на QA-специалиста.

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

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

Определенный уровень стагнации навыков тестировщика происходит из следующих факторов:

  • Нежелание покидать рабочую зону комфорта;
  • Слабая активность в новинках и трендах сферы тестирования;
  • Чувство выполнения монотонной работы;
  • Нет уверенности в том, что выполняете работу, которая вам по душе.

8. Непонимание требований и пожеланий клиента

Без сомнений, именно QA-специалист обязан тестировать должное функционирование программного обеспечения в соответствии с требованиями клиента.

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

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

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

9. Техническая небрежность

Иногда тестировщики, как и другие члены команды, могут лениться во время проверки ПО. Если подобное происходит очень часто, это может негативно повлиять на репутацию QA-специалиста.

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

Наиболее распространенные небрежности при тестировании программного обеспечения:

  • Пробел шага в тест-кейсе;
  • Отсутствие скриншотов там, где они должны быть;
  • Природа дефекта описана не в полной мере.

Как не стать плохим QA?

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

Чтобы не допустить влияние подобных описаний на вас, будьте максимально целеустремленными, сконцентрированными на работе, постоянно стремитесь к изучению новых материалов и повышайте свой профессиональный уровень.

Качества хорошего тестировщика

Качества хорошего тестировщика

Выводы

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

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

Оставить комментарий