Home

Автор: Наталья Руколь

Самый лучший способ оценить, хорошо ли мы протестировали продукт – проанализировать пропущенные дефекты. Те, с которыми столкнулись наши пользователи, внедренцы, бизнес. По ним можно многое оценить: что мы проверили недостаточно тщательно, каким областям продукта стоит уделить больше внимания, какой вообще процент пропусков и какова динамика его изменений. С этой метрикой (пожалуй, самой распространённой в тестировании) всё хорошо, но… Когда мы выпустили продукт, и узнали о пропущенных ошибках, может быть уже слишком поздно: на “хабре” появилась про нас гневная статья, конкуренты стремительно распространяют критику, клиенты потеряли к нам доверие, руководство недовольно.
Чтобы такого не происходило, мы обычно заранее, до релиза, стараемся оценивать качество тестирования: насколько хорошо и тщательно мы проверяем продукт? Каким областям не хватает внимания, где основные риски, какой прогресс? И чтобы ответить на все эти вопросы, мы оцениваем тестовое покрытие.

Зачем оценивать?

Любые метрики оценки – трата времени. В это время можно тестировать, заводить баги, готовить автотесты. Какую такую магическую пользу мы получаем благодаря метрикам тестового покрытия, чтобы пожертвовать временем на тестирование?

1. Поиск своих слабых зон. Естественно, это нам нужно? не чтобы просто погоревать, а чтобы знать, где требуются улучшения. Какие функциональные области не покрыты тестами? Что мы не проверили? Где наибольшие риски пропуска ошибок?
2. Редко по результатам оценки покрытия мы получаем 100%. Что улучшать? Куда идти? Какой сейчас процент? Как мы его повысим какой-либо задачей? Как быстро мы дойдём до 100? Все эти вопросы приносят прозрачности и понятности нашему процессу, а ответы на них даёт оценка покрытия.
3. Фокус внимания. Допустим, в нашем продукте около 50 различных функциональных зон. Выходит новая версия, и мы начинаем тестировать 1-ю из них, и находим там опечатки, и съехавшие на пару пикселей кнопки, и прочую мелочь… И вот время на тестирование завершено, и эта функциональность проверена детально… А остальные 50? Оценка покрытия позволяет нам приоритезировать задачи исходя из текущих реалий и сроков.

Доклад одного из наших тренеров Натальи Руколь (автор и ведущий тренингов Школа тест-менеджеров и Школа тест-аналитиков) на конференции SQA Days 17.

Глупые люди наступают на одни и те же грабли потому, что ничему не учатся. Тестировщики наступают на одни и те же грабли потому, что надо воспроизвести дефект.

На конференциях принято рассказывать: мы сделали такую крутую штуку! Мы внедрили опупенный инструмент! Посмотрите, как мы справились с этими техниками… Такие рассказы слушать приятно, и есть, чему поучиться. Но наши рабочие дни обычно состоят не из геройских подвигов! Мы сталкиваемся с проблемами и трудностями:

• пропустили критичный дефект
• не успели провести тестирование вовремя
• автотесты не окупаются и требуют слишком много времени
• нет сил актуализировать тесты и планы

Что делать при возникновении таких проблем? Я знаю отличное решение:

расплакаться! Но на докладе расскажу о другой реакции: как извлекать полезный опыт из каждой допущенной ошибки.

На этом докладе вас ждут:

• мои самые позорные грабли в карьере тестировщика
• извлечённый опыт и найденные решения
• самоуспокоительные мантры тестировщиков.

Обсуждение, организованной Татьяной Писчасовой, о Мире без тестировщиков на конференции CodeFest 2015.

В черном-черном городе.. на черной-черной горе.. в черном-черном офисе.. черные-черные разработчики.. писали черные-черные программы...
И САМИ ИХ ТЕСТИРОВАЛИ!!!!

Каждый тестировщик будучи junior-ом слышал такую страшилку от старших товарищей.

Сегодня в тренде кроссфункциональные команды. Роль тестировщика не привязана к определенному человеку - тестировать может каждый. Некоторые прогрессивные команды вовсе обходятся без тестировщиков.
То, что когда-то было страшной сказкой становится реальностью.

Приглашаю коллег обсудить этот тренд. Чем грозит (и грозит ли) тестирование продукта без выделенного специалиста.
В чем плюсы, в чем минусы такого подхода.
На каких проектах он применим, на каких - нет.
Как обеспечить качество продукта без специалистов по качеству.

И как жить тестировщикам, которых "оставили без работы".

Представьте себе, что вы приходите к парикмахеру за новой стрижкой, хотите объяснить ожидания, а он без вопросов начинает орудовать ножницами? Или представьте себе магазин, в котором вам пытаются всучить готовую продуктовую корзину, и не дают возможности выбора продуктов. Звучит как-то странновато, не находите?

Но в тестировании очень многие менеджеры пытаются сделать то же самое! В то время, как руководители проектов, разработчики и другие сотрудники компании что-то ожидают от тестирования, мы пытаемся им сделать "как правильно" вместо "как они хотят".

В результате нас ждут проблемы с договорённостями, в команде царит недопонимание. Зато, мы соответствуем своему абстрактному "хорошо" и "правильно"!

Для просветлённых тест-менеджеров, готовых отказаться от таких абстрактных правил, предлагаем вниманию 1-й вводный вебинар нового онлайн-тренинга Натальи Руколь Школа Тест-Менеджеров v 2.0.

На нём мы рассмотрим:

• Кто является внутренним заказчиком (пользователем) тестирования?
• Что от нас хотят?
• Как понять ожидания, когда их не могут сформулировать?
• Как сделать тестирование более полезным и подходящим вашему проекту?

Вебинар будет полезен тест-менеджерам и тестировщикам-оркестрам, самостоятельно определяющим "как будет проводиться тестирование на проекте".

Доклад Дмитрия Химиона, Performance Lab на конференции CodeFest 2015.

Вы — участник проекта, где релиз дополняется 20-ю патчами?
Вы — QA-менеджер и чувствуете, что разработчики «лукавят», говоря что «у них всё работает»?
Вы — тестировщик и думаете, куда бы развиваться и как еще можно повлиять на качество проекта?
Тогда этот доклад будет вам интересен и, возможно, полезен в работе. Я расскажу о работе с проблемой технического долга со стороны команды тестирования, что qa-team может в этой области, и как оно может выглядеть. Рассмотрим связь между ISO, зрелостью процессов, командой тестирования и проявлением технического долга.

Доклад Андрея Солнцева, разработчика в таллинской компании Codeborne, на конференции CodeFest 2015.

Есть большие отделы QA, поделённые на касты «мануальщиков», «автоматизаторов», «тест-менеджеров» и «тест-лидов». Есть армия тестировщиков, колбасящая селениум изо дня в день. Есть гриды и облака для параллельного запуска тестов в тысячу потоков по ночам.

А мы разрабатываем интернет-банк всего лишь вчетвером. Вместе с автотестами. Никаких аналитиков. Никаких тестировщиков. Никаких тест-менеджеров. И тесты наши пробегают всего лишь за 5 минут. Как нам это удаётся?

Смотрите запись доклада

Выступление Максима Цепкова на AgileDays-2015.

Страница данного доклада с кратким текстовым содержанием и презентацией

Управление проектами и критерии качества в ИТ прошли долгий путь исторического развития, сменив несколько моделей. Начиналось все с совершенного программного обеспечения (software system) как результата качественного проектирования, свойственного НИОКР. Далее был период всеобъемлющего нормирования процессов по их разработке (PMBoK 3, RUP), сменившийся, отчасти революционно, гибкими подходами к разработке (SCRUM, Kanban), которые сделали упор на сроки и предсказуемость поставки. А сейчас фокус сместился на удовлетворенность стейкхолдеров и достижение бизнес-целей (OMG Essence of Software Engineering).

Но развитие не остановилось. Непонимание места конкретных подходов, методологий и практик в контексте общего развития отрасли не позволяет эффективно их использовать и порождает множество пустых дискуссий среди разработчиков о том, как правильно.

За время доклада мы рассмотрим основные вехи развития подходов к управлению ИТ-проектами и эволюцию критериев качества ПО в мире и в России, которая в 90-х годах шла своим путем, но за последнее время приблизилась к общим трендам.

А также разберемся, для каких проектов и команд уместны те или иные модели управления проектами, в чем могут крыться их преимущества и недостатки и какие формы организации разработки им соответствуют. Понимание этого позволит не только настраивать процессы в своем проекте, но и вести содержательные дискуссии с приверженцами иных форм организации, которые часто встречаются среди заказчиков и руководства.

Автор: Роман Шейко. Оригинальная публикация в блоге автора

Первая статья

Сегодня я хотел бы рассказать о создании стратегии для тестирования одного крупного сайта (http://lingualeo.com). Коротко: это онлайн-платформа для желающих изучить английский язык.

Цель у меня такая: не показать результат, а в первую очередь рассказать о самом процессе составления стратегии. Мне было интересно проследить, как и что я делаю. Это напоминает работу над ошибками и самопроверку. Кроме того, это попытка объяснить свою работу. Не всегда это просто сделать, потому что часто мы работаем интуитивно. Для меня умение объяснить свою работу означает способность понять свои ошибки (что я делаю неправильно) и свои достижения (что я делаю правильно).   
Итак, я расскажу о процессе составления стратегии и постараюсь сделать это в структурированной форме, по порядку. Как вы понимаете, не каждый процесс структурирован сам по себе. Поэтому не факт, что у меня получится разложить все по полочкам.

Автор: Роман Шейко. Оригинальная публикация в блоге автора

Тестовая стратегия определяет то, как мы тестируем продукт. Это набор мыслей и идей, которые направляют процесс тестирования. В разных компаниях, а также в разных источниках это понятие может звучать по-разному - например, как подход к тестированию или высокоуровневый тест план. Я считаю, что разница между тестовой стратегией и тест планом заключается в покрытии и ‎уровне детализации. Стратегия покрывает процесс тестирования продукта в целом, а тест план обычно покрывает какую-то часть тестирования или отдельный релиз. Уровень детализации у тест плана как правило выше, он в своем роде уточняет тестовую стратегию, наполняет ее необходимыми деталями. Но граница между этими понятиями - условна и размыта. В тестовой стратегии могут покрываться в деталях некоторые важные моменты, в тест плане могут быть обобщения.

Формирование тестовой стратегии - интересный процесс, который часто выполняется нами на уровне интуиции, когда мы сами не до конца осознаем, почему мы решили делать так или иначе. Часто после своего формирования где-то на уровне интуиции стратегия так и продолжает жить там, в области неосознанного. Давайте попробуем достать её оттуда.

Анастасия Коцевич, ЗАО «Технологии качества», бренд A1QA

Не секрет, что взаимоотношения между программистами и тестировщиками нельзя назвать идеальными. Сама структура подхода, когда «одни программируют – другие тестируют» порождает конфликт между этими категориями специалистов. Естественно, в понимании девелопера тестировщик вставляет палки ему в колеса, находя изъяны в идеальном, с его точки зрения, коде. Тестировщик, в свою очередь, как правило недоволен неравномерностью нагрузки, задержками с поставками «билдов» и жесткими дедлайнами.

Благодаря этому (и иным соображениям целесообразности) «кодеры» и «тестеры» обычно работают отдельно друг от друга. Но иногда бывают исключения. Опытом участия в таком «совместном» проекте и извлеченными уроками мне хотелось бы поделиться в этой статье.

Как тестировщику, мне ранее не приходилось работать бок о бок с командой разработки того проекта, на котором я работала. Признаюсь честно, мне не очень хотелось начинать. Более того, я этого боялась. Нет, переезжать в другую страну или город не было нужды. Нужно было всего лишь переместиться на этаж выше, но от этого страх не уменьшался.