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