Эта история повторяется вновь и вновь – коллега говорит мне, что сотрудничает с организацией, обучая ее разработчиков тестированию. Поначалу это звучит, как отличная идея – хотя большинство разработчиков и так достаточно хорошо тестируют то, что должны тестировать разработчики, особенно если они сотрудничают друг с другом и проводят ревью своей работы.
Однако это не то тестирование, на которое нацелен тренинг. Оказывается, что разработчиков обучают высокоуровневому интеграционному и системному тестированию – видам глубокого тестирования, требующим значительных доменных знаний и существенного отхода от образа мышления разработчика. Зачем разработчикам этот тренинг? Затем, что организация избавилась от тестировщиков, которые занимались этим ранее, и надеется, что теперь этим займется разработка.
Публикуем доклад Владислава Савченко «Сертификация с точки зрения разработчика», собравший много хороших отзывов на прошлой конференции TestCon Moscow.
Современные разработчики всё больше сталкиваются с техническими вопросами в части оценки соответствия их изделий требованиям безопасности (соответствия стандартам PCI DSS, нормативным документам ФСТЭК России и пр.). Опыт работы Испытательной лаборатории, проводящей такие оценки позволил сформулировать основные проблемные технические моменты, которые могут возникнуть в ходе такой оценки. Владислав подробно рассмотрел, как правильно подготовить свой продукт к процедуре оценки соответствия, какие тесты необходимо проводить перед передачей материалов в Испытательную лабораторию, а также типовые ошибки, допускаемые разработчиком и пути их разрешения.
Были ли у вас когда-либо трудности с объяснением возможного бага разработчику, архитектору, проектному менеджеру? Бывает ли, что вас не понимают, или вы не понимаете других участников команды, обсуждая систему проекта или другие абстрактные концепции? Вы не одиноки. Большие и сложные системы влекут за собой возможность абсолютного отсутствия единства их понимания среди коллег. Эта статья рассматривает использование символов и рисунков как инструмента, который поможет вам понимать и объяснять сложные системы.
На днях меня вновь спросили "Когда заказчик спрашивает, сколько времени займет тестирование нашего проекта, что мне ему отвечать?"
Простейший ответ, который я могу предложить, таков: если тестирование – часть процесса разработки, то оно займет ровно столько же времени, сколько разработка. Это связано с тем, что эффективное и продуктивное тестирование не разделено с разработкой – оно встроено в разработку.
Когда мы разрабатываем программный продукт или услугу, мы создаем дизайны, прототипы, функции, модули, компоненты, интерфейсы, интегрированные компоненты, сервисы, системы целиком… С каждым созданным нами элементом ассоциируется какой-либо уровень риска – возможности возникновения проблем. Дабы преуспеть, каждый элемент системы должен вписываться в общую картину совместно с другими элементами, и удовлетворять запросам тех, кто использует и создает систему.
Тестировщик всегда работает в условиях недостатка времени: беклог не уменьшается, релиз на носу, а протестировать нужно еще многое. Чтобы обеспечить качество продукта, нужно постоянно повышать эффективность собственной работы. Один из способов - освоить некоторые инструменты, облегчающие рутинные действия в тестировании.
Давайте вначале разберемся, что подразумевается под словом "план". Мы с Джеймсом Бахом говорим о планировании (и учим планировать в курсе Rapid Software Testing), понимая план как сумму или пересечение стратегии и логистики. Стратегия – это набор идей, направляющих ваш тест-дизайн. Логистика – это набор идей, направляющих распределение ваших ресурсов. Объедините их, и получится план. Тут очень важно отметить, что план – это не физический предмет - это набор идей. Следовательно, важно различать план и документацию по планированию – то есть документы, содержащие какую-то касающуюся плана информацию.
Вопрос, что должно входить в тест-план, можно интерпретировать двояко – во-первых, как вопрос про "план", а во-вторых, как вопрос о документации планирования. Начнем с плана.
Оглядываясь на свой опыт работы в тестировании, я осознаю, что получила крупные поучительные уроки, и сейчас они кажутся мне очень понятными и очевидными. Однако все эти годы я писала о своей позиции, и могу оценить, насколько мои взгляды менялись со временем. Поначалу я нервничала, если писала о том, что мне казалось верным (хотя это могло быть абсолютно не так), но блог помог мне справиться с волнением и обращать внимание на положительный эффект от него.
Множество фундаментальных перемен я предсказать не могла – они происходили постепенно в течение длительного времени. Ретроспективно они очень существенны, и их легко воспринимать как то, что я знала всегда. О четырех из них я хочу рассказать подробнее – они резко изменили мою систему ценностей и стимулировали поиск новых возможностей.
Баг-хантинг – распространенная практика в мировых тест-организациях. Однако некоторые тест-менеджеры думают, что баг-хантинг – это поиск багов на границах через неформальные эксперименты с приложением.
Что такое баг-хантинг (и чем он не является)?
Баг-хантинг – это неформальные упражнения по тестированию. Не надо путать их с ситуацией, когда вы развлекаетесь с приложением без цели и смысла, а также не смешивайте их с исследовательским тестированием. Вот почему:
Баг-хантинг – это групповая деятельность, а исследовательское тестирование может проводиться единолично.
Цель баг-хантинга – подключить к процессу тех, кто не является тестировщиком, и найти неочевидные баги. Исследовательское тестирование нацелено на "обычные" баги, и им обычно занимаются исключительно тестировщики.
Исследовательским тестированием можно заниматься на любой стадии процесса разработки. Баг-хантинг приносит пользу, если приложение достаточно стабильно.
"С тестированием все путем". Значит ли это, что продукт в хорошей форме, или что мы добились хорошего покрытия, или нашли много багов? "С тестированием все очень плохо". Продукт хорош? Тестирование заблокировано? Мы ошибочно ставим много багов?
Люди отвечали на него, предлагая собственные интерпретации. Это неудивительно. Их интерпретации различались между собой, что тоже неудивительно. Меня больше удивило количество людей, убежденных, что есть некий общеизвестный базис, на основании которого мы можем оценить наше тестирование как хорошее или плохое – а также неявно предполагающих, что люди автоматически поймут, о чем мы.
