Тестирование ключевых изменений

From The Document Foundation Wiki
Jump to: navigation, search

Зачем нужен тест ключевых изменений?

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

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

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

Как провести тестирование ключевых изменений?

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

  1. Найдите новое ключевое изменение:
    • ищите его на странице примечаний к выпуску для предстоящего выпуска;
    • просмотрите список рассылки команды QA; разработчики просят помощи в то время когда работают над кодом, потому что в тот момент когда код перед глазами, ошибку проще устранить.
  2. Поймите в чем заключается это изменение:
    • прочтите описание в примечаниях к выпуску или сообщение от разработчика;
    • если вы не уверены, обратитесь к автору (в примечаниях к выпуску автор указан в скобках); если вы не можете найти его, спросите в списке рассылки для разработчиков.
  3. (по выбору) Попросите разработчика указать возможные побочные эффекты и проблемы. Он может иметь интересные идеи относительно того, что должно быть проверено.
  4. Скачайте и установите сборку, в которой присутствует это ключевое изменение:
    • изменения упомянутые в примечаниях к выпуску доступны в ежедневных сборках;
    • изменения упомянутые в списке рассылки могут находиться только в ветке кода; в этом случае, возможно придётся попросить разработчика включить их, и потребуется дополнительная сборка.
    • на этапе бета/релиз кандидата все ключевые изменения доступны в официальных сборках
  5. Играйтесь с новым функционалом.
  6. Попробуйте различные предполагаемые (и не предполагаемые) сценарии.
  7. Посмотрите, работает ли это ключевое изменение, так как требуется.
  8. Будьте осторожны с побочными эффектами в смежных частях.
  9. Сообщите о найденных проблемах.

Примечание: Нет необходимости повторять полный тест на регрессию. Он будет пройден в любом случае.