Многие люди считают, что тестирование программного обеспечения — это поиск ошибок.
Иногда я говорю тестировщикам: «не пытайтесь найти как можно больше ошибок, постарайтесь пропустить как можно меньше!», а они меня не понимают: какая разница? И разница огромная! В этой статье я хочу рассказать вам, что это такое и какие инструменты нужно использовать для действительно полезного тестирования.
Что такое охота за ошибками?
Я тестирую продукт. Моя задача — внести как можно больше ошибок.Это логично! Тестировщику всегда приятно находить ошибки; это видимый, измеримый результат работы, и чем их больше, тем больше меня ценят как тестировщика.
Какие области я бы протестировал в этом случае? Прежде всего, самый нестабильный.
Часто они нестабильны, поскольку имеют меньший приоритет, но это не имеет значения, гораздо важнее количество ошибок.
Что произойдет, если я столкнусь с трудно воспроизводимой ошибкой? Окупаемость его исследований рассчитывается в голове очень быстро.
Зачем мне с этим заморачиваться, если за это же время я могу иметь 3 менее критичных, но более простых в установке? Какие тесты я проведу в первую очередь? Конечно, самые нестандартные.
В поле входа введите «Война и мир», разделите на ноль, вставьте в свой профиль фотографию в формате .
exe. Открою вам секрет - иногда на собеседованиях тестировщики в ответ на просьбу "проверить калькулятор" перечисляют интересные и практичные тесты, но в числе первых тридцати Нет протестируйте «проверку сложения» и другие базовые операции.
Вот как выглядит поиск ошибок — к тестированию это не имеет никакого отношения.
Что такое тестирование?
Я тестирую продукт. Моя задача — пропустить как можно меньше ошибок, которые являются приоритетными для пользователя.Чем меньше допущено ошибок, чем меньше недовольства высказано клиентом, тем выше я оцениваю эффективность своей работы.
Какие области я буду тестировать в этом случае? Естественно, я начну с наивысшего приоритета для пользователя.
Даже если они будут работать стабильно и успешно, я всё равно проверю основные пользовательские сценарии, чтобы не пропустить серьёзные проблемы.
Что произойдет, если я столкнусь с трудностями? Например, с трудновоспроизводимым дефектом, или непониманием бизнес-процесса пользователя, или отсутствием требований? Если это важный функционал, то я узнаю «что не так» и «как сделать правильно».
В конце концов, внесение дефекта может занять много времени, и с точки зрения бага/времени результат тестирования будет не очень высоким, но у меня будут более глубокие знания о продукте, архитектуре и пользователях.
Какие тесты я проведу в первую очередь? Конечно, самые стандартные.
Выполнение самого простого сценария в самых простых условиях, чтобы гарантировать работу наиболее важных функций.
И только потом перейду к менее стандартным сценариям.
Результаты тестирования и поиска ошибок
В случае поиска ошибок в краткосрочной перспективе результаты выше: одновременно создается больше ошибок.Но в долгосрочной перспективе дела обстоят не так радужно:
- из-за отсутствия глубоких знаний о продукте процент пропущенных дефектов постепенно начинает увеличиваться
- Команда разработчиков занята исправлением ужасных, ужасных, невообразимых ошибок, полученных при нажатии одной и той же кнопки 144 раза под IE в полнолуние.
- релиз содержит жутко неприятные и очевидные для пользователя ошибки
- количество найденных ошибок падает в ДОЛГОСРОЧНОЙ СРОЧНОСТИ
Как перейти от поиска ошибок к тестированию?
Чтобы тестирование было эффективным и полезным в долгосрочной перспективе, нужно следовать простым правилам и использовать ключевые инструменты тестирования: 1. Анализ продукта и документирование испытаний.Нажимая на кнопки, можно создать массу багов — но нельзя сказать, что это проверено.
Единственное решение — документировать испытания.
Подробные тест-кейсы, которые расстраивают тестировщиков и отнимают много времени, нужны очень редко.
И здесь контрольные списки со списком «что проверить».
Что они дают:
- Вы анализируете продукт, записываете основные функции, действия и их параметры.
Это значительно снижает риск что-то забыть.
- Контрольные списки — отличное напоминание о необходимости «копать глубже».
Есть какая-то неясная особенность с недостаточным описанием.
Как это проверить? При тестировании без тестов проще всего сказать «Я вернусь к этому позже» и никогда не возвращаться.
А с тестами - у вас будет тест, в котором непонятно как и что проверять, вы увидите такие тесты и не забудете о необходимости это выяснить.
- Контрольные списки могут и ДОЛЖНЫ быть согласованы.
С разработчиками, аналитиками.
В процессе тестирования участвует вся команда, тестировщики узнают много нового о продукте, а коллективный разум повышает качество тестирования.
И помимо разового повышения качества отдельного чек-листа, улучшается качество тестирования в целом: тестировщики начинают больше учитывать при тестировании, развиваться, и эти знания со временем окупаются в виде большего количества знаний.
эффективное тестирование.
Цель — охватить весь продукт. Только пожалуйста, никаких оправданий по поводу ужасного потребления ресурсов — я набросал проекты с миллионами строк кода менее чем за полтора месяца.
И в процессе написания таких тестов возникали неожиданные вопросы и всплывали критические ошибки, которые, несмотря на наличие горе-тестеров, годами торчали в продукте.
2. Оценка теста Чтобы избежать слепоты котят, необходимо оценить эффективность тестирования.
Проанализируйте пропущенные ошибки и причины их пропуска.
Покрытие функционала и кода тестами.
Уровень удовлетворенности пользователей посредством анкетирования и сбора обратной связи.
Качество внесения ошибок путем опроса разработчиков.
ВСЕГДА есть что улучшать, и отсутствие процесса постоянного совершенствования — это неизбежная трясина.
3. Обсудите цели тестирования с командой Многие люди считают, что тестирование преследует какие-то мифические цели.
И что они всегда одинаковы.
Как бы там ни было! Каждый проект, компания, команда имеет свои цели.
Все ли понимают их одинаково? Вы произносили их вслух? Чтобы принести максимальную пользу, нужно четко понимать, в чем эта выгода.
И не удивляйтесь, если мнение ПМ и разработчиков не совпадет с вашим.
Мы должны не убеждать их, а адаптироваться к текущим целям проекта! 4. Понимание пользователей и их бизнес-процессов Для меня загадка, как такое возможно, но тем не менее это факт: зачастую тестировщики тестируют продукт, ничего не зная о пользователе.
- Как используется этот продукт?
- Зачем он вообще нужен, какие проблемы решает?
- Какова средняя квалификация пользователей?
- В каких условиях работают пользователи? На каких средах и оборудовании?
Часто аналитики не предоставляют им эту информацию.
Приходите в себя! Не зная пользователя, невозможно нормально протестировать продукт. 5. Техническая квалификация и понимание архитектуры.
Для иллюстрации вот ошибка, о которой мне недавно сообщили в системе отслеживания ошибок: Перейти на сайт тестируемого продукта http://****.
ru в браузере Фаерфокс Введите логин и пароль Авторизуйтесь с того же компьютера в браузере Opera Он просит вас повторно ввести имя пользователя и пароль, но автоматически не входит в систему.
Такие ошибки не только бесполезны, они позорят тестировщиков и дискредитируют индустрию в целом! Чтобы правильно создавать дефекты, нужно понимать платформу, на которой написан тестируемый продукт. Если мы говорим о веб-тестировании, то мы можем, по крайней мере, указать в отчете об ошибке код ошибки, возвращаемый сервером, посмотреть детали фаербага, предоставить подробную информацию и сэкономить много времени на разработке!
выводы
Многие разработчики не любят тестировщиков.И они делают это правильно! Но хороших тестировщиков любят и ценят все.
Но тестировщики, а не кликеры и багфиксеры! Научитесь выяснять, что не так, что не нравится другим членам команды разработчиков.
Обязательно изучите ошибки, которые вы пропустили, и сделайте все возможное, чтобы не пропустить их снова.
Не гонитесь за ошибками — вашей мантрой должно быть «счастье пользователя», «качественный продукт» и «успешный проект», а не «внедрить как можно больше ошибок» — ОЧЕНЬ часто эти 2 цели оказываются слишком далекими друг от друга.
.
И да пребудет с вами сила! Теги: #тестирование #поиск ошибок #потенциальные тестировщики #кот-тестеры #Тестирование ИТ-систем
-
Видеозапись И Магнитная Лента
19 Oct, 24 -
Web И Mvc: Разбор Полетов
19 Oct, 24 -
Uwp — Проблема № 227
19 Oct, 24
