В очередной раз поставили задачу максимально некорректно. Типа: "У нас обновление такое-то. Потестируй там что-нибудь..".
Нервы мои не выдержали, и я разразился очередным документом "Постановка задачи тестирования". Документ этот содержит список простых вопросов, ответы на которые необходимо получить перед началом тестирования. К сожалению, многие не понимают, что только корректная постановка задачи приводит к желаемому результату :(
Вполне допускаю, что список не совсем полный, но по мере необходимости буду дополнять и корректировать. Замечу, что эти вопросы перекликаются с вопросами, размещенными в предыдущем посте, но цели у них разные.
Постановка задачи тестирования
1. Что именно нужно тестировать? (дистрибутив, ссылки на веб клиенты).
2. Вид тестирования (Функциональные (+уровни тестирования); Нефункциональные; Связанные с изменениями).
3. Как тестировать? (что конкретно должно быть протестировано, что должно быть проверено обязательно, что дополнительно, что "если останется время").
4. Где документация? (спецификация, требования).
5. Когда и как долго тестировать? (сроки, время начала, если сразу нельзя начать)?
6. Где тестировать? (адреса, ссылки, машины, ОСи, окружение)?
7. Чем тестировать? (инструменты, файлы)?
8. Где необходимые инструменты, артефакты? (файлы, базы, логины, пароли, учетные записи, сертификаты и т.д.).
9. К кому обращаться за дополнительной информацией?
11. Что делать с результатами?
12. Необходим ли отчет? (если да- см. заявку на отчет).
13. Критерии успешного (неуспешного) тестирования. (если необходимо дать оценку, заключение).
10. Дополнительные инструкции.
Сообщения
Зависит от ситуации, конечно, но в некоторых случаях некоторые вопросы из списка тестировщик должен определять сам, и никто из начальства ему это не скажет, так как это входит в его обязанности. Например, пункты 2, 3 (должно следовать из требований), 7, 13.
ОтветитьУдалитьЧитая статьи тестировщиков складывается впечатление, что тестировщикам все всё должны давать. "Дайте нам то", "дайте сё","скажите как это".
ОтветитьУдалитьПо моему мнению тестировщик сам должен все это делать и поддерживать обратную связь с руководством. Дали задание протестировать - тестировщик сообщает что и как он собирается тестировать. Другими словами тестировщик должен составлять план тестирования.
Товарищи может хватит жаловаться на плохую жизнь. Чес слово, коллеги тестировщики...
Пример: есть некое ПО, состоящее из клиентской и серверной частей. Документации нет. Приходит задача- "протестировать "название ПО"". Как поступаем в таком случае? Что тестируем?- функциональное или регрессионное клиентской части? А может нагрузочное серверной? Почему-то вообще ничего не работает... а! оказывается сменили пары логин\пароль...
ОтветитьУдалитьЯ что- должен мысли чужие читать, чтобы все это знать?
Идем к постановщику задачи, выясняем у него и у тех, к кому он будет отсылать за подробностями, ответы на поставленные вопросы- тратим свое и чужое время. Хотя могли бы потратить его с гораздо большей пользой.
Я прекрасно понимаю, что почти на все эти вопросы можно получить ответы вполне самостоятельно и раздобыть всю нужную информацию, но какой ценой? Сколько времени я потеряю в таком случае? А если регулярно?
Понятно, что такие постановки редкость, но они иногда случаются. И вот чтобы избежать этого, надо чтобы постановщики хоть немного думали о том, что пишут.
Да, я сам вполне могу определить и вид тестирования и метод, и распределить, и спланировать у себя в группе работы, но может требовалось-то совсем другое от нас?..
Андрей,
ОтветитьУдалитьИногда цена работы постановщика задачи стоит дороже такого же времени работы нескольких тестировщиков... Так что искать информацию самим - есть нелегкая задача мнгих тестеров.
Единственное. если постановщик задачи разумный человек - он будет экономить и ваше и свое время правильной постановкой задачи. Такие вопросы могут натолкнуть егов нужную сторону...
Максим, "Такие вопросы могут натолкнуть егов нужную сторону..."- вот это вот и есть основная цель. :)
ОтветитьУдалитьДобавил картинку последней версии.
ОтветитьУдалитьНе будьте так категоричны.
ОтветитьУдалитьЕсли бы мне дали, я бы вот тогда......
Я считаю, что если Вы специалист своей области Вы самостоятельно определите виды и способы тестирования.
Подумайте...
Гораздо хуже, когда вам ставят абсолютно тупые задачи люди, которые понятия не имеют что такое тестирование и что от него ждать.
Все познается в сравнении.
Не вешайте голову. Не ругайте всех, что вам что то не дали.
По поводу шаблона заявки на тестирование.
ОтветитьУдалитьДа, плохого в этом ничего нет.
НО.
Он не очень подходит для компании, в которой есть отдел тестирования и разработки.
Вот если тестирование выносится на аутсорс, тогда да... (кстати сказать сторонняя организация которая будет проводить тестирование запросит горАздо больше документации).
А для внутреннего пользования я думаю это лишнее.
Все что должны дать разработчики - это готовый билд (серверное приложение + клиент) и список реализованных фич (требования или исправление ошибок).
Все.
Надеюсь, что не надо объяснять, что у вас к этому времени уже должен быть примерный план тестирования.
Влад, как я уже упоминал выше, с организацией тестирования с моей стороны проблем нет. Рассматривалась ситуация, когда как раз "ставят абсолютно тупые задачи"...
ОтветитьУдалитьЕсли от меня хотят что-то конкретно- пусть объяснят что. Вместо того, чтобы через полчаса уже спрашивать о каких-то результатах.)
Просто иногда у нас такие случаи происходят. К сожалению.
У нас внутренняя организация несколько сложнее чем обычно- 2 отдела разработки (первый разрабатывает на основе результатов работы второго). Когда в тестирование поступает что-то из второго отдела- проблем нет (и списки реализованных фич, требований и набор билдов, и описание реализации и тд), но вот когда поступает что-то из первого отдела- жесть. Что-то где-то как-то сделано...как работает никто объяснить не может, не говоря уже о том, чтобы объяснить как должно работать. Вот для борьбы с такими случаями и пришлось формализовать деятельность шаблоном.
Влад, на самом деле есть определенный смысл в таком шаблоне, и помимо билда и релиз-ноутс разработка должна предоставить хотя бы минимальные требования к тестированию, в частности должны быть предоставлены окружение, на котором тестировать, тип тестирования. это как минимум. а спецификации - это вообще больная тема.
ОтветитьУдалитьТак то оно так, тестировщик получил таск, сочинил тест план, обсудил с начальством и вперед работу работать. Но мне встретилась другая крайность, таск звучит так "мы тут подумали и решили, что было бы инетересно почитать твой отчет с точки зрения тествирощика о "название ПО"" - что я должен был тут делать, тяжело сказать. Я написал черновой вариант тест плана и отправил на рассмотрение. Сразу вспомнился этот блог и крик души автора написавшего статью выше.
ОтветитьУдалитьСергей, а в чем проблема?
ОтветитьУдалитьАндрей, мне например, совсем неясна постановка задачи в подобном виде.
ОтветитьУдалитьСергей, а у вас после итераций тестирования отчеты пишутся? Если да- то может быть его и хотели, но несколько более развернутый. Если нет- то может именно просто отчет?
ОтветитьУдалитьАндрей. В данный момент я не работаю в этой организации. Это "тестовое задание" было таким образом сформулировано.
ОтветитьУдалитьЗабавно. А-ля количество бензоколонок где-нибудь в Урюпинске, но с ориентацией на тестирование...
ОтветитьУдалить