Эту статью я написала в рабочем конфлюенсе в 2013 году. И на момент написания этой статьи (2019 год) она все еще была актуальна.
Исходно чек-лист записала как напоминание, в том числе и себе. Потому что к задачам приходится возвращаться, в том числе людям, которые их НЕ проверяли. Например, во время регрессии надо хотя бы базово проверить функционал.
И вот ты открываешь задачу, листаешь до последнего комментария посмотреть, какая документация, что как работает, а там… Пусто. Или скромное «Все проверено, все ок». А документация где? Я же не в теме задачи, я хочу прочитать побольше!
Или если заказчик пишет, что у него что-то не работает, а ты хочешь проверить, покрыта ли ситуация автотестами. Идешь в задачу, а там нет ссылки на автотесты. Их вообще не писали? Или просто ссылку не дали? Приходится выяснять…
Так и появился чек-лист закрытия задачи:
Он вроде как «про нас», но на самом деле универсальный. Ну разве что в вашей компании тестировщик не пишет документацию, тогда второй пункт меняем на «проверить, что вся нужная документация написана или актуализирована».
Разберем каждый пункт отдельно.
Если документации никакой по задаче нет (неважно, баг это или improvement), она переоткрывается.
Если документация есть, но в JIRA нет на нее ссылки в последнем комментарии — задача переоткрывается. (суровые времена, суровые меры)
Минимально надо написать / исправить пользовательские требования.
Если же были изменения в конфигах проекта, надо проверить, что есть техническая документация по такому изменению. Если ее нет, пишем.
Если добавлялась задачи миграции — сразу написать общую инструкцию по обновлению релиза.
Если придется возвращаться к задаче позднее, иногда бывает полезно узнать, на какой версии тестировал тестировщик и что он проверял (вкратце).
Записываем версии из mercurial, даем ссылку на документацию и краткое описание: Проверил вручную через интерфейс / SOAP / буфер.
Если задача проверялась вручную, обязательно прикладываем к ней тестовые данные (если они не весят 3Тб)
Да, эти данные можно получить из общего хранилища, но там они могут быть уже изменены или даже удалены. (У нас есть общее хранилище тестовых данных, но все файлики хранятся на диске. В системе контроля версий пробовали, не понравилось, туда вообще никто не коммитит, а на диск хоть как-то складывают)
Иногда кажется, что это все фигня, одного контрагента создали или выборки по view собрали.
Но если через полгода у Заказчика всплывет проблема и будут подниматься старые задачи для воспроизведения, эти файлики очень помогут, проверено и не раз. А вот актуальные данные из хранилища уже устареют.
Помните — взять готовый sql-запрос и проверить по базе займет 1 минуту. А снова сидеть и составлять этот запрос — это может и час занять, если не больше. Экономьте свое время!
Поэтому:
См также:
Как в Maven быстро создать БД по шаблону? — о том, как мы делаем dbStart для тестирования.
Коммент с тестами, докой и данными должен быть заключительным. А не так, что «я написал такие-то тесты, нашел такие-то проблемы» и потом переписка с разработчиком на 20 комментов, а твой «заключительный» затерялся где-то в середине. Если затерялся — продублируй (старый можно удалить).
Когда мы набрали новых тестировщиков, этой статьи стало мало. Потому что задачи джуниоров я переоткрывала и рассказывала, как надо исправить завершающий комментарий, чтобы он был понятным. А они, в свою очередь, просили примеры «как правильно».
Так в статье появился еще один блок — «Примеры». Тут важно дать ссылки на реальные задачи в рабочей jira + какие-то доп статьи в конфлюенсе. Примеры должны быть разные: как на огромные комментарии, когда по задаче написано 200 автотестов, так и на небольшие задачи, с которыми ребята будут сталкиваться каждый день.
Я ссылки давать не буду, но смысл, надеюсь, понятен. Выглядит раздел примерно так:
Примеры больших задач, где много доки и тестов:
Примеры небольших задач: TEST-816 — расширили модель согласий.
При тестировании «добавить функционал в Демо» обращайте особое внимание на рефакторинг — выносите документацию к core, тесты все в Демо, а остальное через инклюд итд. Пример: TEST-4519 — Добавить кросс-сверку ФЛ-ИП в Демо.
Примеры полезных комментов «как я это тестил», к которым возвращаешься повторно (их лучше в HOWTO выносить, но и в задаче надо оставить): TEST-812 — Сделать перестроение индекса неблокируемым (куда ставить бряку*, чтобы проверить)
* Бряка: Breakpoint (жаргонное) — точка остановки кода. Это когда вы запускаете исходный код в режиме отладки, такие точки помогают отследить параметры, локализовать ошибку.
P.S. — другие статьи по тестированию см в моем блоге
Исходно чек-лист записала как напоминание, в том числе и себе. Потому что к задачам приходится возвращаться, в том числе людям, которые их НЕ проверяли. Например, во время регрессии надо хотя бы базово проверить функционал.
И вот ты открываешь задачу, листаешь до последнего комментария посмотреть, какая документация, что как работает, а там… Пусто. Или скромное «Все проверено, все ок». А документация где? Я же не в теме задачи, я хочу прочитать побольше!
Или если заказчик пишет, что у него что-то не работает, а ты хочешь проверить, покрыта ли ситуация автотестами. Идешь в задачу, а там нет ссылки на автотесты. Их вообще не писали? Или просто ссылку не дали? Приходится выяснять…
Так и появился чек-лист закрытия задачи:
- Проверить задачу (здравствуй, кэп). Используйте готовые чек-листы для типовых задач + избегайте типовых ошибок в автотестах.
- Написать по ней документацию (min — пользовательскую, max — пользовательскую и «для коллег»).
- В JIRA оставить комментарий «проверил на сборке core ***, customer ***, посмотрел то, то и то, дока вот она».
- Приложить к задаче тестовые данные, если что-то проверялось вручную.
Он вроде как «про нас», но на самом деле универсальный. Ну разве что в вашей компании тестировщик не пишет документацию, тогда второй пункт меняем на «проверить, что вся нужная документация написана или актуализирована».
Разберем каждый пункт отдельно.
Документация
Если документации никакой по задаче нет (неважно, баг это или improvement), она переоткрывается.
Если документация есть, но в JIRA нет на нее ссылки в последнем комментарии — задача переоткрывается. (суровые времена, суровые меры)
Минимально надо написать / исправить пользовательские требования.
Если же были изменения в конфигах проекта, надо проверить, что есть техническая документация по такому изменению. Если ее нет, пишем.
Если добавлялась задачи миграции — сразу написать общую инструкцию по обновлению релиза.
Комментарий
Если придется возвращаться к задаче позднее, иногда бывает полезно узнать, на какой версии тестировал тестировщик и что он проверял (вкратце).
Записываем версии из mercurial, даем ссылку на документацию и краткое описание: Проверил вручную через интерфейс / SOAP / буфер.
Тестовые данные
Если задача проверялась вручную, обязательно прикладываем к ней тестовые данные (если они не весят 3Тб)
Да, эти данные можно получить из общего хранилища, но там они могут быть уже изменены или даже удалены. (У нас есть общее хранилище тестовых данных, но все файлики хранятся на диске. В системе контроля версий пробовали, не понравилось, туда вообще никто не коммитит, а на диск хоть как-то складывают)
Иногда кажется, что это все фигня, одного контрагента создали или выборки по view собрали.
Но если через полгода у Заказчика всплывет проблема и будут подниматься старые задачи для воспроизведения, эти файлики очень помогут, проверено и не раз. А вот актуальные данные из хранилища уже устареют.
Помните — взять готовый sql-запрос и проверить по базе займет 1 минуту. А снова сидеть и составлять этот запрос — это может и час занять, если не больше. Экономьте свое время!
Поэтому:
- Создали БД из dbStart — аттачим dbStart (экселька, в которой сохранен срез базы для тестирования).
- Загружали тестовые данные из хранилища — аттачим загруженный файл.
- Загружали их откуда-то еще — добавляем в хранилище и аттачим к задаче.
См также:
Как в Maven быстро создать БД по шаблону? — о том, как мы делаем dbStart для тестирования.
Коммент с тестами, докой и данными должен быть заключительным. А не так, что «я написал такие-то тесты, нашел такие-то проблемы» и потом переписка с разработчиком на 20 комментов, а твой «заключительный» затерялся где-то в середине. Если затерялся — продублируй (старый можно удалить).
Примеры
Когда мы набрали новых тестировщиков, этой статьи стало мало. Потому что задачи джуниоров я переоткрывала и рассказывала, как надо исправить завершающий комментарий, чтобы он был понятным. А они, в свою очередь, просили примеры «как правильно».
Так в статье появился еще один блок — «Примеры». Тут важно дать ссылки на реальные задачи в рабочей jira + какие-то доп статьи в конфлюенсе. Примеры должны быть разные: как на огромные комментарии, когда по задаче написано 200 автотестов, так и на небольшие задачи, с которыми ребята будут сталкиваться каждый день.
Я ссылки давать не буду, но смысл, надеюсь, понятен. Выглядит раздел примерно так:
Примеры больших задач, где много доки и тестов:
- TEST-679 — Доработки JMS
- TEST-760 — Обратный поток в разные JMS-источники
Примеры небольших задач: TEST-816 — расширили модель согласий.
При тестировании «добавить функционал в Демо» обращайте особое внимание на рефакторинг — выносите документацию к core, тесты все в Демо, а остальное через инклюд итд. Пример: TEST-4519 — Добавить кросс-сверку ФЛ-ИП в Демо.
Примеры полезных комментов «как я это тестил», к которым возвращаешься повторно (их лучше в HOWTO выносить, но и в задаче надо оставить): TEST-812 — Сделать перестроение индекса неблокируемым (куда ставить бряку*, чтобы проверить)
* Бряка: Breakpoint (жаргонное) — точка остановки кода. Это когда вы запускаете исходный код в режиме отладки, такие точки помогают отследить параметры, локализовать ошибку.
P.S. — другие статьи по тестированию см в моем блоге
