Как можно меньше, но чтобы все узнать. Важно не переборщить.
Вот решила я создать интернет-магазинчик кухонных мелочей. Пока есть только товар и общее представление, что «должно быть как Озон, а там придумаем как сделать лучше». И вот я даю такую задачу разработчику, он молча кивает и уходит делать. Зато тестировщик заваливает вопросами:
— А сколько разделов будет на сайте?
— А что, если их будет больше 100?
— А что, если товаров в разделе нет?
— А что, если я захочу купить 1 предмет?
— А если 10?
— А если 50?
— А если мне нужно 2 одинаковых?
— А что, если я закажу доставку за МКАД?
— А внутри МКАД?
— А какого цвета будет кнопочка заказа?
— А в каком порядке пойдут разделы?
— А …
Когда я вижу огромный пласт вопросов на «простенькую задачу», я прихожу в ужас — «И что, мне на все на это надо отвечать???». Потом начинаю вчитываться и раздражаюсь, ведь если это все вопросы ко мне, то зачем мне вообще работать с такой командой, которая шагу ступить без одобрения не может?
Не пытайтесь заменить аналитика. Это его задача — продумать требования вплоть до мелочей и уточнить все детали. И аналитиков отдельно учат задавать вопросы. Так, чтобы не додумывал, но и чтобы не заваливал заказчика вопросами.
Поэтому все мелкие детали «а что, если я проведу негативный тест?», спрашиваем у аналитика. При этом их можно объединить. Сравните, при условии «заказать можно от 100 до 300 упаковок товара оптом»:
— А что будет, если заказать 5 товаров?
— А если 0?
— А если -1?
— А если 500?
— А если 100500?
— А если «сто штук» прописью?
И
— Что будет, если заказать не в диапазоне от 100 до 300?
Так мы узнаем, как себя система ведет в негативном сценарии, выдает пустой результат, ошибку, или что-то иное. И узнаем мы это за ОДИН вопрос, а не 100500.
Или если заказчик говорит, что система должна обрабатывать только форматы экселя и csv, сравниваем:
— А что, если загрузить формат doc?
— А что, если загрузить формат docx?
— А что, если загрузить формат txt?
— А что, если загрузить формат xlsm?
— А что, если загрузить формат jpg?
— А что, если загрузить формат JPG?
— А что, если загрузить формат png?
— А что, если загрузить формат rtf?
— А что, если загрузить формат pdf?
— А что, если загрузить файл без расширения?
И
— Распознается любой формат CSV или только расширение .csv? (Если Заказчик не понял вопроса, объяснить разницу между форматом и расширением)
— Другой текст, word, rtf, pdf — не работает?
— Что будет, если загрузить неподходящий формат?
Мысль все та же — думаем о том, что именно мы хотим узнать с помощью этих вопросов. Об этом и спрашиваем. Обычно получается несколько вопросов совместить в один. Плюс выкидываем вопросы, которые не надо задавать:
Вот решила я создать интернет-магазинчик кухонных мелочей. Пока есть только товар и общее представление, что «должно быть как Озон, а там придумаем как сделать лучше». И вот я даю такую задачу разработчику, он молча кивает и уходит делать. Зато тестировщик заваливает вопросами:
— А сколько разделов будет на сайте?
— А что, если их будет больше 100?
— А что, если товаров в разделе нет?
— А что, если я захочу купить 1 предмет?
— А если 10?
— А если 50?
— А если мне нужно 2 одинаковых?
— А что, если я закажу доставку за МКАД?
— А внутри МКАД?
— А какого цвета будет кнопочка заказа?
— А в каком порядке пойдут разделы?
— А …
Когда я вижу огромный пласт вопросов на «простенькую задачу», я прихожу в ужас — «И что, мне на все на это надо отвечать???». Потом начинаю вчитываться и раздражаюсь, ведь если это все вопросы ко мне, то зачем мне вообще работать с такой командой, которая шагу ступить без одобрения не может?
Не пытайтесь заменить аналитика. Это его задача — продумать требования вплоть до мелочей и уточнить все детали. И аналитиков отдельно учат задавать вопросы. Так, чтобы не додумывал, но и чтобы не заваливал заказчика вопросами.
Поэтому все мелкие детали «а что, если я проведу негативный тест?», спрашиваем у аналитика. При этом их можно объединить. Сравните, при условии «заказать можно от 100 до 300 упаковок товара оптом»:
— А что будет, если заказать 5 товаров?
— А если 0?
— А если -1?
— А если 500?
— А если 100500?
— А если «сто штук» прописью?
И
— Что будет, если заказать не в диапазоне от 100 до 300?
Так мы узнаем, как себя система ведет в негативном сценарии, выдает пустой результат, ошибку, или что-то иное. И узнаем мы это за ОДИН вопрос, а не 100500.
Или если заказчик говорит, что система должна обрабатывать только форматы экселя и csv, сравниваем:
— А что, если загрузить формат doc?
— А что, если загрузить формат docx?
— А что, если загрузить формат txt?
— А что, если загрузить формат xlsm?
— А что, если загрузить формат jpg?
— А что, если загрузить формат JPG?
— А что, если загрузить формат png?
— А что, если загрузить формат rtf?
— А что, если загрузить формат pdf?
— А что, если загрузить файл без расширения?
И
— Распознается любой формат CSV или только расширение .csv? (Если Заказчик не понял вопроса, объяснить разницу между форматом и расширением)
— Другой текст, word, rtf, pdf — не работает?
— Что будет, если загрузить неподходящий формат?
Мысль все та же — думаем о том, что именно мы хотим узнать с помощью этих вопросов. Об этом и спрашиваем. Обычно получается несколько вопросов совместить в один. Плюс выкидываем вопросы, которые не надо задавать:
- Что мне надо протестировать?
- Вопросы к гуглу.
См также:
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
вот честно - если компания экономит на аналитике, который должен задавать один вопрос вместо десяти - то пускай терпит эти десять вопросов от тестировщика. А уж от того, что тестировщик задаст десять вопросов аналитику, хуже не будет - спецификации от этого должны становиться только лучше (т.е. не содержать непонятной интерпретируемой информации и т.д.)
ОтветитьУдалитьТо есть вы любите, когда вас отвлекают от работы 10 раз с одним и тем же вопросом? И поэтому считаете, что так должно быть у всех?)
Удалить> И вот я даю такую задачу разработчику, он молча кивает и уходит делать.
ОтветитьУдалить> Поэтому все мелкие детали «а что, если я проведу негативный тест?», спрашиваем у аналитика.
Дак ТЗ для разработчика всё-таки в вашем примере аналитик или заказчик предоставляет?
По разному бывает, могут и сразу разработчику)
УдалитьСпасибо за быстрый ответ!
УдалитьЕсли нет аналитика, и есть серьёзные вопросы к ТЗ, то очень может оказаться необходимым для тестировщика именно что "пытаться заменить аналитика". Или какие варианты?
Если есть аналитик, и именно он формирует ТЗ, то получается, что согласно написанному, тестировщику всё-таки стОит задавать столько вопросов, сколько он считает необходимым - он ведь будет задавать их аналитику.
В приведённом примере, как я понял, задача пришла напрямую от заказчика разработчику, но при этом есть аналитик.
Смысл статьи - в таком кейсе при наличии у тестировщика вопросов по ТЗ, стоит обсудить это ТЗ с аналитиком, а не заваливать мелкими вопросами заказчика. я верно понял?
Пытаться заменить аналитика — хорошо. Но не надо
Удалитьа) спрашивать "а как мне тестировать" — ни заказчика, ни аналитика
б) задавать 10 вопросов там, где можно задать один — и меня очень смущает, что "заказчика правда не надо дергать, а аналитик хай страдает", какое-то странное отношение. К аналитику тогда, получается, не стоит и правило 20 минут применять? Пришла мысль — отвлек и озвучил? И собирать вопросы пачкой, чтобы отвлечь один раз, не надо? Ну не заказчик же, потерпит...
По поводу "а как мне тестировать" - полностью согласен. Тестировщик на то и тестировщик, чтобы знать как тестировать.
Удалить"Задавать 10 вопросов там, где можно задать один" - я не спорю, но это ведь очень общий принцип. Он применим к любой ситуации, непонятно, что тут специфичного именно для вопроса из заголовка статьи - Сколько вопросов задавать по ТЗ. Но если смысл статьи - именно про применение этого принципа для этого конкретного случая - то ок, я с этим согласен. Просто не увидел этого сразу. Извините :)
я не говорю, что "аналитик хай страдает". я пытался понять смысл статьи, опираясь на написанный в ней текст - непонятка возникла именно из-за того, что вначале аналитика вообще в процессе постановки задачи не было, а потом он появился в середине статьи как один из агентов.
Согласна, что это общий принцип. В заголовок добавила про ТЗ, чтобы было понятно, о чем речь вообще :) Ну и потому что это выдержка из книги и там речь про ТЗ ))
Удалить>> А что, если загрузить формат xlxsm?
ОтветитьУдалитьа если xlsm?
Спасибо, исправила)
УдалитьЗдравствуйте. Получается вопрос "Как тестировать?" вообще нельзя никому задавать? Просто бывают задачи, которые непонятны из-за того что оформлены "языком разработчика" и тут хоть весь гугл перерой, но вряд ли более понятнее она от этого станет.
ОтветитьУдалитьМожно, коллегам, обращаясь за помощью.
УдалитьИли разработчику, да, если совсем непонятно "а как это проверять"