Comments 25
Хорошо, хотя в основном о наболевшем :)
Про себя могу сказать, что «заказываю» тестировщикам заключение о работоспособности в некоторых условиях. А уже стратегию тестирования, тест-кейсы, они уже сами составляют исходя из этих самых условий.
Основная задача тестирования по-моему — установление уровня качества продукта, а именно уровня соответствия требованиям/условиям использования. А какое решение принимать на основе получившегося уровня — дело менеджера…
Про себя могу сказать, что «заказываю» тестировщикам заключение о работоспособности в некоторых условиях. А уже стратегию тестирования, тест-кейсы, они уже сами составляют исходя из этих самых условий.
Основная задача тестирования по-моему — установление уровня качества продукта, а именно уровня соответствия требованиям/условиям использования. А какое решение принимать на основе получившегося уровня — дело менеджера…
Спасибо о рассказе с другой стороны, учтем на будущее.
Вообще-то приходя в парихмахерскую я почти так и говорю: «Я вам доверяю, вы профессионал, сделайте хорошо.»
А если результат не понравится, вы не сердитесь на мастера, правильно?
Я года 4 назад пришел в парикмахерскую и сказал именно так. Собственно до сих пор я стригусь у этого мастера.
Как TeamLead сейчас начинаю внедрение «правильного» тестирования. Беру человека… И уже сказал ему: «Ты специалист? Вот и раскажи как у нас должно быть построено тестирование, чтобы мы смогли вовремя и в требуемом качестве выпускать продукт.»
А что из этого получится — вскритие покажет.
Как TeamLead сейчас начинаю внедрение «правильного» тестирования. Беру человека… И уже сказал ему: «Ты специалист? Вот и раскажи как у нас должно быть построено тестирование, чтобы мы смогли вовремя и в требуемом качестве выпускать продукт.»
А что из этого получится — вскритие покажет.
Угу, и можно понадеяться на «авось», а вдруг вскрытие что хорошее покажет?
А можно не надеяться и заранее оградить себя от проблем, обозначив конкретные ожидания.
А можно не надеяться и заранее оградить себя от проблем, обозначив конкретные ожидания.
Вам хорошо, в Москве вакансий меньше, чем соискателей. А в нашей дыре за каждого специалиста идет драка. Да, человека которого берем, тоже на мне будет учится. Опыт у него уже есть, будем улучшать и углублять. Он свой, я свой.
Сейчас, прочитав кучу умных книг, я вижу много путей. Сейчас у меня в этом проблема.
Кстати, возвращаясь к парехмахерским. Вам, как не профессионалу, может показаться, что вам очень пойдет кислотно-зеленый цвет. И задачей мастера будет, в том числе, постараться вас в этом разубедить?
Сейчас, прочитав кучу умных книг, я вижу много путей. Сейчас у меня в этом проблема.
Кстати, возвращаясь к парехмахерским. Вам, как не профессионалу, может показаться, что вам очень пойдет кислотно-зеленый цвет. И задачей мастера будет, в том числе, постараться вас в этом разубедить?
Ну тем более, раз нет возможности найти супер-эксперта, который снимет головную боль, надо хорошо понимать, что от него требовать…
Про зелёный цвет и парикмахера: да, его задача — постараться разубедить меня, если он считает это неправильным, но в конечном счёте всё равно сделать то, что я хочу. А не покрасить меня втихаря в «более подходящий» (по его мнению) синий.
Про зелёный цвет и парикмахера: да, его задача — постараться разубедить меня, если он считает это неправильным, но в конечном счёте всё равно сделать то, что я хочу. А не покрасить меня втихаря в «более подходящий» (по его мнению) синий.
Вы обратили внимание, в рамках какой статьи мы ведем с вами обсуждение. Значет я стремлюсь понять что я могу максимально выжать из тестирования. Но собственно, если вас берет работадатель, он ведь будет вам доверять, как профессионалу? Вот и я буду доверять и проверять. А так, я бы с удовольствием в свой законный отпуск постажировался бы по тестированию где нибудь…
Пока не сталкивался с таким, но всегда есть возможность исправить это сделав еще по-короче)
Я не хотел сказать, что PM не должен знать за чем тестирование, а лишь то, что по-моему мнению сравенние не совсем корректно.
С другой стороны я не обратил внимания, что автор девушка, а девушки, наверно, когда идут в парикмахерскую, в деталях представляют свою будущую прическу.
Я не хотел сказать, что PM не должен знать за чем тестирование, а лишь то, что по-моему мнению сравенние не совсем корректно.
С другой стороны я не обратил внимания, что автор девушка, а девушки, наверно, когда идут в парикмахерскую, в деталях представляют свою будущую прическу.
>>Вообще-то приходя в парихмахерскую я почти так и говорю
Мне кажется Вы недоговариваете или не стремитесь вспомнить все детали похода в парикмахерскую. Думаю все-таки минимальную спецификацию на стрижку Вы все-таки задаете.
Поделюсь своим опытом походов в это часто посещаемое место.
Меня все-таки спрашивают «Что на этот раз? По-короче или по-длиннее», также популярен вопрос «Просто аккуратно или что-то необычное?». Вопросов конечно мало, но все же они есть!!! Ах-да, еще популярен вопрос «Виски косые или прямые?». Именно эти вопросы можно считать своеобразным техническим заданием на изделие «стрижка». Именно они позволяют оценить результат работы специалиста. Если я просил «косые виски», т.к. это одна из черточек моего внешнего вида, а получил «прямые виски», то я буду считать это «парикмахер сделал багу, т.к. запрошенное и ожидаемое отличается от результата»
Мне кажется Вы недоговариваете или не стремитесь вспомнить все детали похода в парикмахерскую. Думаю все-таки минимальную спецификацию на стрижку Вы все-таки задаете.
Поделюсь своим опытом походов в это часто посещаемое место.
Меня все-таки спрашивают «Что на этот раз? По-короче или по-длиннее», также популярен вопрос «Просто аккуратно или что-то необычное?». Вопросов конечно мало, но все же они есть!!! Ах-да, еще популярен вопрос «Виски косые или прямые?». Именно эти вопросы можно считать своеобразным техническим заданием на изделие «стрижка». Именно они позволяют оценить результат работы специалиста. Если я просил «косые виски», т.к. это одна из черточек моего внешнего вида, а получил «прямые виски», то я буду считать это «парикмахер сделал багу, т.к. запрошенное и ожидаемое отличается от результата»
«Но вывод почти всегда один: тестирование на качество никак не влияет»
Хоть фраза формально и правильная (да, по сути тестирование — это измерительный инструмент), но применять её нужно осторожно. Могут и не понять. Я сам на этой фразе споткнулся и задумался на несколько секунд.
Тестирование никогда не рассматривается отдельно, как измерительный инструмент — это неотъемлемая часть контроля качества. Т.е. измеряем не просто так ради интереса, а именно для того, чтобы ответить себе на вопрос, а должного ли качества у нас сейчас продукт.
Я когда в квартире ремонт делаю чтобы обеспечить ровность стен использую измерительный иструмент типа гидро-уровень. Гидро-уровень мне нужен не просто чтобы знать «где горизонт», а чтобы стены вертикальные (т.е. качественные) сделать.
Хоть фраза формально и правильная (да, по сути тестирование — это измерительный инструмент), но применять её нужно осторожно. Могут и не понять. Я сам на этой фразе споткнулся и задумался на несколько секунд.
Тестирование никогда не рассматривается отдельно, как измерительный инструмент — это неотъемлемая часть контроля качества. Т.е. измеряем не просто так ради интереса, а именно для того, чтобы ответить себе на вопрос, а должного ли качества у нас сейчас продукт.
Я когда в квартире ремонт делаю чтобы обеспечить ровность стен использую измерительный иструмент типа гидро-уровень. Гидро-уровень мне нужен не просто чтобы знать «где горизонт», а чтобы стены вертикальные (т.е. качественные) сделать.
И да, и нет :)
Гидро-уровень нужен, чтобы узнать горизонт, а это нужно, чтобы сделать стены вертикальными. Причино-следственная связь верна, если тестирование нужно чтобы «просто информировать», но это ни на что не влияет, то толку ноль.
Но есть другая крайность, с которой я встречаюсь даже чаще: тестированием надеются залатать дыры в разработке. Получается что-то вроде «а давайте стены выравнивать уровнем». И потом получается: тестирование плохое, потому что продукт плохого качества…
Гидро-уровень нужен, чтобы узнать горизонт, а это нужно, чтобы сделать стены вертикальными. Причино-следственная связь верна, если тестирование нужно чтобы «просто информировать», но это ни на что не влияет, то толку ноль.
Но есть другая крайность, с которой я встречаюсь даже чаще: тестированием надеются залатать дыры в разработке. Получается что-то вроде «а давайте стены выравнивать уровнем». И потом получается: тестирование плохое, потому что продукт плохого качества…
Встречаются два подхода к цели тестирования:
1. цель тестирования — это поиск багов.
2. цель тестирования — проверка качества продукта. Проще говоря, тестеры должны ставить диагноз и нести за этот диагноз ответственность.
Вроде очевидно, что первая цель странная, т.к. баги можно искать до полного посинения и всё равно они останутся. То есть цель недостижимая.
Но, к моему удивлению, практически все руководители проектов (да и прочие руководители), разработчики (это как раз не удивительно :)) и, часто, сами тестеры считают целью тестирования вылавливание багов. НА словах они соглашаются с объяснением о качестве, но по-факту…
1. цель тестирования — это поиск багов.
2. цель тестирования — проверка качества продукта. Проще говоря, тестеры должны ставить диагноз и нести за этот диагноз ответственность.
Вроде очевидно, что первая цель странная, т.к. баги можно искать до полного посинения и всё равно они останутся. То есть цель недостижимая.
Но, к моему удивлению, практически все руководители проектов (да и прочие руководители), разработчики (это как раз не удивительно :)) и, часто, сами тестеры считают целью тестирования вылавливание багов. НА словах они соглашаются с объяснением о качестве, но по-факту…
А ещё могут быть цели:
1) Нивелирование рисков выпуска некачественного ПО
2) Удовлетворение формальным требованиям заказчика
3) Отмывание бюджета
4) Обеспечение прогнозируемости и планируемости проекта
5) Сокращение затрат на весь цикл разработки, или отдельно на поддержку
6)…
1) Нивелирование рисков выпуска некачественного ПО
2) Удовлетворение формальным требованиям заказчика
3) Отмывание бюджета
4) Обеспечение прогнозируемости и планируемости проекта
5) Сокращение затрат на весь цикл разработки, или отдельно на поддержку
6)…
Я писал про цели тестирования. 1 и 2 — это состовляющие проверки качества.
Что касается остального, то я конечно понимаю, что тестерам можно поручить написание отчётов для обоснования расхода средств (цель 3). Но с таким же успехом мы можем поручить им мыть полы в офисе. Какое это имеет отношение к тестированию?
Что касается остального, то я конечно понимаю, что тестерам можно поручить написание отчётов для обоснования расхода средств (цель 3). Но с таким же успехом мы можем поручить им мыть полы в офисе. Какое это имеет отношение к тестированию?
А ещё, формально поиск багов называется тестированием, а проверка (диагностирование) — контролем качества.
тестирование программного обеспечения — процесс исследования программного обеспечения (ПО) с целью получения информации о качестве продукта.
Собственно, PM еще и направлять тестинг может (должен) и собственно именно к нему тестеры и ходят с вопросами (=> живут они сообща).
+ «Основная задача тестирования по-моему — установление уровня качества продукта, а именно уровня соответствия требованиям/условиям использования.» — это как раз лучше и задавать PM, а тестерам подхватывать. ну или наоборот.
главное, чтоб душа в душу жили и не тужили)
+ «Основная задача тестирования по-моему — установление уровня качества продукта, а именно уровня соответствия требованиям/условиям использования.» — это как раз лучше и задавать PM, а тестерам подхватывать. ну или наоборот.
главное, чтоб душа в душу жили и не тужили)
имхо нет панацеи, насколько «качественным» PM хочет чтобы его продукт был, настолько же качественно он должен его контроллировать и тем самым сам задавать критерии. хороший тестер можен направить менеджера в места, где качество хромает или возможно будет хромать. все взаимосвязано. нельзя просто слушать отчеты от тестеров, а в случае провала предприятия сказать «ты — тот, кто не обеспечил мне качество, а ведь обещал») им нужно дружить и причем очень плотно.
Я в своем комментарии говорил о том, что следует ждать от тестировщика. Никто не говорит, что от него ждут качественного продукта — качественный продукт это результат взаимодействия контроля качества и разработчиков, чаще всего итерационного взаимодействия. Так вот, качество само по себе — это уровень соответствия продукта ожиданиям, и измерение этого уровня — на мой взгляд, повторюсь, основная задача тестировщика. Если говорить о PM, то его задача — организовать такое взаимодействие, чтобы продукт на выходе был качественным, то есть удовлетворял требованиям. Дружить им, или «заказывать» друг у друга информацию/услуги — вопрос второй.
Наташ, а теперь и я быдло-менеджер :-)
Ох. Если честно — ничего особенного, выходящего за рамки «тестирование может улучить качество продукта» знать не нужно.
Если к нашему продукту объективно не предъявляется высоких требований и цена ошибки мала — мы в принципе вполне можем и забить на отдельное тестирование ибо оно стоит дороже, чем урон от возможных ошибок.
Если же на качественном уровне декларируется «качество» и есть лишние ресурсы на его обеспечение, то можно «попробовать».
Итак у нас есть группа разработчиков, которая выпускает релиз. Его ведь кто-то проверяет и находит некоторое количество ошибок + потребители находят некоторое количество багов.
В течении некоторого времени — собирается статистика, что на каждые N строк разработчики делают столько то ошибок, и столько-то из них проходит через smoke-тестирование и находится клиентами.
Если числа большие и цена их высока и достаточна для организации службы тестирования — то вперёд.
Организовали, проработали некоторое время — посмотрели снова на статистику — и вот тут и становится ясно:
нужно ли нам тестирование, может ли оно улучшить качества продуктов, или мы и без службы тестирвоания хорошо живём.
Пара слов о метриках: часто можно видеть, что в качестве метрики «эффективности» работы отдела тестирование выступает количество найденых багов. По моему разумению такая метрика ведёт к конфликту между разработкой и тестированием.
Гораздо лучше использовать метрику «количество багов найденных клиентом» — чем эта величина выше — тем хуже работает разработка и тестирование ВМЕСТЕ.
Если к нашему продукту объективно не предъявляется высоких требований и цена ошибки мала — мы в принципе вполне можем и забить на отдельное тестирование ибо оно стоит дороже, чем урон от возможных ошибок.
Если же на качественном уровне декларируется «качество» и есть лишние ресурсы на его обеспечение, то можно «попробовать».
Итак у нас есть группа разработчиков, которая выпускает релиз. Его ведь кто-то проверяет и находит некоторое количество ошибок + потребители находят некоторое количество багов.
В течении некоторого времени — собирается статистика, что на каждые N строк разработчики делают столько то ошибок, и столько-то из них проходит через smoke-тестирование и находится клиентами.
Если числа большие и цена их высока и достаточна для организации службы тестирования — то вперёд.
Организовали, проработали некоторое время — посмотрели снова на статистику — и вот тут и становится ясно:
нужно ли нам тестирование, может ли оно улучшить качества продуктов, или мы и без службы тестирвоания хорошо живём.
Пара слов о метриках: часто можно видеть, что в качестве метрики «эффективности» работы отдела тестирование выступает количество найденых багов. По моему разумению такая метрика ведёт к конфликту между разработкой и тестированием.
Гораздо лучше использовать метрику «количество багов найденных клиентом» — чем эта величина выше — тем хуже работает разработка и тестирование ВМЕСТЕ.
Sign up to leave a comment.
Что менеджер проектов должен знать о тестировании