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