Тестирую уже 8 лет. Ручной и автоматизированный, как тестировщик и тест-менеджер, как сотрудник компании и как представитель аутсорсера.
И практически на всех проектах я сталкиваюсь с одной и той же проблемой: менеджеры проектов не понимают, зачем им тестирование.
Если задать среднестатистическому РМ простой вопрос: «Зачем на этом проекте тестированиеЭ», то чаще всего ответом будет «Вы — тест-менеджер, вы должны ответить на этот вопрос».
А разве вы, приходя в парикмахерскую, не говорите парикмахеру «ты сама знаешь, что мне нужно»? А в продуктовом магазине вы не просите продавца бросить вам в тележку то, что вам нужно.
тебе нужно? Вы можете посоветоваться, можете узнать «как это возможноЭ», спрашивать варианты, но решение всегда за вами.
В чем разница между тестированием? Может быть, это потому, что слишком мало руководителей проектов понимают, зачем им это нужно?
В этой статье я попробую выступить в роли продавца, который показывает клиенту: «что на самом деле происходитЭ» Многое будет описано, возможно, слишком подробно, слишком просто.
Не сердитесь, я просто очень хочу, чтобы меня поняли :)
Зачем вообще возлагать какие-то надежды на тестирование?
Камон! Тестирование — это нажатия всяких кнопок, хорошо, если они будут автоматизированы.Упс.И понятно, какие цели! Вам нужно найти ошибки, и чем их больше, тем лучше.
Какие еще цели может иметь тестирование?
Если исходить из такого подхода, то с тестированием во всех компаниях все в порядке.
Баги находят, исправляют, проверяют. Значит, тестирование всегда полезно? Всегда полностью раскрываете свой потенциал?
Что-то мне подсказывает нет. Тогда в чем же разница между теми редкими случаями, когда «с тестированием все хорошо» и подавляющим большинством?
Попробую привести еще одну иллюстрацию.
Тебе никогда в жизни не делали массаж.
Вы заходите в салон (ну все ходят, почему бы и вам не пойти?) и заказываете получасовой сеанс.
У вас фиксированный бюджет и требования: «Сделай мне массаж».
Невнятная на вид дама нечленораздельно теребит ваши вполне внятные плечи, кайфа нет, выходишь из салона и думаешь «эх, массаж полная фигня».
Но ваше требование «помассируйте меня» было выполнено! Может быть, дело в том, что требование неверно? У вас болела спина и вы хотели, чтобы боль прошла? Или не хватило растяжки? Или вы хотели расслабиться? Чем точнее требования, тем больше вероятность, что подрядчик их удовлетворит. Но если вы не сможете сформулировать, чего хотите, то исполнитель не сможет сделать то, что нужно, и вы не сможете объективно оценить результат.
Каковы могут быть ожидания от тестирования?
Тестирование необходимо для улучшения качества продукта.Упс.Ну это же очевидно!
Простой пример из практики.
Команда тестирования своевременно находит дефекты, команда разработчиков не успевает их исправить, продукт выходит на рынок без изменений, клиенты говорят «отстой»… Тестирование было плохим?
Или давайте сделаем наоборот. Тестировщики тщательно исследуют продукт, используя его и хвостом, и гривой, не находят ни одной ошибки, он выпускается на рынок, пользователи довольны, шапки летают в воздух, цветы присылаются на адрес компании-разработчика.
Тестеры хорошие или нет? В общем, примеров можно привести много.
Но вывод почти всегда один: тестирование не влияет на качество.
Точно так же, как ваша прическа не влияет на ваш успех.
«Ой, парикмахер, подстриги меня, чтобы я сдала экзамен!» Никакой логики, да? То же самое и в тестировании.
Тестирование предоставляет информацию на определенный бюджет, в определенном формате, с определенной скоростью.
Но тестирование никак не влияет на качество, даже если очень этого хочется.
Что же тогда может дать тестирование? Все наши результаты, вся наша работа описывается формулой четырех переменных: тестовое покрытие, предоставляемая информация, скорость и бюджет. Давайте сначала разберемся с этими моментами, а затем перейдем к самим формулам.
1. Тестовое покрытие
Это % возможных пользовательских сценариев, условий, настроек, входных параметров и т. д., проверенных командой тестирования.Чем выше этот процент, тем больше ошибок обнаружено и меньше пропущено.
Чем больше ошибок Может поправьте, если есть желание и возможность.
При этом тестовое покрытие и количество тестов, а также ресурсы, потраченные на тестирование, связаны весьма косвенно.
Квалифицированные тестировщики обладают целым арсеналом техник и инструментов, которые позволяют им «впихнуть невозможное», то есть оптимизировать набор тестов, то есть обеспечить максимальное покрытие при минимальном количестве тестов.
Покрытие можно и нужно измерять: матрицу трассируемости, покрытие кода, % пропущенных дефектов и массу других метрик, которые вам в помощь.
2. Предоставленная информация
Уже много лет существует мем о тестировщике, говорящем: «Ничего не работает!» с паникой в глазах.А если попросить объяснить подробнее, он отвечает: «Ну вообще ничего!» Возможно, он обеспечил хорошее покрытие тестами, но, к сожалению, не предоставил адекватной информации.
Какая информация может понадобиться проекту при тестировании?
- Качественно описанные ошибки в баг-трекере
- Статистическая информация о продукте для прогнозирования выпуска и принятия технологических решений.
- Метрики качества для принятия решений о выпуске
- Оценка самого тестирования: какое покрытие тестируется, насколько тестирования достаточно и т.д.
3. Скорость тестирования
Ладно, освещение хорошее, информация ясна.Слишком поздно.
Или надолго.
Или это долго и поэтому поздно.
Все вы явно сталкивались с ситуацией: до релиза осталось 3 дня, есть критический баг.
Разработчику бьют по голове, он начинает его исправлять, а потом оказывается, что этот баг существует уже полгода, а на самом деле его можно было обнаружить гораздо раньше.
И что этот баг 2 месяца назад исправили бы за полчаса, но сейчас на него завязано пол продукта, и с ним придется возиться неделю.
Мало кто берется анализировать проекты на основе ЗБТ , и мало кто замечает, что тестирование иногда удлиняет релизы в несколько раз.
Так что замените тестирование своевременным тестированием и получите релиз в два раза быстрее.
Обычно это незаметно, и кажется, что баги — источник всех бед… Но иногда найти их раньше — значит сократить затраты на весь цикл разработки! Или другой аспект скорости тестирования: время, необходимое для проверки сборки.
Например, мы готовимся к релизу.
Получаем RC (релиз-кандидат).
На тестирование нужна неделя, чтобы убедиться, что всё работает, РМ соглашается, выделяет неделю, на пятый день критическая ошибка.
10 минут на исправление, и снова 5 дней, и снова на пятый критическая ошибка.
.
Вы сталкивались с этим? Звучит знакомо?
4. Бюджет
Это, пожалуй, самый простой момент из всех.Естественно, это относительно.
1000 рублей – это много или мало? Для буханки хлеба, пожалуй, это много, для поездки на Бали, пожалуй, мало.
Поэтому бюджет — это деньги, которые вы готовы платить, но не за «тестирование», а за конкретные и понятные результаты этого самого тестирования.
Ну и что дальше?
И вот что.Чтобы принести максимальную пользу проекту, необходимо точно знать, что ему сейчас нужно.
Чтобы знать, что необходимо, нужно проанализировать его показатели, что именно выходит за рамки нормы: сроки, качество или бюджет. А после этого создайте свою уникальную формулу с требованиями к тестированию.
При этом будем честными: «сократить сроки» или «увеличить охват» — это все то же «помассируйте меня».
Нам нужны точные показатели.
За что? Чтобы оценить изменения.
Чтобы следить за тем, действительно ли они влияют на производительность всего проекта в целом (скажем честно, само покрытие вам не нужно!).
Чтобы контролировать процесс.
Обратите внимание, я никогда не говорил «юнит-тесты», «автоматизация», «тест-дизайн» и т. д. Все действия вводятся в процесс только по результатам достижения определенных целей! Хотите повысить скорость тестирования сборки? Внедряем автоматизацию.
Вам нужно увеличить скорость поиска дефектов? Юнит-тесты.
Качество отчетности? Дефектная модерация.
Существуют сотни подходов, инструментов и решений, которые можно протестировать.
комбинируйте в зависимости от ваших целей.
Но сами инструменты вторичны.
Поэтому КАК тестировщик/тест-менеджер/аутсорсер тестирования достигнет ваших целей – это его головная боль.
Но лучше внимательного к своему проекту РМ никто не сможет сказать, что этому проекту нужно! Теги: #тестирование #проекты #PM #Управление проектами
-
Microsoft Response Point Выходит На Рынок
19 Dec, 24 -
Мобильная Разработка. Галерея Шаблонов
19 Dec, 24 -
И От Тебя Не Ожидается, Что Ты Это Поймешь.
19 Dec, 24 -
Asp.net: Трассировка — Полезная Функция.
19 Dec, 24 -
Шуточный Прокси Для Git
19 Dec, 24
