Требования есть, но они неполные или некорректные. Что делать??
Это очень распространённая ситуация. Безответственные тестировщики пользуются ею, чтобы иметь оправдания плохому тестированию "а что я, у нас даже требований нормальных нет, я об этом не знал" и т.д. Если наша задача - качественный продукт, а не отмазки, давайте посмотрим, что мы можем сделать:
·Договориться заводить баги на требования в баг-трекер. Их можно помечать специальным образом, заводить в отдельную очередь, на отдельный компонент - реализация зависит от того, какой баг-трекер вы используете. Какие от этого плюсы:
·Вы структурируете работу аналитика. Ему тоже тяжело, он не всегда может решить проблему "нет требований". Зато, он может решить конкретные баги - это значительно проще!
·Вы всегда можете оперировать количеством дефектов на требования - это мотивирует к их исправлению!
·Проводить тестирование требований. Причём, это наиболее полезно делать ДО разработки. Каким образом тестировать требования? Проверять их на понятность, непротиворечивость, полноту, тестируемость. А иногда и сразу делать по ним предложения "это лучше было бы сделать по-другому, вот так". Причём, для тестирования требований не обязательно их документирование! Если у вас принято передавать их из уст в уста, то это тоже можно тестировать! Что это даёт:
·Ошибки находятся раньше! Аналитики часто ошибаются, и мы заводим ошибки, когда код уже написан. Но зачем? Мы можем предупредить о проблемах заранее, и это повысит эффективность всей команды!
|
|
|
·Если мы заранее начинаем знакомиться с требованиями и анализируем их, то к моменту готовности кода мы уже хорошо понимаем, как его тестировать! А это тоже экономия времени.
Требования есть, ура! Надо ли что-то делать?
Редко, но такое тоже бывает. У нас есть требования, документированные или устные, возможно, полученные благодаря нам на первом или втором варианте. Что дальше?
Дальше важно оценивать тестовое покрытие. Чем вообще отличается тестирование от поиска дефектов? Поиск дефектов предназначен для заведения как можно большего количества багов, но при этом не гарантирует качество продукта! Что же такое тестирование? Это проверка, что весь функционал реализован, соответствует требованиям пользователя и готов к использованию на требуемых окружениях. Для этого нам надо не просто искать баги - нам надо оценивать состояние продукта!
А какой лучший способ это делать? Анализировать готовность требований! Вместо фраз "ничего не работает" мы можем сообщать процентное соотношение реализованных и нереализованных требований, статус их работы и т.д. В итоге, мы получаем цельное видение нашего продукта в разрезе требований к нему.
|
|
|
Если у нас есть требования в задокументированном виде, мы можем сделать так называемую traceability matrix, или связать требования и тесты. Или же мы просто можем сделать табличку с перечнем требований, чтобы по каждому указывать статус работоспособности. Нет документированных требований? Всё равно можем сделать табличку на основании нашего знания о работе продукта :)
Истина #11: эффективно работая с требованиями, мы можем повысить эффективность и скорость разработки нашего продукта, принести пользу проекту и пропускать меньше дефектов! При этом, требования не обязательно должны быть кем-то документированы, при отсутствии документации мы можем сделать это сами!
Где подробнее узнать о работе тестировщиков с требованиями?
·В моей статье про работу с требованиями (полезнее для тест-менеджеров, но применимо на любом уровне ответственности)
·Статья на википедии про требования (даёт замечательный список характеристик требований, на соответствие которым их полезно тестировать)
До связи!
Выпуск #7: Что есть баг, или 5 школ тестирования
Привет,
Сегодня я хочу рассказать про 5 школ тестирования. Насколько мне известно, впервые информацию про них структурировал Bett Pettichord в своейпопулярной презентации, до этого информация про различные школы мелькала в блогах таких именитых тестировщиков, как Джеймс Бах, Рекс Блэк, Сэм Канер и многих других.
Для начала я вкратце пересскажу на русском языке содержание презентации, в то время как желающие углубиться в познание темы могут либо рассмотреть первоисточник, либо погуглить англоязычные сообщества.
Дата добавления: 2018-02-28; просмотров: 852; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!