четверг, 7 апреля 2011 г.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

8 комментариев:

  1. а делать дифф кода при коммите (а еще лучше во время начала билда, если пользуетесь какой-либо системой непрерывной интеграции), а затем парсить дифф на интересующие изменения? такой подход не интересно?

    ОтветитьУдалить
  2. интересно, но
    - может использоваться только как вид извещения об изменении. История тестирования, управление изменениями летят мимо.
    - сообщает о технических изменениях, но не о изменениях бизнес-логики.
    - наличие изменения в коде не означает, что это изменение нужно было делать (и нужно было делать так).

    Как нотификалка о факте изменения может использоваться, да. Так же как и уведомления о выполненных коммитах в систему контроля версий.

    ОтветитьУдалить
  3. Так собственно парсинг кода и позволяет смотерть что именно изменилось. Возможно, парсинг не хороший термин в данном случае. Объясню по другому.

    Скажем, если у меня есть веб-портал, то отслеживать изменения в коде страницы я фактически могу, например, смотря на диффы исходников, которые отвечают за интерфейс (в моем случае это *.jsp). А другие файлы просто исключаются из рассмотрения.

    Думаю, теперь яснее. Вот анализ пока идей как сделать нет) Есть желание при коммите или начале билда получать на почту письмо с изменениями в контролах - сильно упростит поддержку тестового кода. В данном случае я имею ввиду автоматизацию.

    Бизнес логику меняют - наверняка можно определить пул файлов, в которых можно это отследить. Если произошло крупное изменение, и были добавлены новые исходники -тоже по зависимостям можно отследить и по факту добавления новых файлов, попадающих под интересующую маску.

    Это естественно технический аспект.

    Что понимаете под историей тестирования? Баг-трекинг сюда нельзя прикрутить?

    Управления изменениями? Специализированные тулы наверняка можно найти. Типа DOORS. смотря что именно вы под этим понимаете.

    Давайте пообщаемся подробнее) Мне интересна эта тема - сам постоянно мучаюсь. Но у меня в основном касается вопрос синхронного изменения кода автотестов вместе с кодом приложения.

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

    ОтветитьУдалить
  4. [в один комментарий не влезает, разобью на два]

    Как это видится мне.

    Изменения бывают разные и в разных местах. В UI, в бизнес-логике, во внутренней логике приложения, в устройстве БД. etc. Внесение новых фич, исправление багов, рефакторинг кода, и т.д. Изменения могут вносить разные команды разработчиков (далеко не у всех так, я понимаю, но вот у нас - так), которые сидят в разных городах и к которым прикреплены свои команды тестировщиков.
    Все эти изменения [рано или поздно] попадают в некий очередной билд.

    Распарсив дифф мы выгребем все эти изменения.
    Дальше встает вопрос - как интерпретировать то, что получилось.

    Можно для начала отбросить все, что не относится к модулям, над которыми работает наша команда.
    Только этого делать нельзя.
    Во-первых, работа наших модулей может зависеть от работы чужих посредством бизнес-логики или внутренней логики приложения. Это не повод детально тестировать их изменения, но общее представление иметь нужно - хотя бы чтоб бессмысленные баги не постить.
    Во-вторых, даже если внесенные изменения нас практически не касаются, полезно знать, чем они там занимаются - может, изобретают новый велосипед, когда уже есть подобный и прекрасно ездит. А может прикручивают что-то интересное, что и нам может быть полезно/интересно.
    Другое дело, что пытаться понять смысл подобных изменений по коду - лишняя трата времени, особенно если это будет делать каждый работник в проекте. Куда как проще получить краткое описание от соответствующей команды - что, зачем, как - и дать эту информацию всем интересующимся.

    Ну ладно, выбросили чужие изменения, остались наши. Что мы можем понять, глядя на них.
    Многое можем, верно.
    Отдельно посмотреть на UI-код и код бизнес-логики. Сравнить изменения в процедуре апгрейда и свежей установки. Увидеть, что [КНОПКА] будет показана только когда переменная showButton == True. Заметить, что объект А теперь не может быть создан, если уже имеется объект Б. Обратить внимание, что при свежей установке теперь создается новая таблица в БД, а при апгрейде ее создать забыли.
    И, в общем, уже видно, что проверить, куда посмотреть внимательней, где поковырять сильнее.
    Нет, правда, очень здорово.

    Но нет ответа на два вопроса:
    - по какой причине эти изменения произошли?
    и
    - какие изменения должны были быть внесены, но не случились?

    Без ответа на первый вопрос трудно понять, как правильно тестировать внесенные изменения. И трудно ответить на второй вопрос.
    То есть все равно придется пойти и спросить - а зачем это вообще, и как оно должно работать?

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

    Знание кода помогает оптимизировать усилия по тестированию.
    Но, вообще говоря, клиенту неинтересно, что там в коде менялось. И даже руководителю проекта не очень интересно.
    Клиенту нужно просто чтоб все работало так, как он ожидает. Начальнику интересен статус проекта - что сделано, что нет. Ну и позже - почему у пользователей что-то работает не так, как они ожидают.
    То есть они оперируют не в терминах кода, а в терминах фич и, возможно, тех самых изменений. Начальник не спросит "Вы проверили изменения кода за среду?" Он спросит - "Как там дела с фичей ХХХ? А исправление логики в NNN проверили?".

    В этом месте мы переходим к отчетности и истории тестирования.

    ОтветитьУдалить
  5. В этом месте мы переходим к отчетности и истории тестирования.

    Грубо говоря, отчет о тестировании имеет некоторое [счетное] количество детализаций.

    Просто пример из головы.
    Самый простой отчет:
    качество на 4+; проблемы есть, но некритичные, можно релизиться.
    Чуть подробнее:
    три фичи на 4+, пять на 5, две выбросили из-за нехватки ресурсов; \
    были еще мелкие изменения, их тоже проверили;
    регрессия покрыта на 95%.
    Еще подробнее:
    таблица по каждой фиче: фича, оценка качества, список найденных багов, список проведенных проверок.
    Еще подробнее:
    таблица по каждой фиче: фича, оценка качества, список найденных багов, список проведенных проверок, когда планировалась, когда поступила в тестирование, когда тестировалась, какие были простои в тестировании, причины простоев, все, что подскажет фантазия.
    аналогично - по мелким изменениям.
    аналогичные данные по регрессии
    Еще подробнее:
    в общем-то, глубина погружения почти не ограничена )

    Я к тому, что, например, баг-трекер как хранилище истории тестирования полезен, но содержит слишком сырую информацию, к тому же не всю необходимую. Никому не важно, сколько и каких багов мы нашли, если в итоге фичей невозможно пользоваться. И если можно пользоваться - тоже никому неинтересно.
    Ну то есть, тестировщикам, разработчикам интересно. Руководителю интересно до какого-то момента.
    Но когда потребуется быстрый ответ: вот этот сценарий мы тестировали или нет? а когда, до билда ХХХ или после? - тогда багтрекер, мне кажется, бесполезен. Подобную информацию удобнее сохранять в Test Management системах вроде TestLink'а, но и там порой непросто понять, в контексте какой активности были пройдены те или иные тесткейсы.
    Но вообще говоря, все можно допиливать под свой вкус, и может кому-то будет вполне удобно использовать баг-трекер для подобных целей.

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

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

    Вот как-то так.


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

    ОтветитьУдалить
  6. начну с последнего вопроса. у нас во время циклов активной разработки - в начале каждой итерации разработчики могут достаточно сильно менять интерфейс. особенно для веб-приложения. и тут как раз возникает вопрос о том, как бы отследить вовремя изменения критичных для нас контролов, тобы тесты автоматические проходили без проблем (минимизировать количество проблем).

    в данный моменту нас сначала делаются правки кода, потом пинимается решение о выкатке нового билда, билд деплоиться на серваки - потом запускаются наши тесты, которые могут упасть из-за изменений.

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

    что же касается о вашем вопросе: а нельзя в багтрекере и и системе котнроля версий связать изменения?

    в имени багов - добавлять идентификатор тестовой серии, а систему контроля версий в лог при коммите писать набор идентификаторов. Имею ввиду следующее: указывать в логе с каким изменением требований связано или с правкой какого бага (прям идентификиатор бага). если добавление фичи - идентификатор добавления и т.п.

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

    если нет идентификатора причины коммита - слать ворнинг на команду - мол нет нужного идентификатора.

    достаточно сумбурно, извините, изложил.

    но может общая идея ясна?

    вы о таком не думали?

    ОтветитьУдалить
  7. > в начале каждой итерации разработчики могут достаточно сильно менять интерфейс

    Да, в такой ситуации тяжело. Причем ладно бы тестировшикам тяжело, а как клиенты реагируют на "достаточно сильные изменения интерфейса"?
    Все-таки привычка - великое дело; переучивать интерфейс после каждого апгрейда - тяжело, и неохота. Как это сказали на одном из докладов DevPoint2: наша задача - понять, как думает пользователь, и сделать так, чтоб он не думал.
    А изменения интерфейса заставляют пользователя спотыкаться на привычных шагах и думать не о задаче, которую он (пользователь) собственно хотел выполнить, а об интерфейсе приложения.

    Возвращаясь к тестированию - изменения действительно настолько серьезны, что уникальные идентификаторы контролов не спасают? По идее, даже если элементы поменяли расположение на странице, но их айдишники остались теми же, автотесты не должны бы это замечать. Хотя если что-то переезжает на другую страницу/удаляется/добавляется - тогда сложнее, конечно.

    А от чего отталкиваются разработчики, когда меняют интерфейс? Как-то же они принимают эти решения, нельзя ли в этом поучаствовать? Тогда, договорившись на берегу, все могут приступать к своей работе - разработчики править GUI, а вы - заранее готовить автотесты к этим правкам.

    Это, конечно, не так автоматизировано и технологично, зато можно заранее обсудить, как лучше располагать контролы - с точки зрения пользователя, бизнес-логики, нужд тестирования.

    ОтветитьУдалить
  8. > а нельзя в багтрекере и системе котнроля версий связать изменения?

    Можно, конечно.
    Собственно, примерно так и обстоят дела. Лог коммита содержит информацию о том, зачем он был нужен. Включая айдишники багов/фич.

    Если это подключить и использовать, то, действительно, получается, что мы знаем
    - баг/фичу, ради которых что-то меняли
    - список файлов, которые были изменены
    - собственно внесенные правки

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

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

    С другой стороны, те или иные приседания все равно потребуются, каким бы способом мы ни узнавали о факте изменений.

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


    Правда, получать лишнее сообщение о каждом исправленном баге - немного перебор. Баг-трекер и так мне сообщит.
    Но вот баг багу рознь.
    Где-то исправлена логическая ошибка, и теперь продукт просто работает так, как должен. Сообщать всем о таком изменении, в общем, незачем. Достаточно того, что кто-то один проверит баг.
    А где-то исправление, повлекло за собой изменение интерфейса (порядок шагов, наличие тех же контролов) или бизнес-сценария. Вот о такой правке стоит сообщить, чтоб люди не удивлялись, когда продукт поведет себя не так, как раньше.
    А если это вдруг коммит от соседней команды, содержащий результаты их работы за месяц, то тут долго можно размышлять, как данные изменения кода должны отразиться на поведении продукта, если ребята в логе коммита об этом не написали подробненько.

    И как автоматически отделить один случай от другого мне пока не очень понятно. Можно, конечно, придумать еще пару ключевых слов для лога коммита, по которым мы будем выцеплять нужные. Но вставлять эти ключевые слова все равно придется человеку.
    Как раз про это я и писал, что "Сообщать, по большому счету, можно любым способом". Можно - вставить в лог ключевое слово для парсилки, можно написать письмо на специальный мейллист, и т.д.


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

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

    Да, пожалуй, стоило для начала определить, что я считаю изменениями в контексте статьи, тут я что-то сплоховал. Ну, в следующий раз может быть буду умнее ).
    Зато какое обсуждение получается, вах!

    ОтветитьУдалить