Comments 22
Главная задача тестировщика — тестирование. На этом моменте можно сразу сказать, что тестировщик из вас так себе.
Главная задача тестировщика — проверка соответствия качества конечного продукта (компонента продукта), требованиям спускаемых к этому продукту. Т.е. если продукт весь багнутый и дерьмовый, но продакт менеджер говорит требования, что так и должно быть — значит это и есть эталон качества.
Главная задача тестировщика — проверка соответствия качества конечного продукта (компонента продукта), требованиям спускаемых к этому продукту. Т.е. если продукт весь багнутый и дерьмовый, но продакт менеджер говорит требования, что так и должно быть — значит это и есть эталон качества.
terras Спасибо за вашу оперативную оценку меня как специалиста. Будет здорово, если вы также дадите определение такому термину, как тестирование.
Тестировщик спит спокойно, когда все найденные баги исправленны, и пользователи пишут хорошие отзывыЯ думаю любой тестировщик, которому нравится его работа, всегда думает об багах которые он не обнаружил. И поэтому спит он не очень хорошо. А еще он плохо спит, если другие обнаруживают ошибки которые не смог найти он. Он думает, вот это простые люди, а нашли такое, а я профессионал, и не нашел. Мягко говоря, завышенной самооценкой тестировщики не страдают. Есть такие, кто ищут виноватых среди разработчиков, но я себе всегда говорю, ты не нашел — твоя недоработка, думай почему, и что улучшить.
По мне у тестирование и управление дополняют друг друга. Почему? Для управления приоритетами в разработке нужна информация о проблемных местах в продукте. Полезное (я намеренно не говорю слово «правильное») тестирование предоставляет эту информацию. Тестирование без стратегии, цели — будет менее эффективным. Руководитель настраивает тестирование на выполнение необходимых проекту задач. Он дает цели для реализации в продукте, а тестировщики проверяют насколько эти цели были достигнуты.
В конце один вопрос:
Если хорошо себя проявить, то со временем вам будут доверять больше управленческих задачdontspeaker расскажите как себя проявить. Как это было у Вас?
Недавно, услышала интересное мнение: "хороший тестировщик всегда сомневается". Я с ним полностью согласна, т.к. необходимо подвергать сомнению все. Даже свою выполненную работу. Но если на текущий момент все метрики в норме (например те, которые я привожу в статье), то не надо излишне терзать себя беспокойством. Не накручивайте себя и обязательно высыпайтесь. По этой теме рекомендую почитать книгу "Эмоциональный интеллект" Дэниела Гоулмана.
Со второй мыслью абсолютно согласна. Поэтому руководители очень ценят толковое тестирование.
Как проявить себя? Не бойтесь предлагать улучшения начальству или заказчику, если видите проблему и потенциальное решение. Выполняйте все, что обещали сделать на 200 процентов. Не стесняйтесь говорить о том, что вы готовы взять на себя дополнительные задачи и не забывайте предоставлять отчет о полученных результатах руководству. Общайтесь со всей командой по проекту, не будьте безразличны к чужим затыкам, помогайте по возможности.
dontspeaker ну значит я все делаю правильно, может просто сейчас нет необходимости во мне как руководителе. С чего я взял, что вообще нужно к этому стремиться. Я же отказался получать сертификат по программированию, сказав что хочу быть хорошим тестировщиком, а не посредственным программистом. И судя по з/п мой труд высоко ценят и недавно неожиданно меня позвали в совет по обмену опытом как эксперта по тестированию. Но всегда хочется куда-то расти. Просто я нетерпеливый такой и ждать не умею :)
Скажите пожалуйста, мне как новичку, люди добрые это нормально, назначать на руководителя проекта не Тимлида, не Сеньёра с большим опытом и образованием, а тестировщика? Не скажутся ли такие решения начальства на качестве продукции компании и работы команды?
Спасибо за комментарий.
К сожалению, сама формулировка вопроса содержит ошибочное мнение.
Не стоит исключать, что у тестировщика может быть большой опыт и хорошее образование.
Очень надеюсь, что вам со временем повезет поработать с такими специалистами.
Да, конечно, качество продукта может ухудшиться в том случае, если на замену не найдут такого же специалиста в тестировании.
Но, согласитесь, вряд ли человек, который раньше целиком отвечал за качество проекта, а теперь за сам проект, позволит забить на качество.
Умение работать с командой отдельная тема.
Тимлид обязан уметь работать с командой. Но со временем вы увидите, что сложно найти тимлидов, которые хотели бы перейти в управление проектами.
Сеньор разработчик это специалист, который хорошо прокачал свои технические навыки.
Но если вы помните, я писала выше в статье: хорошему управленцу не обязательно понимать все нутро проекта. Это даже может мешать команде.
Ну и не стоит забывать, что начальство не будет назначать любого тестировщика руководителем проекта, если не увидит в нем нужные качества.
К сожалению, сама формулировка вопроса содержит ошибочное мнение.
Не стоит исключать, что у тестировщика может быть большой опыт и хорошее образование.
Очень надеюсь, что вам со временем повезет поработать с такими специалистами.
Да, конечно, качество продукта может ухудшиться в том случае, если на замену не найдут такого же специалиста в тестировании.
Но, согласитесь, вряд ли человек, который раньше целиком отвечал за качество проекта, а теперь за сам проект, позволит забить на качество.
Умение работать с командой отдельная тема.
Тимлид обязан уметь работать с командой. Но со временем вы увидите, что сложно найти тимлидов, которые хотели бы перейти в управление проектами.
Сеньор разработчик это специалист, который хорошо прокачал свои технические навыки.
Но если вы помните, я писала выше в статье: хорошему управленцу не обязательно понимать все нутро проекта. Это даже может мешать команде.
Ну и не стоит забывать, что начальство не будет назначать любого тестировщика руководителем проекта, если не увидит в нем нужные качества.
У нас есть сениоры которым волей судеб свалилось руководство командой и все прелести идущие в пакете — один, являясь отличным программистом, но не имея необходимого для ведения переговоров характера воспринял эту новую роль тяжело. Другой же сениор, которому досталось тимлидство по другой компоненте, по жизни общительный, незакомплексованный, оптимистичный человек, и для него звонить туда сюда, искать компромиссы никогда не составляло большого труда. И первый через год попросил избавить его от этой новой обязанности, а второй влился и нормально справляется. Зависит от предрасположенности к этому виду деятельности.
И что делает тестировщика подходящим кандидатом это то, что его знание требований к продукту практически на уровне разработчика (он только код может не пишет, но понимает как он устроен, ведь он при заведении бага указывает в какой компоненте проблема, напр. frontend, middleware, backend). Кроме того, тестировщика непонарошку заботит качество конечного продукта.
Получается, он знает, что должно получиться, он привык «заставлять» программистов делать так чтобы было как надо, он интуитивно понимает риски и правильно ставит приоритеты задач, он умеет общаться со всеми участниками команды — вот вам и качества лидера.
Конечно от конкретного человека зависит.
И что делает тестировщика подходящим кандидатом это то, что его знание требований к продукту практически на уровне разработчика (он только код может не пишет, но понимает как он устроен, ведь он при заведении бага указывает в какой компоненте проблема, напр. frontend, middleware, backend). Кроме того, тестировщика непонарошку заботит качество конечного продукта.
Получается, он знает, что должно получиться, он привык «заставлять» программистов делать так чтобы было как надо, он интуитивно понимает риски и правильно ставит приоритеты задач, он умеет общаться со всеми участниками команды — вот вам и качества лидера.
Конечно от конкретного человека зависит.
Вы — большая умница и делаете правильные выводы. Советы в статье подойдут не только тестировщику, но любому исполнителю, волей судеб ставшему руководителем.
толково написано и работа проведена большая.
UFO just landed and posted this here
ClearAirTurbulence ваш «оффтоп» вполне по теме. Такое случается, что реализация может показаться нетипичной для нашего культурного опыта. В таком случае стоит свериться с документацией и требованиями. В данном случае мы имеем дело с другим этносом, где это является нормой. Изображение соответствует литературному описанию.
Да безразличен этнос и литературное описание.
Чисто с точки зрения механики она стоит плохо
Это да, но я про другое. Допустим, что у них асимметрия считается оскорбительной. Им пофигу на механику. Суждения тестировщика должны принимать такие моменты во внимание.
Такой репорт могут завернуть, даже если он помечен как «усовершенствование» и сказать, что «так надо». Получится ты зря потратишь время и свое и чужое. Это снижает эффективность бизнеса.
Философия тестирования на мой взгляд такова, что нужно освободить свое сознание от любого опыта, чтобы приблизиться к обьективности. У тестировщика нет ни хорошо, ни плохо, есть «соответствует требованиям», «не соответствует» и самый частый вариант: «я не знаю». Тестировщик это не инженер-рационализатор, не дизайнер, не программист. Он не знает как лучше и не должен знать, он должен наблюдать и выявлять несоответствия требованиям. Это кстати лучший известный мне способ жить в мире и согласии с разработчиками: «Не судить».
Расскажу коротенькую поучительную историю еще на этот счет.
На заре моей карьеры я нашел одну проблему в приложении, при определенных условиях оно начинало тормозить и переставало реагировать на ввод. Я написал в репорте что у приложения «фриз». Разработчик вскинулся и в порыве возмущения сказал: «Это не фриз, это задержка отрисовки, приложение в это время продолжает работать, так что просто лучше пиши что ты видишь, а не то что ты думаешь, что ты видишь.» С тех пор это мое золотое правило тестирования: «просто говори, что ты видишь».
Такой репорт могут завернуть, даже если он помечен как «усовершенствование» и сказать, что «так надо». Получится ты зря потратишь время и свое и чужое. Это снижает эффективность бизнеса.
Философия тестирования на мой взгляд такова, что нужно освободить свое сознание от любого опыта, чтобы приблизиться к обьективности. У тестировщика нет ни хорошо, ни плохо, есть «соответствует требованиям», «не соответствует» и самый частый вариант: «я не знаю». Тестировщик это не инженер-рационализатор, не дизайнер, не программист. Он не знает как лучше и не должен знать, он должен наблюдать и выявлять несоответствия требованиям. Это кстати лучший известный мне способ жить в мире и согласии с разработчиками: «Не судить».
Расскажу коротенькую поучительную историю еще на этот счет.
На заре моей карьеры я нашел одну проблему в приложении, при определенных условиях оно начинало тормозить и переставало реагировать на ввод. Я написал в репорте что у приложения «фриз». Разработчик вскинулся и в порыве возмущения сказал: «Это не фриз, это задержка отрисовки, приложение в это время продолжает работать, так что просто лучше пиши что ты видишь, а не то что ты думаешь, что ты видишь.» С тех пор это мое золотое правило тестирования: «просто говори, что ты видишь».
Разработчик вскинулся и в порыве возмущения сказал
Это проблемы разработчика, а точнее постановки задачи product owner или project manager. Если с точки зрения бизнесзадачи тут должна быть отрисовка без «задержки», то должна быть именно она.
Если «бизнес» допускает временную остановку отрисовки (а на какой период?), то ок.
Тестировщик может заметить, что петли испытывают огромную нагрузку. Провисание и заклинивание люка обеспечено. Исторически так сложиться не могло. Это требование заказчика, которое приходится удовлетворять инженерам ломая голову. Я догадываюсь, что такой вход — это обеспечение legacy по отношению к ранее существующей системе типа «нора».
Хорошая статья. Сейчас прохожу через похожие этапы. Что-то кажется более менее пройденным, что-то в процессе. Пока что часто поддаюсь соблазну «сделай сам», потому что «людей мало», вместо того, чтобы заняться аудитом и оптимизацией работы. Порой хочется сделать что-то дома, внеурочно, но понимаю, что это может для технического спеца — круто, а мне нужно стремиться к другим вещам — перераспределить работу, дать таски ребятам по этой проблеме. Не бежать решать технические проблемы, в общем, а выстраивать процессы вокруг этих проблем такие, чтобы в команде был ресурс их решать. В общем, зон роста много, ваша статья позволила по ним свериться.
selotec может поделитесь, как шли к этому? Чем занимается проект? Сколько в нем человек? На какой позиции начинали. На какой позиции теперь? Как выглядели процессы изначально, как вы смогли их улучшить? Кто вам дал это сделать?
Начинал будучи стажером без опыта. Делал помимо технических задач (автотестов, ручного и т.д.) разные дела — и деплоить бэкенды доводилось, и факапы разгребать по качеству и по интеграциям общаться. Т.е. помимо технических задач имел разные зоны ответственности в проектах и команде в целом. Было дело — выстраивал процессы тестирования на новых проектах команды, ну и за релизы продуктов отвечал. В какой-то момент руководитель сказал, что я теперь сеньор.
Когда пришел, был единственным тестировщиком на 5х разработчиков и 3-4 проекта. Сейчас нас в соотношении 1 к 3 примерно, в команде на человек 18-20. Проекты — плюсовые и питонячьи бэкенды, плюсовые же библиотеки, которые потом интегрируются другими командами. Когда тестировщиков стало больше в команде, встал вопрос о руководителе группы тестирования, предложили мне, но внутренне я тогда не был к этому готов (по уровню квалификации был миддлом на тот момент). Позже, когда я дорос до сеньора, а руководитель решил заняться делами вне компании, вакансию снова предложили мне, и в этот раз я согласился (все это время наблюдал, чем занимается мой руководитель и какие задачи решает, и понял, что ничего сверхстрашного и неподъемного там нет).
По процессам — много тоже разного было. Не было общей тестовой документации — каждый писал где хотел и что хотел. Стандарты мы какие-то разрабатывать не стали, а стали писать все чек-листы и прочие штуки в одном общем источнике. Была проблема с кроссфункциональностью — когда один человек (и только он) мог знать, как тестируется целый один проект — автобусный фактор в чистом виде. Ввел практику, что все по кругу тестируем разные проекты, каждый погружается так или иначе во все. Ответственные есть все равно, но каждый может потестировать почти любой продукт. Были проблемы с интеграциями внутри команды (между нашими продуктами) и снаружи — договаривались, притирались. Плохо был построен процесс планирования — тестирование или не планировалось или планировалось по остаточному принципу — что разработка взяла в спринт, то и тестируем, — тестирование не говорило «нет, это не влазит, давайте дедлайны и приоритеты». Исправил этот момент — теперь и дедлайны от разработки есть всегда, и тестирование периодически говорит, что весь релиз не влазит, давайте думать, что будем релизить в следующий раз. Надо мной в иерархии стоит тимлид, он на все улучшения процессов смотрит адекватно, общаемся с ним, с разработчиками, учитываем фидбек. В общем, улучшать процессы никто не мешает, наоборот, ждут этого. На этом проблемы в процессах не кончились, работаем дальше, тем более что ресурса в тестировании на все проекты не хватает, а вакансии согласовываются дольше, чем появляется необходимость в них. Но свои сеньоры подрастают, что-то уже могу передавать им, где-то они фидбечат по процессам и предлагают решения. Растем понемногу)
Когда пришел, был единственным тестировщиком на 5х разработчиков и 3-4 проекта. Сейчас нас в соотношении 1 к 3 примерно, в команде на человек 18-20. Проекты — плюсовые и питонячьи бэкенды, плюсовые же библиотеки, которые потом интегрируются другими командами. Когда тестировщиков стало больше в команде, встал вопрос о руководителе группы тестирования, предложили мне, но внутренне я тогда не был к этому готов (по уровню квалификации был миддлом на тот момент). Позже, когда я дорос до сеньора, а руководитель решил заняться делами вне компании, вакансию снова предложили мне, и в этот раз я согласился (все это время наблюдал, чем занимается мой руководитель и какие задачи решает, и понял, что ничего сверхстрашного и неподъемного там нет).
По процессам — много тоже разного было. Не было общей тестовой документации — каждый писал где хотел и что хотел. Стандарты мы какие-то разрабатывать не стали, а стали писать все чек-листы и прочие штуки в одном общем источнике. Была проблема с кроссфункциональностью — когда один человек (и только он) мог знать, как тестируется целый один проект — автобусный фактор в чистом виде. Ввел практику, что все по кругу тестируем разные проекты, каждый погружается так или иначе во все. Ответственные есть все равно, но каждый может потестировать почти любой продукт. Были проблемы с интеграциями внутри команды (между нашими продуктами) и снаружи — договаривались, притирались. Плохо был построен процесс планирования — тестирование или не планировалось или планировалось по остаточному принципу — что разработка взяла в спринт, то и тестируем, — тестирование не говорило «нет, это не влазит, давайте дедлайны и приоритеты». Исправил этот момент — теперь и дедлайны от разработки есть всегда, и тестирование периодически говорит, что весь релиз не влазит, давайте думать, что будем релизить в следующий раз. Надо мной в иерархии стоит тимлид, он на все улучшения процессов смотрит адекватно, общаемся с ним, с разработчиками, учитываем фидбек. В общем, улучшать процессы никто не мешает, наоборот, ждут этого. На этом проблемы в процессах не кончились, работаем дальше, тем более что ресурса в тестировании на все проекты не хватает, а вакансии согласовываются дольше, чем появляется необходимость в них. Но свои сеньоры подрастают, что-то уже могу передавать им, где-то они фидбечат по процессам и предлагают решения. Растем понемногу)
Спасибо. Для меня, как бывшего тестировщика, обучающегося на данный момент на курсе MBA, статья выглядит очень жизненно и интересно.
- Отсутствие возможности набрать свою команду. Чаще всего руководители проектов работают с теми, кого им назначили на проект.
- Перейти на другой проект – сложно. Не нравится проект? Значит вы что-то делаете не так
Сделаю предположение, что это особенности именно вашей компании. Все же встречается и обратное
Sign up to leave a comment.
Переход из тестировщика в руководители проектов