К основному контенту

Кто такой хороший тестировщик?


Думаю, что вдогонку статье о разработчиках, нужно добавить что-нибудь интересное и для тестировщиков.

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

Итак, поехали.

Вы НЕ являетесь профессионалом, если:
  • Вы считаете, что тестирование – это не техническая профессия, и вы даже не пытаетесь понять код, который лежит в основе продукта.
Понятно, что разработчик должен уметь программировать, это его работа. Но и у вас, как тестировщика, должна быть возможность смотреть на  свой продукт изнутри, понимать, как изменения и исправления могут повлиять на работу или вызвать новые проблемы. Дни «черных» и «белых» ящиков сочтены. Вы можете не писать код, но пока вы не читаете код, большая часть исходных данных для настройки процесса тестирования будет вне зоны вашего внимания.
Это круто конечно, но сейчас, мне кажется, таких доскональных знаний от тестеров не требуется. В моей практике встречались ребята из отделов тестирования, обладающие знаниями в программировании (не «автоматизаторы»). Это действительно здорово им и разработчикам помогает. Но реалии таковы, что это уникумы и найти человека умеющего программировать на должность тестировщика очень сложно. И причин этому много. Я думаю, что это тема для отдельного обсуждения. Но что гораздо, на мой взгляд, важнее - это знания предметной области. Вот тут вы должны быть экспертом. Но мы отвлеклись, поехали дальше.

  • Вы не участвуете в процессе до тех пор, пока не получаете «по голове» готовым билдом с указанием «иди и проверь его».
Задумайтесь и ответьте себе на вопрос: Когда вы начинаете участвовать в процессе разработки? В теории мы должны начинать на этапе сбора и анализа требований, вместе с остальной командой. Но на деле, мы получаем очень мало информации ровно до того момента, когда получаем по голове первым билдом от разработчиков, желающих получить отзыв о том, что они наваяли.
Тут в оригинале идет предположение о том, что обычно у тестировщиков просто нет времени на то, чтобы тратить время на анализ. Я думаю, какая-то правда в этом есть, но чаще у тестировщиков просто не спрашивают их мнение. Будьте активней, добивайтесь участия в планировании функционала, обсуждении того, что и как будет делаться. Ваши знания нужны продукту!

  • Вы общаетесь с Заказчиком только тогда, когда служба поддержки просит вас воспроизвести багу.
Часть вашей работы – это проверка продукта на основе того, как он будет использоваться в продакшене, и поиск багов. Фактически ваша работа – это быть адвокатом Заказчика в команде разработчиков. Для планирования тестов и разворачивания окружения вам нужно понимать как, где и как продукт будет использоваться. Как вы будете это делать, если вы не будете общаться с Заказчиком?
Хочется отметить, что часто не только у тестеров, но и у разработчиков, аналитиков нет доступа непосредственно к Заказчику (в момент разработки продукта). Тут в качестве исходных данных могут выступить предыдущий опыт, общение с отделом продаж, анализ продуктов конкурентов.

  • Управление рисками для вас, это что-то из области страхования жизни.
На самом деле существует немного неоспоримых истин о тестировании. Одна из них - тестировщик никогда не будет иметь времени протестировать абсолютно все. Именно из-за этого, понимание основ управления рисками очень важно. Оно помогает нам правильно понять и расставить приоритеты. Что должно быть проверено в первую очередь, а качество чего можно оценить на основе результатов других тестов. Но, это только основная часть управления рисками. Другой, более интересной и не менее полезной является та, что напрямую даже не связана с тестированием! Каждый тестировщик знает, какие части его продукта подвержены большим рискам, части в которых больше всего багов и где команда срывает сроки из-за непредвиденных обстоятельств. Часть нашей работы как тестировщика, постоянно контролировать эти части и напоминать всей команде о них на всех стадиях нашего проекта.
По своему опыту скажу, что тестировщики, как правило, более пессимистичны при оценке сроков. Видимо это как раз и связано с тем, что они постоянно держат в голове все эти потенциальные проблемы. Точно на тему пессимизма :)

  • У вас нет плана как улучшить качество своего тестирования
Хмм, тут в статье мне как то не понравилось. Много воды. Имхо, надо просто читать больше книг по теории и практике тестирования или вот мой вариант такого списка. Общаться с коллегами из других компаний, перенимать интересный опыт. И постоянно смотреть на себя со стороны, пытаясь найти слабые места, которые можно улучшить. 

  • Вы думаете, что ваша работа это писать, а потом запускать заранее определенный набор тестовых сценариев
В общем, это не так. От вас ждут много чего, например:
- анализ предполагаемой архитектуры вашего продукта
- анализ рисков на основе планов разработки и тестирования
- разработка инструментов автоматизации тестирования
- запуск тестов, но не только тех, что вы заранее описали
- анализ результатов тестов и прочей доступной вам информации для оценки текущего состоянии продукта
И так далее…

  • Вы считаете автоматизацию тестирования высокой наукой и планируете заниматься ей в будущем - на пенсии
Прекратите оправдываться на тему того, почему вы не используете автоматизацию. Автоматизация не является волшебной таблеткой, которая решит все ваши проблемы (не верьте рекламе). Но ее использование делает вашу работу эффективней.
Проблема в том, что многие тестировщики считают себя недостаточно продвинутыми в этом вопросе и просто решают, что не могут использовать автоматические тесты. Но это все равно, что использовать спички для освещения, вместо фонарика.
С чего начать автоматизацию? Возможно, вам поможет эта информация. На самом деле, я считаю, что автоматизацией должны заниматься не только тестировщики, но и разработчики.

  • Вы ставите свое эго превыше всего.
Хороший тестировщик – скромный тестировщик. Вы должны знать, как донести обратную связь и, что более важно, как получить обратную связь от команды и коллег.
Часто тестировщики очень расстраиваются, когда коллеги (особенно разработчики) высказывают мнение о качестве вашей работы, например, когда сами нашли баг, которые вы не нашли, или о тестах, которые не были запущены.
Многие тестировщики воспринимают это как персональную обиду, попытку подвергнуть сомнению их профессионализм. И отвечают неподобающим образом. Вы должны адекватно реагировать на критику от своих коллег. Никто не ожидает  того, что вы идеальны. Но они вправе рассчитывать на ваш  профессионализм и вашу адекватную реакцию на их мнение.

  • Вы не улучшаете свой набор инструментов
Задайте себе вопросы. Вы хорошо знаете те инструменты (утилиты), которые вы используете?
Что бы вам нужно было улучшить, обновить, попросить приобрести для того, чтобы улучшить качество вашей работы.
Тестирование это, без сомнения, мастерство (искусство, если хотите). И без правильных инструментов вам будет сложно создать требуемый продукт.

  • Вы думаете только о том, чтобы стать менеджером или уйти в другую сферу
Многие люди начинают заниматься тестированием, полагая, что это хорошая возможность уйти потом в разработчики. Другие просто не знают, что такое тестирование и думают что это просто «игра» с приложением целыми днями. После этого наверно трудно хорошо работать…
Часть их них становиться хорошими тестировщиками, но большинство в конечном итоге разочаровываются и считают дни до того момента, когда они смогут заняться чем-нибудь другим. Многие не понимают всю мощь и силу тестирования и думают, что единственный путь двигаться дальше - это начать управлять людьми.
Я думаю, что если вы постоянно думаете о чем то другом и не сфокусированы на том, как протестировать лучше, то у вас нет шансов стать профессионалом в этой области. Так что подумайте, на правильном ли вы месте и может пора подыскать себе более подходящее?


Хотите стать профессионалом? Начните смотреть на тестирование как на профессию
Первый шаг – начинаем рассматривать тестирование как нашу профессию.
Второй – посмотрите, чего вам не хватает, чтобы стать лучше? Что вы должны развивать? Как вам нужно подходить к работе и к взаимодействию с заказчиками и коллегами. Что мы должны сделать СЕЙЧАС для улучшения качества нашей работы.
Важно понимать, что изменение должно происходить изнутри, а не под воздействием какого-то указания сверху. И это не зависит от вашей текущей должности, начните с себя.

Вот так вот позитивненько :)

Комментарии

  1. Блин, вот это супер статья.


    Максим, спасибо за классный перевод

    ОтветитьУдалить
  2. Да, я как тестировщик, согласен. Современные тенденции внедрения Scrum процесса Agile разработки потихоньку стирают границу между пишущим тестировщиком и тестирующим разработчиком. В скрам-команде одна должность. Это просто член команды!

    ОтветитьУдалить
  3. Егор Чередниченко18 декабря 2012 г. в 08:35

    Вы думаете только о том, чтобы стать менеджером или уйти в другую сферу - улыбнуло

    ОтветитьУдалить
  4. Правильная статья и хороший перевод. Спасибо!

    ОтветитьУдалить
  5. Отличная статья, спасибо!

    Только поправьте заголовок "У вас не плана как улучшить качество своего тестирования" :)

    Буква "т" в слове "нет" явно пропущена...

    И кстати, те тестировщики, которые остаются в профессии и получают от нее удовольствие, в принципе, играют с приложением каждый день :))) Но на другом уровне, не наивном, о котором упоминается в статье

    ОтветитьУдалить
  6. Спасибо за комментарии, особенно от спецов. Рад, что в тему.

    ОтветитьУдалить
  7. Оля, вот оно! Не помню сколько раз проверил, а все равно бага :) Спасибо

    ОтветитьУдалить
  8. Очень познавательно, спасибо за статью :)

    ОтветитьУдалить
  9. Кратко и по-существу!!! спасибо.

    ОтветитьУдалить

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

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.