1) Научитесь тщательно анализировать результаты теста. Не игнорируйте результаты теста. Окончательный результат теста может быть «пройден» или «не пройден», но устранение основной причины «сбой» даст вам решение проблемы. Тестеры будут пользоваться уважением, если они не только регистрируют ошибки, но и предоставляют решения.
2) Научитесь увеличивать тестовое покрытие при каждом тестировании любого приложения. 100% тестовое покрытие может оказаться невозможным, но тем не менее, вы всегда можете попытаться приблизиться к нему.
3) Чтобы обеспечить максимальное покрытие тестами, разбейте тестируемое приложение (AUT) на более мелкие функциональные модули. Напишите тестовые случаи на таких отдельных модульных модулях. Также, если возможно, разбейте эти модули на более мелкие части.
Например: предположим, что вы разделили свое веб-приложение на модули, и «принятие информации о пользователе» является одним из модулей. Вы можете разбить этот экран «Информация о пользователе» на более мелкие части для написания тестовых случаев: такие части, как тестирование пользовательского интерфейса, тестирование безопасности, функциональное тестирование формы «Информация о пользователе» и т. Д.
Примените все тесты типа и размера поля формы, отрицательные и проверочные тесты к полям ввода и напишите все такие тестовые примеры для максимального охвата.
4) При написании контрольных примеров сначала напишите контрольные примеры для предполагаемой функциональности, т.е. для действительных условий в соответствии с требованиями. Затем напишите контрольные примеры для недопустимых условий. Это будет охватывать как ожидаемое, так и неожиданное поведение тестируемого приложения.
5) Думай позитивно. Начните тестирование приложения с целью обнаружения ошибок / ошибок. Не думайте заранее, что в приложении не будет ошибок. Если вы тестируете приложение с целью обнаружения ошибок, вам определенно удастся найти и эти тонкие ошибки.
6) Запишите свои тестовые примеры в самой стадии анализа требований и разработки. Таким образом, вы можете убедиться, что все требования проверяемы.
7) Сделайте ваши тестовые примеры доступными для разработчиков до написания кода. Не держите свои тестовые случаи под рукой, ожидая окончательного выпуска приложения для тестирования, думая, что вы можете регистрировать больше ошибок. Позвольте разработчикам тщательно проанализировать ваши тестовые примеры для разработки качественного приложения. Это также сэкономит время на восстановление.
8) Если возможно, определите и сгруппируйте ваши тесты для регрессионного тестирования. Это обеспечит быстрое и эффективное ручное регрессионное тестирование.
9) Приложения, требующие критического времени отклика, должны быть тщательно протестированы на работоспособность. Тестирование производительности является важной частью многих приложений. При ручном тестировании это наиболее игнорируемая часть тестировщиками из-за отсутствия необходимого большого объема данных при тестировании производительности. Узнайте, как проверить приложение на производительность. Если невозможно создать тестовые данные вручную, напишите несколько основных сценариев для создания тестовых данных для теста производительности или попросите разработчиков написать один для вас.
10) Программисты не должны тестировать свой собственный код. Как обсуждалось в нашем предыдущем посте, базового модульного тестирования разработанного приложения должно быть достаточно для разработчиков, чтобы выпустить приложение для тестировщиков. Но вы (тестер) не должны заставлять разработчиков выпускать продукт для тестирования. Пусть они занимают свое время. Все от лидера до менеджера знают, когда модуль / обновление выпущено для тестирования, и они могут соответственно оценить время тестирования. Это типичная ситуация в гибкой среде проекта.
11) Пройдите тестирование требований. Протестируйте приложение на предмет того, что оно не должно делать.
12) При проведении регрессионного тестирования используйте предыдущий график ошибок (Bug graph - количество ошибок, найденных в зависимости от времени для разных модулей). Этот модульный график ошибок может быть полезен для прогнозирования наиболее вероятной части ошибки приложения.
13) Запишите новыйRMS, концепции, которые вы изучаете во время тестирования. Держите текстовый файл открытым во время тестирования любого приложения. Запишите результаты тестирования и наблюдения в нем. Используйте эти наблюдения в блокноте при подготовке окончательного отчета о выпуске теста. Эта полезная привычка поможет вам предоставить полный однозначный отчет об испытаниях и подробности выпуска.
14) Часто тестировщики или разработчики вносят изменения в базу кода для тестируемого приложения. Это необходимый шаг в среде разработки или тестирования, чтобы избежать выполнения оперативной обработки транзакций, как в банковских проектах. Запишите все такие изменения кода, сделанные для целей тестирования, и во время окончательного выпуска убедитесь, что вы удалили все эти изменения из окончательных ресурсов файла развертывания на стороне клиента.
15) Держите разработчиков подальше от тестовой среды. Это обязательный шаг для обнаружения любых изменений конфигурации, отсутствующих в документе о выпуске или развертывании. Иногда разработчики вносят некоторые изменения в конфигурацию системы или приложения, но забывают упомянуть об этом на этапах развертывания. Если разработчики не имеют доступа к среде тестирования, они не будут случайно вносить такие изменения в среду тестирования, и эти недостающие вещи могут быть зафиксированы в нужном месте.
16) Рекомендуется привлекать тестировщиков непосредственно с требований к программному обеспечению и самого этапа проектирования. Таким образом, тестеры могут получить информацию о надежности приложения, что приведет к подробному охвату тестированием. Если вас не просят принять участие в этом цикле разработки, вы можете обратиться к своему руководителю или менеджеру с просьбой привлечь вашу команду тестирования ко всем процессам принятия решений или встречам.
17) Группы тестирования должны делиться лучшими практиками тестирования, опытом с другими командами в своей организации.
18) Разговаривайте с разработчиками, чтобы узнать больше о продукте. Когда бы ни было возможно, сделайте личное общение для быстрого разрешения споров и избежания недоразумений. Но также, когда вы понимаете требование или решаете любой спор - обязательно сообщайте об этом через письменные способы связи, такие как электронная почта. Не держите ничего в устной форме.
19) Не хватает времени для выполнения приоритетных задач тестирования. Расставьте приоритеты в своей работе по тестированию от высокого до низкого приоритета и соответствующим образом планируйте свою работу. Проанализируйте все связанные риски, чтобы расставить приоритеты в вашей работе.
20) Напишите четкий, описательный, недвусмысленный отчет об ошибке. Не только предоставьте признаки ошибки, но также обеспечьте эффект ошибки и все возможные решения.
Не забывайте, что тестирование - это творческая и сложная задача. Наконец, все зависит от ваших навыков и опыта, от того, как вы справитесь с этой задачей.
Вам:
Обмен собственным опытом тестирования, советами или секретами тестирования в комментариях ниже, безусловно, сделает эту статью более интересной и полезной !!