Баг-хантинг – распространенная практика в мировых тест-организациях. Однако некоторые тест-менеджеры думают, что баг-хантинг – это поиск багов на границах через неформальные эксперименты с приложением.
Что такое баг-хантинг (и чем он не является)?
Баг-хантинг – это неформальные упражнения по тестированию. Не надо путать их с ситуацией, когда вы развлекаетесь с приложением без цели и смысла, а также не смешивайте их с исследовательским тестированием. Вот почему:
Баг-хантинг – это групповая деятельность, а исследовательское тестирование может проводиться единолично.
Цель баг-хантинга – подключить к процессу тех, кто не является тестировщиком, и найти неочевидные баги. Исследовательское тестирование нацелено на "обычные" баги, и им обычно занимаются исключительно тестировщики.
Исследовательским тестированием можно заниматься на любой стадии процесса разработки. Баг-хантинг приносит пользу, если приложение достаточно стабильно.
"С тестированием все путем". Значит ли это, что продукт в хорошей форме, или что мы добились хорошего покрытия, или нашли много багов? "С тестированием все очень плохо". Продукт хорош? Тестирование заблокировано? Мы ошибочно ставим много багов?
Люди отвечали на него, предлагая собственные интерпретации. Это неудивительно. Их интерпретации различались между собой, что тоже неудивительно. Меня больше удивило количество людей, убежденных, что есть некий общеизвестный базис, на основании которого мы можем оценить наше тестирование как хорошее или плохое – а также неявно предполагающих, что люди автоматически поймут, о чем мы.
В рамках сдвоенного доклада мы проговорим проблему построения Архитектуры решений Автоматизации «от обратного» - систематизируем классические Архитектурные недочеты, в том числе процессного происхождения, сформулируем варианты решения каждой рассмотренной проблемы, критерии выбора решения, и конечно условия перехода проблемы из не идеальной, но промышленно приемлемой, в потенциально опасный для проекта прецедент.
В докладе автор рассматривает как используется QA в различных аспектах жизни. Рассказывает о его основных целях и задачах. Приводит примеры хороших и плохих подходов. Говорит о рисках.
Есть несколько статей об антипаттернах разработки ПО. Но большинство из них говорят о деталях на уровне кода и фокусируются на конкретной технологии или языке программирования.
В этой статье я хочу сделать шаг назад и перечислить высокоуровневые антипаттерны тестирования, общие для всех. Надеюсь, вы узнаете некоторые из них независимо от языка программирования.
Терминология
К сожалению, в тестировании пока не выработали общую терминологию. Если спросить сотню разработчиков, в чём разница между интеграционным, сквозным и компонентным тестом, то получите сто разных ответов. Для этой статьи ограничимся такой пирамидой тестов:
При изучении любой дисциплины самое сложное/главное понять основы, базовые принципы, на пальцах, на школьных примерах, затем, на этот металлический каркас можно навесить тонны бетонной практики, получившийся железобетонный монолит станет гарантией практически не ограниченного технического роста специалиста. Звучит самоочевидно, не правда ли ..? И тем не менее, субъективный опыт автора в проведении собеседований, а это около ~500 специалистов из стран СНГ, Индии, США в Автоматизации тестирования и сопоставимые цифры в С \ С++ мире, говорит, что даже Senior разработчики в большинстве не понимают «физического смысла» ООП, не могут озвучить базовую формулировку одного из «столпов» - инкапсуляции, хотя знают как на 3 языках, 20 способами реализовать интерфейс, класс и объект, а вот вырасти дальше уже не могут, и вынужденно в течении 20 лет топчутся на месте. Вот это досадное карьерное недоразумение мы и постараемся исправить. IMHO тема будет интересна/полезна самому широкому кругу слушателей, от молодых специалистов в Ручном тестировании до Архитекторов в Автоматизации.
Большая часть моей работы посвящена обучению, тренировке и оценке тестировщиков. Как гуманисту, мне хочется применить тут эвристику разнообразия: наши различия могут сделать команду сильнее. Это означает, что я не могу выбрать один-единственный тип тестировщиков и оценивать людей согласно этому шаблону. С другой стороны, я вижу интересные модели навыков и темперамента у тестировщиков, и имеет смысл обсудить эти модели в широком ключе. Да, все снежинки различаются, но также верно, что все снежинки похожи друг на друга.
Итак, я выделяю как минимум семь различных типов тестировщиков: административный, технический, аналитический, социальный, эмпатический тестировщик, пользователь и разработчик. Когда я начну углубляться в объяснения, я хочу, чтобы вы поняли следующее: это модель, а не тюрьма. Это кластеры эвристик или – в некоторых случаях – ролей. Ваш стиль работы или ситуация могут подходить для нескольких моделей сразу.
При изучении любой дисциплины самое сложное/главное понять основы, базовые принципы, на пальцах, на школьных примерах, затем, на этот металлический каркас можно навесить тонны бетонной практики, получившийся железобетонный монолит станет гарантией практически не ограниченного технического роста специалиста. Звучит самоочевидно, не правда ли ..? И тем не менее, субъективный опыт автора в проведении собеседований, а это около ~500 специалистов из стран СНГ, Индии, США в Автоматизации тестирования и сопоставимые цифры в С \ С++ мире, говорит, что даже Senior разработчики в большинстве не понимают «физического смысла» ООП, не могут озвучить базовую формулировку одного из «столпов» - инкапсуляции, хотя знают как на 3 языках, 20 способами реализовать интерфейс, класс и объект, а вот вырасти дальше уже не могут, и вынужденно в течении 20 лет топчутся на месте. Вот это досадное карьерное недоразумение мы и постараемся исправить. IMHO тема будет интересна/полезна самому широкому кругу слушателей, от молодых специалистов в Ручном тестировании до Архитекторов в Автоматизации.
При изучении любой дисциплины самое сложное/главное понять основы, базовые принципы, на пальцах, на школьных примерах, затем, на этот металлический каркас можно навесить тонны бетонной практики, получившийся железобетонный монолит станет гарантией практически не ограниченного технического роста специалиста. Звучит самоочевидно, не правда ли ..? И тем не менее, субъективный опыт автора в проведении собеседований, а это около ~500 специалистов из стран СНГ, Индии, США в Автоматизации тестирования и сопоставимые цифры в С \ С++ мире, говорит, что даже Senior разработчики в большинстве не понимают «физического смысла» ООП, не могут озвучить базовую формулировку одного из «столпов» - инкапсуляции, хотя знают как на 3 языках, 20 способами реализовать интерфейс, класс и объект, а вот вырасти дальше уже не могут, и вынужденно в течении 20 лет топчутся на месте. Вот это досадное карьерное недоразумение мы и постараемся исправить. IMHO тема будет интересна/полезна самому широкому кругу слушателей, от молодых специалистов в Ручном тестировании до Архитекторов в Автоматизации.
Сейчас много говорят про DevOps, Agile-разработку и «сдвиг влево». Очевидно, эти процессные модели совершили открытие: тестировщики могут не только тестировать готовый продукт, и они могут и должны быть вовлечены в каждую стадию разработки.
Это не новость для курса «Rapid Software Testing». Мы изначально отвергли идею, что продукт должен быть завершен/соответствовать определенному уровню качества или неким «приемочным критериям», чтобы перейти в тестирование. Мы приветствуем возможность протестировать что угодно, выданное нам. Мы с радостью начнем тестирование с момента зарождения идеи продукта до момента, наступившего спустя долгое время после релиза.
Если тестировщиков приглашают на планерку, то продукт для тестирования еще отсутствует как класс. Что же нам там делать?
