Всего лишь пара изменений

Чем хороши изменения требований — они, пусть даже и возникают неожиданно, а все равно пройдут весь традиционный круг оценок и планирования. Ну ладно, должны проходить. Но все равно об изменениях мы узнаем заранее.

Но не всегда тестировщик заранее знает, что что-то в поведении продукта изменится. Приходит он на работу, берет свежий билд приложения и видит, что добавились/пропали/переехали контролы в GUI. Или поменялась очередность шагов визарда. Или изменилась давно привычная логика работы. Да мало ли что. А чтоб такие изменения планировались, он и не слышал. Баг писать? Или так и должно быть теперь?

В целом понятно, что если оснований для изменений нет, то со стороны тестировщика честно будет написать баг. Возможно, этот баг потом выкинут, но зато хоть повод для обсуждений появится.

Другой вопрос — как такая ситуация могла возникнуть. Есть варианты, да. Возможно, потихоньку идет процесс улучшения GUI и юзабилити продукта. Или — прилетел баг от клиента, и его починили в продукте, а тестировщик этого бага и не видел пока. Или — над продуктом работают несколько команд разработчиков и тестировщиков, каждая в своей песочнице, и время от времени их наработки добавляются в новые билды. Много чего возможно.

И вопрос — как эти изменения контролировать?

В маленьких командах этот вопрос, наверное, не очень актуален, но чем больше людей, тем сложнее работать с изменениями. Тем более, что разным людям и в разное время нужны разные данные об изменениях. Но в любом случае, первое, что приходит на ум — это

Сообщать об изменениях

Сообщать, по большому счету, можно любым способом — словом, письмом, страничкой в вики и т.д. Что удобнее в каждом отдельном случае — зависит от размера команды, масштаба изменений и еще примерно трехсот параметров.

Что именно сообщать — тоже во многом вопрос контекста, но в любом случае стоит упомянуть, в чем суть изменения, на каком основании оно сделано, с какого момента оно вступает в силу.

В принципе, так можно сообщать не только о неожидаемых изменениях, но и о готовности [части] фичи к тестированию. Понятно же, что не всякое изменение — фича, но всякая фича — изменение.

Ок, нам сообщили, можно жить и радоваться. Тестировщику — наверное, да, можно. А его начальнику, возможно, пора задуматься, как

Сохранять историю тестирования изменений

Мы же тестировщики; если что-то изменилось — наша работа проверить, что все продолжает работать как нужно.  А по итогам тестирования мы должны ответить — что было протестировано в контексте данного изменения, когда (в каких билдах), с каким результатом.

Опять же, как сохранять эту информацию — дело вкуса. Кому-то подойдут ответы на письма об изменениях. Кто-то захочет все свести в единую таблицу. Важно чтоб в итоге было удобно с этими отчетами работать.

Впрочем, история — это хорошо и полезно, но иногда стоит еще и

Планировать тестирование изменений

Действительно, на одну и ту же функциональность может прилететь несколько изменений, затрагивающих разные нюансы. С точки зрения тестирования может быть дешевле проверять такие изменения не по мере поступления, а все скопом.

Тут, правда, нужно как-то узнать, что планируется N изменений в данной части продукта, а это не всегда возможно. Про фичи-то мы знаем, конечно, а вот с мелкими изменениями и фичами других команд дела обстоят посложнее.

Кроме того, не надо забывать про баги. Откладывая тестирование до момента внесения всех ожидаемых изменений, мы и починку внесенных багов откладываем на тот же (или больший) срок. Риск, ага.

 

Контролировать изменения или нет, и как тщательно, — дело каждого отдельного проекта. Лишь бы изменения не засыпали проект с головой.

Удачи вам, внятных требований и контролируемых изменений.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *