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

TDF LibreOffice Document Liberation Project Блоги сообщества Weblate Nextcloud Redmine Ask LibreOffice Пожертвования

• Главная
• Разработка
• Дизайн
• QA
• События
• Документация
• Сайт
• Локализация
• Accessibility
• Маркетинг
• Diversity
• Wiki справка

• Сообщить об ошибке
• Сортировка ошибок
• Проекты
• Регрессионные тесты
• Автоматические тесты
• Bibisect
• QA Собрания
• ЧаВо

• EN
• AN
• AR
• AST
• BE
• BG
• BN
• BRX
• CA
• CS
• DA
• DE
• EL
• EO
• ES
• FA
• FI
• FR
• GD
• GL
• GUG
• HE
• HI
• HR
• HU
• ID
• IS
• IT
• JA
• JV
• KO
• KU
• LO-LA
• LT
• MN
• MR
• NE
• NL
• NO
• OC
• OM
• PA
• PL
• PT
• PT-BR
• RO
• RU
• SAH
• SK
• SL
• SQ
• SV
• TA
• TE
• ไทย (TH)
• TR
• UK
• UZ
• VI
• 正體 (ZH-TW)
• 简体 (ZH-CN)
• Article Title: QA/Testing/Feature Tests/ru

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

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

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

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

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

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

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

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