(от Цикл историй тестировщиков ) Всем привет. Как вы уже могли заметить, интенсивность запусков курсов в OTUS увеличивается с каждым месяцем, и в марте их особенно много.
Мы хотим, чтобы сегодняшний материал совпал с запуском курса.
«Автоматизация веб-тестирования» , который стартует в середине марта.
Приятного чтения.
Я до сих пор вижу, как многие тестировщики говорят о количестве найденных ошибок и уязвимостей как о показателе успеха тестирования.
Недавно я увидел другую точку зрения, которая говорила, что суть на самом деле в качестве ошибок, а не в их количестве.
Однако с этой мерой также следует быть осторожными.
Сейчас мы поговорим об этом.
Основная идея заключается в том, что способ тестирования определяется типом ошибок, которые вам нужно найти.
О некоторых аспектах сегодняшней темы я уже говорил ранее в разговор об охоте за ошибками .
Не хочу повторяться, поэтому постараюсь быть кратким.
Сформулирую свои мысли кратко и применительно к коллективу, в котором работаю.
В тестировании для меня важно влиять на пользователей, чтобы они быстрее принимали правильные решения.
Это требует использования жесткого цикла обратной связи, чтобы сократить время между разработчиками, совершающими ошибку, и последующим ее исправлением.
Эти ошибки представляют собой области, в которых различные качества (поведение, производительность, безопасность, удобство использования и т. д.) либо отсутствуют, либо ухудшаются.
Это определенно не измеряется количеством найденных ошибок, но играет роль характер ошибки.
Моя задача — найти ошибки, которые больше всего угрожают целостности и качеству разработки.
Вероятно, это можно объяснить «качеством» ошибок, то есть эти ошибки тем важнее, чем больше они угрожают целостности.
На мой взгляд, ключом к эффективному исправлению ошибок является их обнаружение как можно быстрее, в идеале сразу после их появления.
Хотя, с моей точки зрения, даже «качество ошибки» — это далеко не высшая мера.
Мы придаем столько значения качеству ошибок, но неужели их количество — незначительная характеристика? На самом деле, количество ошибок имеет значение, если вы очень сосредоточены на сокращении времени, затрачиваемого на их поиск.
Допустим, в системе 10 критических ошибок.
И я действительно быстро нашел двоих из них, и это действительно круто! Перед выпуском продукта были обнаружены две критические ошибки.
Но других перед развертыванием я не нашел.
Это означает, что 8 критических ошибок остались незамеченными.
В этом случае количество ошибок является ключевым показателем, даже если в то время мы этого не понимали.
Важно думать немного по-другому.
Количество ошибок или их качество не так важно, как механизмы их возникновения и, соответственно, механизмы их обнаружения.
Существует множество существующих вариантов:
Механизмы, которые хорошо находят ошибки, но работают слишком долго; Механизмы, которые плохо находят ошибки, но работают очень быстро; Механизмы, которые «склонны» замечать ошибки одного вида, но при этом не видят других; Механизмы, которые не очень популярны среди тестировщиков, но реально работают и не используются, потому что никто в команде о них не знает, из-за чего то, что можно найти, остаётся ненайденным; Механизмы, которые могут работать хорошо и быстро и находить множество ошибок, но обратная связь от них настолько неясна, что люди не могут принимать решения на основе их результатов.Сосредоточение внимания на этих аспектах так же, как и на других известных, важно, поскольку это помогает обойти некоторые традиционные проблемы.
Например, например, когда вы уже прогнали сотню тестов, но не нашли ни одной ошибки.
И это может быть хорошо, но только если ошибок действительно нет. Но если они существуют, то это плохо, если используемые методы тестирования не могут их обнаружить.
Или ситуация, когда я запускаю кучу тестов и нахожу мелкие ошибки, пропуская при этом более сложные.
Моя команда и я должны принять определенные решения на основе проведенных тестов.
Это значит, что мы должны верить тому, что говорят нам результаты тестов, и соответственно, мы должны изначально доверять тем методам обнаружения, которые мы реализовали в этих тестах.
Некоторые методы обнаружения исходят из самих тестов, грубо говоря, что они ищут и как они выглядят. Другие методы обнаружения должны быть присущи самой среде и тестируемости, которые мы определяем, чтобы определить, насколько вероятно и в принципе возможно, что тесты вызовут ошибку, если она существует. В завершение своих кратких размышлений хочу сделать вывод, что я не определяю успех тестирования какими-то конкретными факторами.
Но если вы все-таки хотите для себя это как-то определить, то вам следует определять это не по количеству найденных ошибок и уязвимостей и не по качеству этих ошибок, а по конкретной способности механизмов тестирования их обнаруживать.
Я обнаружил, что неопытные тестировщики, читающие эту заметку, не увидят существенной разницы между идеей изоляции способностей и результатами, полученными после изоляции этих способностей.
Что касается специалистов, то они должны чрезвычайно хорошо их дифференцировать.
Будучи способными понять и сформулировать это различие, тестировщики могут выйти за рамки бесполезного (только по мнению автора) различия между «проверкой» и «тестированием» и вместо этого развить конструктивное понимание методов обнаружения, как человеческих, так и автоматизированных, которые позволяют тестированию помочь людям быстрее принимать правильные решения.
Вот такой, казалось бы, простой, но весьма полезный материал.
По сложившейся традиции ждем ваших комментариев и приглашаем вас на открытый вебинар , который пройдёт 11 марта Михаил Самойлов — Ведущий специалист по автоматизации тестирования в Group-IB. Теги: #qa #тестирование веб-сервисов #тестирование веб-приложений #автоматизация тестирования
-
Видео@Mail.ru Начало Работать С Hd
19 Oct, 24 -
Что Случилось С Гуглом?
19 Oct, 24 -
О Чем Бы Вы Хотели Прочитать?
19 Oct, 24 -
Фликр
19 Oct, 24
