Основные принципы в тестировании ПО
Порой, тестируя большое количество новых фитч тестировщики забывают даже о самых важных принципах в тестировании и тем самым делая много стратегических и поведенческих ошибок в тестировании ПО.
В этой статье напомню общеизвестные и основные принципы о которых не следует забывать, когда тестируете какое либо приложение или новую фитчу
Из множества принципов, которые наверно для себя выделил каждый тестировщик занимающийся тестированием ПО есть основные по мнению сообщества тестировщиков, которые и хотелось бы выделить:
1) Исчерпывающее тестирование невозможно ни одним из тестировщиков. Думаю что все понимают что протестировать все возможные случаи и комбинации просто невозможно, конечно если это не тривиальный случай.
Все случаи просто не могут быть включены в тест сьют, так как это заняло бы у нас очень много времени и в конце концов не стоило бы нам таких усилий. Если каждый тестировщик сядет и тщательно продумает все сценарии и если отдать эту фитчу для тестирования другому тестировщику, то он как правило находит еще кучу возможных сценариев и кейсов, которые можно включить. Поэтому в тестировании ПО принято проанализировать продукт или новую фитчу после чего сфокусировать усилия в тестировании на более рисковые и приоритетные случаи и участки нашего продукта.
2) Скопление багов. Если брать продукт и разбить его по модулям, то в процессе тестирования можно заметить что основная часть багов лежит в одном или нескольких модулях продукта, следовательно можно отметить эффект скопления багов. Как правило такое можно наблюдать в совершенно разных продуктах. Для того чтобы эффективно протестировать наш продукт, следует распределить свои усилия в тестировании по реальной плотности багов в модулях продукта, если же тестируем впервые, то пропорционально ожидаемой плотности. Со временем тенденция с накоплением багов может изменятся от модуля к модулю. Это следует отслеживать и перераспределять усилия в дальнейшем тестировании.
3) Эффективность раннего тестирования. Очень важно чтобы тестирование начиналось как можно раньше и предугадывались возможные ошибки которые может совершить разработчик.
Перед тем как разрабатывать и тестировать тот или иной продукт, следует выяснить всю специфику, возможные конфликты в спецификации, невозможность новой фитчи взаимодействовать с другим модулем, убедиться что тестировщик, разработчик и продакт овнер одинаково правильно понимают как это будет реализовано. Запомните чем раньше найдутся баги тем дешевле их исправить.
4) Парадокс пестицида. Если написав тест кейсы, прогонять их много много раз, то в конечном счете эти кейсы не помогут нам найти новые баги. Поэтому существует практика в тестировании когда пересматривают и модернизируют тест кейсы чтобы словить какие-то новые баги. Тест кейсы могут усложняться, быть разносторонними так чтобы охватить все компоненты, модули нашего продукта, что в свою очередь поможет нам найти больше интересных и новых багов.
5) Тестирование зависит от нашего продукта. Существует много программ, продуктов и к каждой из них следует подходить индивидуально в плане тестирования. В каких-то больше усилий в тестировании нужно на безопасность, в каких-то на юзабилити. Поэтому не стоит грести все продукты под одну гребенку и тестировать по какому-то одному шаблону.
6) Тестирование показывает наличие багов в продукте но ни как не их отсутствие. Многие думают что если новый функционал прошел стадию тестирования, значит все — багов уже нет. В этом и заключается ошибочное суждение. Тестирование лишь снижает вероятность наличия багов в продукте. Следовательно, в процессе тестирования много багов может быть пропущено и это не будет означать что если продукт прошел тестирование, то сейчас этот продукт на 100% работает корректно.
7) Продукт хорошо протестирован и вроде бы нет очевидных багов, то это хороший продукт. Иногда тестрируя и выискивая функциональные баги, мы забываем посмотреть с другой стороны и спросить а нужно ли это пользователю. Если эта фитча не соответствует ожиданиям пользователя и его потребностям, то какой бы качественный наш продукт не был — это уже не так важно.
В этой статье напомню общеизвестные и основные принципы о которых не следует забывать, когда тестируете какое либо приложение или новую фитчу
Основные принципы в тестировании ПО
Из множества принципов, которые наверно для себя выделил каждый тестировщик занимающийся тестированием ПО есть основные по мнению сообщества тестировщиков, которые и хотелось бы выделить:
1) Исчерпывающее тестирование невозможно ни одним из тестировщиков. Думаю что все понимают что протестировать все возможные случаи и комбинации просто невозможно, конечно если это не тривиальный случай.
Все случаи просто не могут быть включены в тест сьют, так как это заняло бы у нас очень много времени и в конце концов не стоило бы нам таких усилий. Если каждый тестировщик сядет и тщательно продумает все сценарии и если отдать эту фитчу для тестирования другому тестировщику, то он как правило находит еще кучу возможных сценариев и кейсов, которые можно включить. Поэтому в тестировании ПО принято проанализировать продукт или новую фитчу после чего сфокусировать усилия в тестировании на более рисковые и приоритетные случаи и участки нашего продукта.
2) Скопление багов. Если брать продукт и разбить его по модулям, то в процессе тестирования можно заметить что основная часть багов лежит в одном или нескольких модулях продукта, следовательно можно отметить эффект скопления багов. Как правило такое можно наблюдать в совершенно разных продуктах. Для того чтобы эффективно протестировать наш продукт, следует распределить свои усилия в тестировании по реальной плотности багов в модулях продукта, если же тестируем впервые, то пропорционально ожидаемой плотности. Со временем тенденция с накоплением багов может изменятся от модуля к модулю. Это следует отслеживать и перераспределять усилия в дальнейшем тестировании.
3) Эффективность раннего тестирования. Очень важно чтобы тестирование начиналось как можно раньше и предугадывались возможные ошибки которые может совершить разработчик.
Перед тем как разрабатывать и тестировать тот или иной продукт, следует выяснить всю специфику, возможные конфликты в спецификации, невозможность новой фитчи взаимодействовать с другим модулем, убедиться что тестировщик, разработчик и продакт овнер одинаково правильно понимают как это будет реализовано. Запомните чем раньше найдутся баги тем дешевле их исправить.
4) Парадокс пестицида. Если написав тест кейсы, прогонять их много много раз, то в конечном счете эти кейсы не помогут нам найти новые баги. Поэтому существует практика в тестировании когда пересматривают и модернизируют тест кейсы чтобы словить какие-то новые баги. Тест кейсы могут усложняться, быть разносторонними так чтобы охватить все компоненты, модули нашего продукта, что в свою очередь поможет нам найти больше интересных и новых багов.
5) Тестирование зависит от нашего продукта. Существует много программ, продуктов и к каждой из них следует подходить индивидуально в плане тестирования. В каких-то больше усилий в тестировании нужно на безопасность, в каких-то на юзабилити. Поэтому не стоит грести все продукты под одну гребенку и тестировать по какому-то одному шаблону.
6) Тестирование показывает наличие багов в продукте но ни как не их отсутствие. Многие думают что если новый функционал прошел стадию тестирования, значит все — багов уже нет. В этом и заключается ошибочное суждение. Тестирование лишь снижает вероятность наличия багов в продукте. Следовательно, в процессе тестирования много багов может быть пропущено и это не будет означать что если продукт прошел тестирование, то сейчас этот продукт на 100% работает корректно.
7) Продукт хорошо протестирован и вроде бы нет очевидных багов, то это хороший продукт. Иногда тестрируя и выискивая функциональные баги, мы забываем посмотреть с другой стороны и спросить а нужно ли это пользователю. Если эта фитча не соответствует ожиданиям пользователя и его потребностям, то какой бы качественный наш продукт не был — это уже не так важно.
2 комментария