Ниже приведены некоторые из самых распространенных мифов о тестировании программного обеспечения.
Миф 1: Тестирование слишком дорого
Реальность. Существует поговорка: плати меньше за тестирование во время разработки программного обеспечения или плати больше за обслуживание или исправление позже. Раннее тестирование во многих аспектах экономит как время, так и затраты, однако снижение стоимости без тестирования может привести к неправильной разработке программного приложения, что сделает продукт бесполезным.
Миф 2: Тестирование отнимает много времени
Реальность. На этапах SDLC тестирование никогда не занимает много времени. Однако диагностика и исправление ошибок, выявленных во время правильного тестирования, является трудоемкой, но продуктивной деятельностью.
Миф 3: тестируются только полностью разработанные продукты
Реальность — Без сомнения, тестирование зависит от исходного кода, но рассмотрение требований и разработка контрольных примеров не зависит от разработанного кода. Однако итеративный или инкрементальный подход в качестве модели жизненного цикла разработки может снизить зависимость тестирования от полностью разработанного программного обеспечения.
Миф 4: полное тестирование возможно
Реальность — становится проблемой, когда клиент или тестер считает, что полное тестирование возможно. Возможно, что все пути были проверены командой, но полное тестирование никогда не возможно. Могут существовать некоторые сценарии, которые никогда не выполняются группой тестирования или клиентом в течение жизненного цикла разработки программного обеспечения и могут выполняться после развертывания проекта.
Миф 5: протестированное программное обеспечение не содержит ошибок
Реальность — это очень распространенный миф, в который верят клиенты, менеджеры проектов и команда менеджеров. Никто не может с полной уверенностью утверждать, что программное приложение не содержит ошибок на 100%, даже если тестировщик с превосходными навыками тестирования протестировал тестирование. приложение.
Миф 6: пропущенные дефекты из-за тестеров
Реальность. Это неправильный подход к обвинению тестировщиков в ошибках, которые остаются в приложении даже после проведения тестирования. Этот миф относится к ограничениям времени, стоимости и требований. Однако стратегия тестирования может также привести к тому, что команда тестирования пропустит ошибки.
Миф 7: тестеры несут ответственность за качество продукции
Реальность. Это очень распространенное неправильное толкование того, что только тестировщики или группа тестирования должны отвечать за качество продукта. В обязанности тестировщиков входит выявление ошибок для заинтересованных сторон, а затем они сами решают, исправят ли они ошибку или выпустят программное обеспечение. Выпуск программного обеспечения в то же время оказывает большее давление на тестеров, так как они будут обвинены в любой ошибке.
Миф 8: Автоматизация испытаний должна использоваться везде, где это возможно, чтобы сократить время
Реальность — да, это правда, что автоматизация тестирования сокращает время тестирования, но невозможно запустить автоматизацию тестирования в любой момент во время разработки программного обеспечения. Тестовый автомат должен быть запущен, когда программное обеспечение было проверено вручную и в какой-то степени стабильно. Более того, автоматизация тестирования никогда не может быть использована, если требования постоянно меняются.
Миф 9. Любой может протестировать приложение
Реальность — люди за пределами IT-индустрии думают и даже верят, что любой может протестировать программное обеспечение, и тестирование — это не творческая работа. Однако тестеры очень хорошо знают, что это миф. Думая об альтернативных сценариях, попытка сбить программное обеспечение с целью изучения потенциальных ошибок не представляется возможным для человека, который его разработал.
Миф 10. Единственная задача тестера — найти ошибки
Реальность. Поиск багов в программном обеспечении — задача тестировщиков, но в то же время они являются экспертами в области конкретного программного обеспечения. Разработчики несут ответственность только за конкретный компонент или область, назначенную им, но тестировщики понимают общую работу программного обеспечения, каковы зависимости и влияние одного модуля на другой модуль.