Comments 19
Общее впечатление: сначала создаём (или допускаем появление, или не пытаемся исправить исторически сложившуюся) проблему, а потом героически боремся с последствиями. И в данном случае фраза «Героизм — следствие чьей-то некомпетентности.» подходит просто идеально. Почему бы не направить это время и усилия на то, чтобы нормально поставить все необходимые для нормального тестирования процессы, вместо того чтобы мириться с существующей ситуацией и пытаться в ней выживать?
Можно направить все усилия на то, чтобы героически ставить ВСЕ необходимые для нормального тестирования процессы. А можно просто делать качественный продукт наиболее подходящими для этого инструментами. Каждый сам выбирает :)
Я выбираю ставить процессы. По-крайней мере это однократная задача, а не непрерывный и бесперспективный процесс выживания в агрессивной среде. И по мере добавления новых процессов бардака становится меньше, а работать проще — так что даже если это проделать не в полной мере, а сколько получится — жить всё-равно станет намного легче. Собственно, то, что описано в статье — это тоже постановка процессов, только не тех, которые нужны.
удачи!
Давайте по-чесноку: тестирование это вообще не тот процесс, который нужен! Писался бы сразу идеальный код — не нужно было бы продукт верифицировать. Были бы идеальные и всем понятные требования — не нужно было бы валидировать. Уберите ошибки разработки и аналитики, и тестировщики просто не нужны!
Как только такое получится, вот тогда и заживём. А пока что тестировщики неизбежно компенсируют проблемы со всех этапов разработки.
Как только такое получится, вот тогда и заживём. А пока что тестировщики неизбежно компенсируют проблемы со всех этапов разработки.
тестирование это вообще не тот процесс, который нужен!Это не так. В том идеальном мире, где тестирование не нужно — там не нужны и аналитика с разработкой — стоит заказчику чего-то захотеть и произнести вслух «Хочу!» как оно уже готово.
Юнит-тесты нужны не для того, чтобы проверить код на корректность (соответствие требованиям), а для того, чтобы проверить что код делает то, что предполагает написавший его разработчик (и совершенно не обязательно это то, что нужно заказчику). Ручное тестирование нужно не для того, чтобы находить баги, а для того, чтобы понять насколько результат аналитики и разработки соответствует «Хочу» заказчика (и скорректировать либо одно либо второе).
Но на практике далеко не всё возможно (понятно как и есть ресурсы) покрыть автоматическими тестами, поэтому ручное тестирование используется и для поиска багов. Что лично меня — огорчает. А поскольку на абсолютном большинстве проектов нормальные автоматические тесты вообще отсутствуют (не дают времени их писать, разработчики либо ленятся либо не умеют их нормально писать), то в результате без ручного тестирования проект вообще не жизнеспособен. Отсюда и возникает Ваше впечатление, что нужда в тестировании вызвана исключительно криворукими аналитиками и разработчиками… и будь они не столь криворукими можно было бы обойтись без тестирования — но это не так, см. предыдущий абзац. Другое дело, что количество и смысл ручного тестирования в нормальных условиях (наличие требований, актуальной спецификации, примерно 90% покрытие кода нормальными юнит-тестами) значительно отличаются от типичного для большинства проектов.
Автоматизированные тесты (в том числе юнит тесты) — это не только проверочное средство, но еще и дополнительное орудие в борьбе со сложностью системы в целом. Без юнит тестов немыслимо развивать большие системы: фиксят одни баги — появляются другие, реализовывают новый функционал — отваливается старый. При налаженной системе тестирование вносить в код любые изменения можно быстрее и с меньшим количеством ошибок.
Вообще, если честно, когда кто-то при ручном тестировании находит у меня в коде баг — мне становится стыдно. Потому, что это означает во-первых то, что я плохо сделал свою работу, и во-вторых то, что я этим добавил кучу лишней, ручной и нудной работы по пере-тестированию другому человеку. И, на мой взгляд, это очень правильное отношение — оно стимулирует делать всё возможное, чтобы такая ситуация не повторилась. Отсюда и моё отношение к работе на проектах где нет возможности работать качественно (нет требований, юнит-тестов, etc.).
Не поняла, если честно, ваше предложение :) Появляется на проекте тестировщик, на проекте нет нормальных требований. Что ему делать?
Бегать и махать руками «ах вы негодяи, поставьте мне все процессы, чтоб я мог нормально тестировать»?
Я смотрю с позиции специалиста по тестированию, и из двух десятков проектов последнего года, с которыми я работала, ни в одном не было хороших продуманных требований. Могу везде спихивать ответственность и говорить «постройте процессы», а могу компенсировать, насколько это возможно, со своей стороны. Наверное, оба подхода имеют право на существование, и выбирает каждый сам.
Бегать и махать руками «ах вы негодяи, поставьте мне все процессы, чтоб я мог нормально тестировать»?
Я смотрю с позиции специалиста по тестированию, и из двух десятков проектов последнего года, с которыми я работала, ни в одном не было хороших продуманных требований. Могу везде спихивать ответственность и говорить «постройте процессы», а могу компенсировать, насколько это возможно, со своей стороны. Наверное, оба подхода имеют право на существование, и выбирает каждый сам.
Появляется на проекте тестировщик, на проекте нет нормальных требований. Что ему делать?Попросить требования, конечно. Польза от этого будет всем, т.к. для разработки проекта документированные требования так же полезны (точнее — необходимы), как и для тестирования. Если хватает квалификации — написать требования самостоятельно и согласовать. Если не хватает — пинать всех до кого дотянется пока их не напишет тот, кто умеет.
Давайте я перефразирую Ваш вопрос: «Появляется на проекте тестировщик, а в офисе для него нет рабочего места и компа. Что ему делать?». И для полноты перефразирую Ваш ответ из статьи (как я её понял): «Пристроиться за плечом разработчика/менеджера/любого другого человека работающего в данный момент с приложением которое нужно тестировать и записывать на бумажку увиденные проблемы.».
Я поняла ваш подход, и спорить, правильный он или нет, не готова. Похоже на религиозный спор :) Мне кажется, что пока требования тестирования не удовлетворены, очень важно делать со своей стороны максимум, зависящий от нас, не прикрываясь внешними проблемами.
Я ни в коем случае не говорю, что налаживать другие процессы не нужно. Нужно! Конечно! Но когда в тестировании бардак, бегать и ругать аналитиков за нехватку требований, а разработчиков за нехватку юнит-тестов, у меня совести не хватит :))) А вот сделав всё от нас зависящее, уже можно и за другие процессы браться. Но, это не задача тестирования, изначально это всё-таки задача РМа. А нам что пришло, с тем и стараемся по максимуму работать.
Я ни в коем случае не говорю, что налаживать другие процессы не нужно. Нужно! Конечно! Но когда в тестировании бардак, бегать и ругать аналитиков за нехватку требований, а разработчиков за нехватку юнит-тестов, у меня совести не хватит :))) А вот сделав всё от нас зависящее, уже можно и за другие процессы браться. Но, это не задача тестирования, изначально это всё-таки задача РМа. А нам что пришло, с тем и стараемся по максимуму работать.
Наверное мы вообще об одном и том же говорим. На проектах, где я РМ, я мыслю как вы, и чиню анализ с анализа, а не с тестирования. А если я ТМ, то приходится мыслить совсем по-другому, и принимать внешние процессы как данность.
Очень может быть. У меня нет опыта вынужденной длительной работы в роли TM при сопротивляющемся здравому смыслу PM. Как фрилансер, я имею свободу выбора проектов и заказчиков, что даёт возможность нормально организовать работу. Либо я организую её самостоятельно, как PM, либо с проекта уходит кто-то из нас — либо я либо тот сопротивляющийся здравому смыслу PM. Мучить себя дурной и бесперспективной работой в значительных количествах я категорически не хочу — это время моей жизни.
Что касается «принимать внешние процессы как данность» — отвечу ещё одной цитатой: «Господи, дай мне спокойствие принять то, чего я не могу изменить, дай мне мужество изменить то, что я могу изменить. И дай мне мудрость отличить одно от другого.». Я многие внешние процессы принимаю как данность, даже если они с моей точки зрения — полнейшая, изумительная глупость. Но отсутствие требований на проекте, который не является одноразовым скриптом — я принять не могу.
Что касается «принимать внешние процессы как данность» — отвечу ещё одной цитатой: «Господи, дай мне спокойствие принять то, чего я не могу изменить, дай мне мужество изменить то, что я могу изменить. И дай мне мудрость отличить одно от другого.». Я многие внешние процессы принимаю как данность, даже если они с моей точки зрения — полнейшая, изумительная глупость. Но отсутствие требований на проекте, который не является одноразовым скриптом — я принять не могу.
Наташа, спасибо! Поправьте меня, если я ошибаюсь, посыл следующий:
1. Мы работаем в тех условиях, что есть, т.е. в реальном мире.
2. Для прозрачности и поддержания процесса реализации в актуальном состоянии нам приходится модифицировать внутренние процессы тестирования таким образом, чтобы не особо задеть внешние процессы реализации (аналитика, разработка, менеджмент).
3. Мы структурируем информацию о прямых требованиях, каталогизируем ее и генерализуем (собираем в некоторые категории/направления/группы).
4. Обеспечиваем стабильное покрытие каждого «каталога» требований проверками необходимыми и достаточными для анализа этих проверок (соответствует/не соответствует, работает/не работает).
5. Живем с этим и поддерживаем в актуальном состоянии.
Т.е. стандартный подход к работе с требованиями в тестировании, хоть TDD хоть ad hoc…
Не совсем понимаю, как это противоречит точке зрения powerman… Как бы не были поставлены процессы, все равно рано или поздно объем проверок и требований превысит память выполняющей проверки команды и потребуется либо заново генерировать и отбирать ТС либо условно принимать, что то что не меняли — работает.
В сущности наверное стоит озаглавить не как оценить покрытие, а как его стабилизировать согласно требованиям. Ведь мы знаем, что оценка покрытия — это то, что нужно ПМу для собственного успокоения, т.к. адекватность этой оценки может понимать только тестировщик.
В целом хорошая статья с правильными практиками, обязательно читаю нечто подобное в каждой организации, куда прихожу ТМ работать и для подчиненных и для коллег по реализации. Теперь смогу ссылку давать :)
Еще раз спасибо, Наташа.
1. Мы работаем в тех условиях, что есть, т.е. в реальном мире.
2. Для прозрачности и поддержания процесса реализации в актуальном состоянии нам приходится модифицировать внутренние процессы тестирования таким образом, чтобы не особо задеть внешние процессы реализации (аналитика, разработка, менеджмент).
3. Мы структурируем информацию о прямых требованиях, каталогизируем ее и генерализуем (собираем в некоторые категории/направления/группы).
4. Обеспечиваем стабильное покрытие каждого «каталога» требований проверками необходимыми и достаточными для анализа этих проверок (соответствует/не соответствует, работает/не работает).
5. Живем с этим и поддерживаем в актуальном состоянии.
Т.е. стандартный подход к работе с требованиями в тестировании, хоть TDD хоть ad hoc…
Не совсем понимаю, как это противоречит точке зрения powerman… Как бы не были поставлены процессы, все равно рано или поздно объем проверок и требований превысит память выполняющей проверки команды и потребуется либо заново генерировать и отбирать ТС либо условно принимать, что то что не меняли — работает.
В сущности наверное стоит озаглавить не как оценить покрытие, а как его стабилизировать согласно требованиям. Ведь мы знаем, что оценка покрытия — это то, что нужно ПМу для собственного успокоения, т.к. адекватность этой оценки может понимать только тестировщик.
В целом хорошая статья с правильными практиками, обязательно читаю нечто подобное в каждой организации, куда прихожу ТМ работать и для подчиненных и для коллег по реализации. Теперь смогу ссылку давать :)
Еще раз спасибо, Наташа.
Поправьте меня, если я ошибаюсь, посыл следующийДа-да! Ещё лучше, чем у меня, и чётче сформулировано :)
Не совсем понимаю, как это противоречит точке зрения powermanМне тоже кажется, что мы об одном и том же :)
Ведь мы знаем, что оценка покрытия — это то, что нужно ПМу для собственного успокоения, т.к. адекватность этой оценки может понимать только тестировщик.Проблемы начинаются, когда приходит босс и говорит: «посчитайте мне что-то и назовите циферку». Ничего хорошего из этого не выходит обычно :))) А когда мы для себя измеряем, и смотрим по своим табличкам, что проверено, что нет, куда копать, что доделать, что актуализировать, что важнее всего по приоритетам — то это работа не на циферку, а на результат.
Ну и вообще, для меня, оценка — это наши планы на будущее, приоритизация, вектор движения. А не «оценка». Слово-то такое… Опошленное менеджерами :))
Во всех приведённых проблемных ситуациях работа над улучшением качества требований всё равно проводится. И не важно, что это делает сотрудник, который отвечает за тестирование; просто в эти моменты он исполняет роль аналитика. Если такая ситуация устраивает и самого сотрудника, и руководство, и при этом этот подход даёт нужный результат, то почему нет?
Sign up to leave a comment.
Оценка тестового покрытия на проекте