Комментарии 22
Главная задача тестировщика — проверка соответствия качества конечного продукта (компонента продукта), требованиям спускаемых к этому продукту. Т.е. если продукт весь багнутый и дерьмовый, но продакт менеджер говорит требования, что так и должно быть — значит это и есть эталон качества.
Тестировщик спит спокойно, когда все найденные баги исправленны, и пользователи пишут хорошие отзывыЯ думаю любой тестировщик, которому нравится его работа, всегда думает об багах которые он не обнаружил. И поэтому спит он не очень хорошо. А еще он плохо спит, если другие обнаруживают ошибки которые не смог найти он. Он думает, вот это простые люди, а нашли такое, а я профессионал, и не нашел. Мягко говоря, завышенной самооценкой тестировщики не страдают. Есть такие, кто ищут виноватых среди разработчиков, но я себе всегда говорю, ты не нашел — твоя недоработка, думай почему, и что улучшить.
По мне у тестирование и управление дополняют друг друга. Почему? Для управления приоритетами в разработке нужна информация о проблемных местах в продукте. Полезное (я намеренно не говорю слово «правильное») тестирование предоставляет эту информацию. Тестирование без стратегии, цели — будет менее эффективным. Руководитель настраивает тестирование на выполнение необходимых проекту задач. Он дает цели для реализации в продукте, а тестировщики проверяют насколько эти цели были достигнуты.
В конце один вопрос:
Если хорошо себя проявить, то со временем вам будут доверять больше управленческих задачdontspeaker расскажите как себя проявить. Как это было у Вас?
Недавно, услышала интересное мнение: "хороший тестировщик всегда сомневается". Я с ним полностью согласна, т.к. необходимо подвергать сомнению все. Даже свою выполненную работу. Но если на текущий момент все метрики в норме (например те, которые я привожу в статье), то не надо излишне терзать себя беспокойством. Не накручивайте себя и обязательно высыпайтесь. По этой теме рекомендую почитать книгу "Эмоциональный интеллект" Дэниела Гоулмана.
Со второй мыслью абсолютно согласна. Поэтому руководители очень ценят толковое тестирование.
Как проявить себя? Не бойтесь предлагать улучшения начальству или заказчику, если видите проблему и потенциальное решение. Выполняйте все, что обещали сделать на 200 процентов. Не стесняйтесь говорить о том, что вы готовы взять на себя дополнительные задачи и не забывайте предоставлять отчет о полученных результатах руководству. Общайтесь со всей командой по проекту, не будьте безразличны к чужим затыкам, помогайте по возможности.
К сожалению, сама формулировка вопроса содержит ошибочное мнение.
Не стоит исключать, что у тестировщика может быть большой опыт и хорошее образование.
Очень надеюсь, что вам со временем повезет поработать с такими специалистами.
Да, конечно, качество продукта может ухудшиться в том случае, если на замену не найдут такого же специалиста в тестировании.
Но, согласитесь, вряд ли человек, который раньше целиком отвечал за качество проекта, а теперь за сам проект, позволит забить на качество.
Умение работать с командой отдельная тема.
Тимлид обязан уметь работать с командой. Но со временем вы увидите, что сложно найти тимлидов, которые хотели бы перейти в управление проектами.
Сеньор разработчик это специалист, который хорошо прокачал свои технические навыки.
Но если вы помните, я писала выше в статье: хорошему управленцу не обязательно понимать все нутро проекта. Это даже может мешать команде.
Ну и не стоит забывать, что начальство не будет назначать любого тестировщика руководителем проекта, если не увидит в нем нужные качества.
И что делает тестировщика подходящим кандидатом это то, что его знание требований к продукту практически на уровне разработчика (он только код может не пишет, но понимает как он устроен, ведь он при заведении бага указывает в какой компоненте проблема, напр. frontend, middleware, backend). Кроме того, тестировщика непонарошку заботит качество конечного продукта.
Получается, он знает, что должно получиться, он привык «заставлять» программистов делать так чтобы было как надо, он интуитивно понимает риски и правильно ставит приоритеты задач, он умеет общаться со всеми участниками команды — вот вам и качества лидера.
Конечно от конкретного человека зависит.
Вы — большая умница и делаете правильные выводы. Советы в статье подойдут не только тестировщику, но любому исполнителю, волей судеб ставшему руководителем.
Да безразличен этнос и литературное описание.
Чисто с точки зрения механики она стоит плохо
Такой репорт могут завернуть, даже если он помечен как «усовершенствование» и сказать, что «так надо». Получится ты зря потратишь время и свое и чужое. Это снижает эффективность бизнеса.
Философия тестирования на мой взгляд такова, что нужно освободить свое сознание от любого опыта, чтобы приблизиться к обьективности. У тестировщика нет ни хорошо, ни плохо, есть «соответствует требованиям», «не соответствует» и самый частый вариант: «я не знаю». Тестировщик это не инженер-рационализатор, не дизайнер, не программист. Он не знает как лучше и не должен знать, он должен наблюдать и выявлять несоответствия требованиям. Это кстати лучший известный мне способ жить в мире и согласии с разработчиками: «Не судить».
Расскажу коротенькую поучительную историю еще на этот счет.
На заре моей карьеры я нашел одну проблему в приложении, при определенных условиях оно начинало тормозить и переставало реагировать на ввод. Я написал в репорте что у приложения «фриз». Разработчик вскинулся и в порыве возмущения сказал: «Это не фриз, это задержка отрисовки, приложение в это время продолжает работать, так что просто лучше пиши что ты видишь, а не то что ты думаешь, что ты видишь.» С тех пор это мое золотое правило тестирования: «просто говори, что ты видишь».
Разработчик вскинулся и в порыве возмущения сказал
Это проблемы разработчика, а точнее постановки задачи product owner или project manager. Если с точки зрения бизнесзадачи тут должна быть отрисовка без «задержки», то должна быть именно она.
Если «бизнес» допускает временную остановку отрисовки (а на какой период?), то ок.
Когда пришел, был единственным тестировщиком на 5х разработчиков и 3-4 проекта. Сейчас нас в соотношении 1 к 3 примерно, в команде на человек 18-20. Проекты — плюсовые и питонячьи бэкенды, плюсовые же библиотеки, которые потом интегрируются другими командами. Когда тестировщиков стало больше в команде, встал вопрос о руководителе группы тестирования, предложили мне, но внутренне я тогда не был к этому готов (по уровню квалификации был миддлом на тот момент). Позже, когда я дорос до сеньора, а руководитель решил заняться делами вне компании, вакансию снова предложили мне, и в этот раз я согласился (все это время наблюдал, чем занимается мой руководитель и какие задачи решает, и понял, что ничего сверхстрашного и неподъемного там нет).
По процессам — много тоже разного было. Не было общей тестовой документации — каждый писал где хотел и что хотел. Стандарты мы какие-то разрабатывать не стали, а стали писать все чек-листы и прочие штуки в одном общем источнике. Была проблема с кроссфункциональностью — когда один человек (и только он) мог знать, как тестируется целый один проект — автобусный фактор в чистом виде. Ввел практику, что все по кругу тестируем разные проекты, каждый погружается так или иначе во все. Ответственные есть все равно, но каждый может потестировать почти любой продукт. Были проблемы с интеграциями внутри команды (между нашими продуктами) и снаружи — договаривались, притирались. Плохо был построен процесс планирования — тестирование или не планировалось или планировалось по остаточному принципу — что разработка взяла в спринт, то и тестируем, — тестирование не говорило «нет, это не влазит, давайте дедлайны и приоритеты». Исправил этот момент — теперь и дедлайны от разработки есть всегда, и тестирование периодически говорит, что весь релиз не влазит, давайте думать, что будем релизить в следующий раз. Надо мной в иерархии стоит тимлид, он на все улучшения процессов смотрит адекватно, общаемся с ним, с разработчиками, учитываем фидбек. В общем, улучшать процессы никто не мешает, наоборот, ждут этого. На этом проблемы в процессах не кончились, работаем дальше, тем более что ресурса в тестировании на все проекты не хватает, а вакансии согласовываются дольше, чем появляется необходимость в них. Но свои сеньоры подрастают, что-то уже могу передавать им, где-то они фидбечат по процессам и предлагают решения. Растем понемногу)
Спасибо. Для меня, как бывшего тестировщика, обучающегося на данный момент на курсе MBA, статья выглядит очень жизненно и интересно.
- Отсутствие возможности набрать свою команду. Чаще всего руководители проектов работают с теми, кого им назначили на проект.
- Перейти на другой проект – сложно. Не нравится проект? Значит вы что-то делаете не так
Сделаю предположение, что это особенности именно вашей компании. Все же встречается и обратное
Переход из тестировщика в руководители проектов