Я решил собрать несколько признаков, которые могут подсказать, что с тестированием (или с процессом разработки целиком) на вашем проекте что-то не так:
- Тестировщик не участвует в обсуждении и планировании задач, которые он будет потом тестировать.
- Существует отдельно стоящий отдел тестирования, в котором каждый тестировщик может тестировать разные проекты. Часто время тестировщика расписано в процентном отношении между этими проектами.
- Разработчикам плевать на мнение тестировщика, для них он кажется бесполезным грузом.
- Любые советы и рекомендации тестировщика проходят через менеджера, который потом пытается продавить их в команде разработки.
- В проекте есть отдельная команда автоматизаторов, которая разрабатывает собственный фреймворк для тестирования. При этом фреймворк не применяется в реальной жизни пока не будет полностью закончен.
- Разработчики не пишут никаких тестов и все тестирование висит строго на тестировщиках.
- По результатам тестирования тестировщика могут либо наказать либо похвалить.
- Тестировщики работают по выходным, когда были закончены доработки в коде продукта.
- Отдел тестирования постоянно растет и тестировщиков становится все больше. Потом появляются тест лиды, менеджеры, но процесс не останавливается.
- У тестировщиков нет возможности получить сборку продукта на любую версию в системе контроля версий.
- Сборка продукта проходит руками и часто из-за этого тестирование завершается провалом.
- Тестировщику приходится отчитываться перед менеджером за низкое качество продукта.
- Тестировщика могут поощрить за количество найденных дефектов.
- В вашей системе для управления дефектами их больше тысячи в открытом состоянии.
- В команде есть специальный человек, который отвечает за тест-план. Только он может вносить изменения в тест-план и принимать решения по нему.
- Отчет о тестировании составляется руками и требует больших усилий.
- Отсутствуют метрики тестирования, которые отслеживают по ходу разработки продукта.
- Информация о результатах тестирования не доступна публично для всех участников проекта.
Этот список можно и нужно продолжать долго. Я на этом остановлюсь и дам слово вам. Какие пункты вы бы добавили? Какие удалили?
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
http://slonik-v-domene.livejournal.com/65699.html
интересное мнение насчёт глупости в эджайле ))
Нет смысла иметь мусор.
Никто не заставляет каждый раз просматривать полностью гору мусора, есть severity дефектов, в первую очередь смотрим на P1-P2 дефекты, далее Р3 и т.д. Могут быть P4 дефекты с крайне низкой вероянтостью исправления, но это не повод не иметь их в базе дефектов.
Проблема в том, что они скапливаются и на них кто-то тратит время в принципе. В горе мусора очень тяжело найти что-то вкусное или полезное. 🙂
Наличие большого числа дефектов в открытом состоянии не проблема, решается через процедуру триажа, например.
ну то есть я понял правильно – тот тест-план, который по какому-то ISO и описан Канером
В целом согласен, с тест-планом имеется ввиду сценарий, где все чтят и уважают тест-план, считая его первоисточником знаний. Но внести изменения в него очень трудно, потому что это делает только один человек и тщательно “фильтрует” заявки со своей колокольни.
ну так отпиши, может не согласен где или может я где-то не так понял (особенно с тестпланом, кстати, неочевидно)
Ну вот как хорошо, мне и не пришлось все расписывать по пунктам. 😉
думал думал и решил написать много
http://zxtesting.blogspot.com/2013/02/via-xp-injection.html
согласен с 99% сказанного Николаем, удивил комментатор:
“> В вашей системе для управления дефектами их больше тысячи в открытом состоянии.
Крупная компания”
эмм, речь про отдел тестирования, а не про компанию, на каждом проекте своя система управления дефектами и если там 1000 открытых багов – это ЖОПА!
“> Существует отдельно стоящий отдел тестирования, в котором каждый тестировщик может тестировать разные проекты. Часто время тестировщика расписано в процентном отношении между этими проектами
Эффективная компания”
идиотская компания, а не эффективная, тестировщик должен думать про один проект на протяжении всего цикла релиза, иначе его эфективность на обоих проектах будет не выше 50% на каждом, то есть то, что он делал бы на одном проекте за час, на двух будет делать по два на каждом, причём скорее всего он будет отдавать приоритет внимания на один из проектов и реальная картина будет где-то 80% эффективности на одном проекте и 20% на другом.
“> Отдел тестирования постоянно растет и тестировщиков становится все больше. Потом появляются тест лиды, менеджеры, но процесс не останавливается.
Быстро-растущая компания”
в пределах проекта? в отсутствии роста количества функционалов и их сложности? это конечно нужно уточнить в тексте, но нет.
Есть определённы предел, после которого рост числа сотрудников в команде будет приводить просто к похабному исполнению работы “ветеранами” и спихиванием работы на “новичков”. А ещё неплохо учитывать, что увеличение числа людей в команде приводит к падению производительности, то есть то, что 1 человек сделает за 3 дня, 2 человека сделают в лучшем случае за 2, а не за 1,5, а 3 – за 1,5, а не за 1.
“> По результатам тестирования тестировщика могут либо наказать либо похвалить
Адекватная компания”
неадекватная компания 🙂 крайне рекомендую почитать на эту тему Джоэля Спольски, старый гей-майкрософтовец шарит ))
“> Отчет о тестировании составляется руками и требует больших усилий
Смотря что понимать под отчетом”
отчёт о проделанной работе (баклог, тасклист, статус репорт бла бла бла), он должен быть максимально автоматизирован и тестировщик (да и любой член команды) должен иметь возможность заполнить отчёт практически мгновенно, не затрачивая на это умственных сил. То есть репорт должен быть максимально механической работой.
По поводу пункта “Существует отдельно стоящий отдел тестирования, в котором каждый тестировщик может тестировать разные проекты. Часто время тестировщика расписано в процентном отношении между этими проектами.” – часто это вынужденная мера. Особенно в небольших компаниях. Когда проектов несколько, но ни один из заказчиков не согласен брать тестировщика на full time. При этом нельзя твердо сказать, что тестирование от этого страдает – по разному бывает. Думаю, что если будет отдельный отдел/команда, где каждый (или несколько сразу) тестировщиков будут отвечать только за свой проект, то это вполне нормально. Пусть и противоречит при этом принципу “тестировщик должен быть частью команды”.
Автоматизаторов, которые разрабатывают свой фреймворк, я бы вообще бил по рукам. Расширяйте существующие! Благо, большинство из них – open source.
Самыми важными из перечисленных мне кажутся пункты 1,3,4,6,7,8. Остальные скорее являются следствием этих пунктов или их продолжением.
Ага, ага. :)))
> В вашей системе для управления дефектами их больше тысячи в открытом состоянии.
Крупная компания
> Существует отдельно стоящий отдел тестирования, в котором каждый тестировщик может тестировать разные проекты. Часто время тестировщика расписано в процентном отношении между этими проектами
Эффективная компания
> Отдел тестирования постоянно растет и тестировщиков становится все больше. Потом появляются тест лиды, менеджеры, но процесс не останавливается.
Быстро-растущая компания
> По результатам тестирования тестировщика могут либо наказать либо похвалить
Адекватная компания
> Отчет о тестировании составляется руками и требует больших усилий
Смотря что понимать под отчетом
>Статья для мыслящих.
а заодно и для читающих между строк? 😉
Александр: Проблема в том – что определение важности – очень субъективно… Конечно основные критерии можно зафиксировать. Но нельзя не учитывать и альтернативные мнения.
Для этого собственно и делается триаж, который у нас к сожалению не практикуется.
Тогда это будет не тест, а навязывание контекста. Статья для мыслящих. 😉
> Тестировщики находят совершенно непонятные и
> надуманные проблемы и ставят им высокую важность.
Можно четко и недвусмысленно расписать критерии определения severity, убедиться, что все всё правильно поняли … необоснованной “важности” станет меньше
> Надеюсь вы понимаете, что речь идет об открытых дефектах
Кстати, нет , я понял буквально) Может, имеет смысл снабдить каждый пункт пояснениями?
Для этого он и тест. Так можно тест на алкоголизм проходить и отрицать правду: “не, ну а что тут плохого выпивать с друзьями каждый вечер? ведь это после работы расслабиться…”.
На ваше недоумение по поводу 1000 дефектов поясню. Надеюсь вы понимаете, что речь идет об открытых дефектах. Так вот, такое количество означает что вы либо потратили много времени на никому не нужные мелочи, либо к вашему мнению не прислушиваются отстальные, либо неверно расставлены приоритеты, либо вы просто храните весь хлам в надежде “авось пригодится, нельзя же выкинуть”.
Последний пункт не менее плох. Приведу пример из жизни – у вас завален хламом балкон, все шкафы и полки. Каждый раз когда нужно что-то достать или найти, вы тратите много времени, но хлам упорно не выбрасываете. Места для новых вещей нет, поэтому вам приходится перебирать периодически хлам в поисках “самого бесполезного”. А все остальное пусть пока лежи, авось пригодится…
То есть в 99% проектов хотябы что-то но не так. гы гы
Даже если системе 10 лет – лучше чтобы багов вообще не было. У нас тоже старая система и багов много. Я не говорю, что у нас все хорошо.
Могу добавить – Тестировщики находят совершенно непонятные и надуманные проблемы и ставят им высокую важность.
… И важность не допускается пересматривать. Говорят – если менять severity – статистика портится по дефектам.
Сам я думаю, что важность дефекта – понятие относительное.
Примерно половина пунктов довольно сомнительна и, вообще говоря, ни о чем хорошем или плохом не говорит..
Взять хотя бы “В вашей системе для управления дефектами их больше тысячи.”… А если продукту 10 лет, а если в нем несколько миллионов строк кода ? )