Внимательно прочитайте каждый пункт и постарайтесь внедрить полученную информацию в свою повседневную деятельность по тестированию ПО. В будущем все лучшие практики тестирования вы освоите на собственном опыте. Но почему бы вам не изучить их заранее?
Лучшие практики тестирования программного обеспечения
1. Тщательно анализируйте результаты тестов. Итоговый результат прохождения теста может быть отмечен, как “пройден” или “провален”, но устранение основной причины “провала” всегда приводит к решению проблемы. Тестировщик быстрее заслужит уважение, если он будет не только находить ошибки, но и предлагать решения по их исправлению.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туторилов, задач по автоматизации и книг по QA.
2. Научитесь максимизировать тестовое покрытие каждый раз, когда вы тестируете любое приложение. 100% покрытие тестами часто бывает невозможным, но всегда можно попытаться приблизиться к этому показателю.
3. Для обеспечения полного тестового покрытия разбейте тестируемое приложение (AUT) на более мелкие функциональные модули и пишите тест-кейсы уже для них. Также, если возможно, разбейте эти модули на более мелкие части.
Предположим, что вы разделили сайт или приложение на модули, и один из них – это “прием информации о пользователе”. Вы можете разделить этот модуль на более мелкие части для написания следующих тест-кейсов: тестирование пользовательского интерфейса, безопасности, функциональное тестирование формы “Информация о пользователе” и т.д.
Примените все виды тестов заполнения полей ввода, как позитивные, так и негативные, и пропишите эти тест-кейсы для максимального покрытия.
4. При написании тест-кейсов необходимо сначала составить их для предполагаемой функциональности, т.е. для допустимых условий в соответствии с требованиями. Затем напишите тест-кейсы для недопустимых условий. Это позволит проверить как ожидаемое, так и неожиданное поведение тестируемого приложения.
5. Мыслите позитивно. Всегда приступайте к тестированию, поставив себе цель обязательно найти ошибки. Не стоит заранее думать о том, что в приложении не будет багов. В результате вы обязательно сможете найти даже самые трудноуловимые ошибки.
6. Создавайте тест-кейсы на этапе анализа требований и проектирования. Так вы убедитесь, что все требования адекватны и их можно проверить.
7. Сделайте свои тест-кейсы доступными для разработчиков до написания кода. Не храните их при себе, ожидая финального релиза приложения для тестирования, полагая, что так получится зафиксировать больше ошибок. Позвольте разработчикам тщательно проанализировать ваши сценарии, чтобы они могли разработать качественное приложение.
8. По возможности определите и сгруппируйте тест-кейсы для регрессионного тестирования для более быстрой и эффективной работы.
9. Приложения, требующие критического времени отклика, важно тщательно протестировать на производительность. Тестирование производительности – важная часть многих приложений, которая, к сожалению, часто игнорируется QA инженерами из-за отсутствия необходимого большого объема данных.
Найдите способы проверить ваше приложение на производительность. Если нет возможности создать тестовые данные вручную, напишите несколько базовых скриптов или попросите разработчиков написать их для вас.
10. Программисты не должны тестировать свой собственный код. Базового unit-тестирования обычно достаточно для того, чтобы разработчики выпустили приложение для тестировщиков. Но тестировщики не должны просить разработчиков выпускать отдельный продукт для тестирования.
Все, от ведущего тестировщика до проджект менеджера, знают, когда модуль/обновление будет выпущено, и могут оценить время тестирования соответствующим образом. Это типично для среды Agile-проекта.
11. Выходите за рамки тестирования требований. Проводите негативные тесты и проверяйте то, что приложение не должно делать.
12. При проведении регрессионного тестирования используйте предыдущий график ошибок (количество найденных багов в зависимости от времени для различных модулей). Он может быть полезен для прогнозирования наиболее вероятных ошибок в приложении.
13. Заведите текстовый файл для новых терминов и понятий, которые вы узнаете в процессе тестирования. Во время работы с приложением держите текстовый файл открытым. Записывайте в него ход тестирования и наблюдения, они всегда пригодятся при подготовке окончательного отчета.
14. Тестировщики или разработчики неоднократно вносят изменения в код тестируемого приложения. Это необходимый шаг в среде разработки или тестирования, который помогает избежать выполнения транзакций в реальном времени, как, например, в банковских проектах.
Записывайте все такие изменения кода, сделанные в целях тестирования, и во время окончательного релиза убедитесь, что вы удалили все эти изменения из файловых ресурсов финального развертывания на стороне клиента.
15. Держите разработчиков подальше от тестовой среды. Иногда разработчики вносят некоторые изменения в конфигурацию системы или приложения, но забывают упомянуть об этом на этапе развертывания. Если у разработчиков нет доступа к тестовой среде, они не смогут случайно внести в нее такие изменения.
16. Хорошей практикой является привлечение тестировщиков уже на этапе разработки требований и проектирования программного обеспечения.
Таким образом, тестировщики могут получить знания о надежности приложения, что приведет к максимальному тестовому покрытию. Если вас не просят принять участие в этом цикле разработки, вы можете обратиться к своему руководителю или менеджеру с просьбой привлечь команду тестирования ко всем процессам принятия решений.
17. Команды тестировщиков должны делиться лучшими практиками и опытом тестирования с другими командами в своей организации.
18. Налаживайте контакты с разработчиками, чтобы узнать больше о продукте. По возможности общайтесь лицом к лицу, чтобы быстро разрешить спорные вопросы и избежать недоразумений.
Даже после того, как вы поймете требования или разрешите какой-либо спор – обязательно продолжайте общение теми же неписаными способами коммуникации, например, по электронной почте.
19. Не тратьте время на выполнение высокоприоритетных задач тестирования. Расставляйте приоритеты задач от высоких до низких и планируйте свою работу соответствующим образом. Анализируйте все сопутствующие риски, чтобы правильно определить приоритетность своей работы.
20. Пишите четкий, описательный и недвусмысленный баг-репорт. Укажите не только описание ошибки и прочие обязательные атрибуты отчета, но и укажите ее последствия и возможные решения проблемы.
Помните, что тестирование – это творческая и сложная задача. То, как вы с ней справитесь, зависит от вашего опыта и полученных навыков.
Перевод статьи «Top 20 Practical Software Testing Tips You Should Read Before Testing Any Application».
В пункте 19 наверное “низкоприоритетных”, а не “высокоприоритетных”