10 "тестхаков" для улучшения процесса тестирования by Святослав Римар

Speaker Rymar Svyatoslav
Title - Название доклада
10 "тестхаков" для улучшения процесса тестирования
Title in English
10 “testhacks” to improve your testing process
Annotation - Аннотация (1000 знаков с пробелами)

Несколько лет назад, благодаря программистам зародилось такое движение как лайфхакинг. Следуя примеру Дэнни О’Брайена (автора термина “lifehack”) я взял 2 слова и соединил их, в моем случае это были “Test” и “hack”.

“Testhacks” – набор полезных, простых, а главное действенных советов, которые помогут в решении комплексных задач и вопросов. Например:

· Сколько времени  уделять тест-дизайну, а сколько тестированию?

· Какие метрики лучше использовать?

· Как тестировать в сжатые сроки?

Доклад будет полезен как тест лидам, которые хотят в короткий срок улучшить процесс тестирования, так и тестировщикам, которым небезразлична судьба проекта и собственная продуктивность.

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

Annotation in English - Аннотация на английском (1000 symbols with spaces)

A few years ago, thanks to programmers a “lifehacking” movement has arisen. Following the lead of Danny O'Brien (author of the term"lifehack") I took two words and put them together. But in my case they were – Test" and "hack".

"Testhacks" is a set of useful, simple, and most importantly effective tips that will help you in solving the complex targets and issues. For example:

  • How much time should you spend on test design and test execution?
  • What metrics are better to use?
  • How to test in tight deadlines?

The speech will be useful for test leads who want to improve the process of testing and testers who care about the outcome of the project and their productivity.

Perhaps, some of the tips may seem simple to you, others more sophisticated in your situation, but the most important thing is that they really work because they have been used on more than one dozen projects, made your work clear and easy to understand. Your work became well-organized, you save your time and budget. 

Detail description or Plan of the talk- Развернутые тезисы или план доклада

План доклада:

 

Вступление

1. Происхождение и определение термина "lifehack" & "lifehacking". 

2. Что такое "testhack"?

3. Как и зачем я придумал "testhacking"?

 

Основная часть

10  основных "testhacks" - определение, внедрение, примеры с прошлых и текущих проектов.

  1. Постоянно меняйте Вашу стратегию.
  2. "Принцип Паретто" в процессе тестирования.
  3. "Mind maps in action".
  4. Сессионное парное тестирование.
  5. "Закон Паркинсона" поможет в оценке задач.
  6. Ночные билды как показатель прогресса.
  7. Забудьте о "best practices".
  8. "Теория разбитых окон" или как можно погубить проект.
  9. Метрики могут быть "опасны" или почему не стоит на них полагаться.
  10. Цифры не главное.

 

Детальный обзор каждого из "testhack" и результатов полученных после их применения.  

 

Постоянно меняйте Вашу стратегию.

Начиная работу над новым проектом, мы комплексно анализируем его, после чего принимаем решение, как будем тестировать продукт. Вопрос, который стоит перед нами с самого начала проекта: «Какую стратегию лучше использовать, чтобы добиться максимально высокого качества?». Хорошо, когда есть такой план и знаешь ответы на вопросы: «что тестировать?», «когда тестировать?» и «как?». Но рано или поздно наступает тот момент, когда  мы подходим к стоп-точке. Все усилия, которые мы предпринимаем, не приносят желанного результата. Напоминает известную «проблему пестицидов»: проходя одни и те же тестовые сценарии в один день, мы просто зайдем в тупик, и уже не будем находить дефектов в программе.

Вот здесь как раз нужно изменить «курс корабля» в другую сторону: было много скрипт тестирования – значит, пора перейти к исследовательскому. А еще лучше не ждать такого момента, а постоянно диверсифицировать стратегию. Цель диверсификации в повышении производительности - это не обеспечит качество и не даст гарантии, но регулярные изменения в вашей стратегии могут помочь установить предельно низкий уровень риска. Именно такой подход дает возможность уменьшить шанс пропуска наиболее критических багов и добиться ожидаемого качества продукта.

 

"Принцип Парето" в процессе тестирования.

«20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата»

 

Знание этого факта легко применить в области тестировании: «80% дефектов сосредотачиваются в 20% функционала»

То есть, ошибки в ПО (модулях, компонентах) распределены неравномерно. В реальности это соотношение бывает разным, например 70/30 или 90/10.

«Как использовать «правило 80/20?»

- старайтесь сортировать баги, выявляя их первопричины, а  не последствия. Группировка всех дефектов, которые приводят к падению ПО - неэффективна. Лучше же разделить их на: дефекты, исходящие из модуля X; дефекты, исходящие из модуля Y; дефекты, исходящие из модуля Z.

- Больше общайтесь с программистами. 80% багов могут быть результатом использования одной и той же библиотеки, сторонних компонент и .т.п..

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

 Читая разные статьи, нашел интересный факт о Microsoft и принципе Парето:

«В компании Microsoft стало известно, что 80 процентов от ошибок и сбоев в Windows и Office вызваны 20 процентами от всего пула обнаруженных ошибок, и, что 1% кода приносит компании более чем 50% головной J»

 

"Mind maps in action".

Mind maps или карты памяти давно и широко используются во многих областях. Тестирование не исключение. Главный плюс карт в том, что они универсальны. Их можно легко использовать как для исследовательского, так и для скриптового тестирования. Карты могут быть вашим чек-листом, документацией, требованиями, моделью продукта, to-do листом, иерархией проекта и т.п.. (Добавить скриншоты с примерами).

Главное преимущество это визуализация, а соответственно они легко воспринимаются нашим мозгом и хорошо запоминаются. В современном мире вездесущего Agile’а  - этот как раз тот инструмент, который дает возможность легко и быстро вносить изменения. Полезен он будет всей команде: бизнес аналитикам, тестировщикам, разработчикам и менеджерам.

 

Сессионное парное тестирование.

Разработчики давно работают в парах, а чем мы хуже? J Я не могу пока заявить, что парное тестирование очень эффективно и принесло нам неслыханные результаты. Но могу заявить, что оно идеально подходит для обучения новых бойцов. Проект у нас начинался с 2 тестировщиков и со временем вырос до 6. У нас не было как такового выделенного времени на разные митинги, чтоб сесть показать, объяснить и разложить все по полочкам. Поэтому, мы решили испробовать парное тестирование в качестве процесса обучения. Что получили:

- Обучение получилось быстрым и динамичным

- На выходе кроме понимания программы и проблем, которую она решает, получили баги и вопросы, возникшие в ходе сессии

- Новые идеи

- Работа вместе над одной задачей помогла нам хорошо подружить людей и сплотить коллектив.

- Меньше вероятности пропустить дефект

 

"Закон Паркинсона" поможет в оценке задач.

Думаю, большинству из вас знаком  «Закон Паркинсона». В области разработки программного обеспечения его еще называют правилом 90:90. «Первые 90% кода отнимают первые 90% времени разработки. Оставшиеся 10% кода отнимают вторые 90% времени разработки». В истории есть 2 очень хороших примера, которые подтверждают закон на практике:

1.     20 лет назад Ройял Фаррос, вице-президент компании Т/Maker, где он руководил разработкой сказал следующее:

«Многие из нас устанавливали сроки сдачи заведомо невозможные, причем настолько, что делали верным одно из следствий закона Паркинсона: «Для завершения проекта требуется в два раза больше времени, чем было отведено». Я твердо верил, что если выделить под проект шесть месяцев, он займет год. Так что, если необходимо было получить что-то через два года, следовало требовать сдачи через год. Тупое принуждение, конечно, но оно всегда срабатывало».

2.     С той же проблемой столкнулся предприниматель Риджели Эверс, работавший над созданием QuickBooks:

«Выпуск первой версии QuickBooks должен был занять девять месяцев. Мы правильно оценили, что начальное развитие будет длиться столько же, сколько длится беременность, но все-таки ошиблись: у нас ушло почти два с половиной года – срок беременности слона».

Иными словами, это самоуничижительное правило гласит, что когда программисты написали 90% кода, они все еще не знают, где находятся! Руководство отлично понимает, что успеть сдать работу вовремя нельзя, какие сроки сдачи ни устанавливай. Разработчики же лучше всего работают под давлением, поэтому руководство использует дату сдачи, как одно из средств давления.

На последнем проекте мы занимались визуализацией данных, создавали разные графики (bar chart, column, stacked и т.д.). Работали в недельных спринтах: по факту реализация 1 графика  занимала 1 спринт. Честно говоря, клиент особо рад этому не был, для него это выглядело довольно медленно. Понятно, что у нас на все были объяснения.

Через некоторое время ко мне в руки попала книжка Кауфмана «Сам себе MBA» вот в ней я и прочел о таком понятии, как «Закон Паркинсона». В голове сразу же появилась мысль, что надо попробовать применить его у нас на проекте когда садимся за оценку историй на спринт. Вместо привычного уже 1 графика на спринт мы взяли 2. Как ни странно, но к концу спринта все было готово. Мы решили продолжить наш эксперимент и за следующий спринт опять реализовали 2 графика. Но самое интересное было впереди. После этого мы решили вернуться к прошлому режиму, взяли на спринт только 1 график, что в результате – думаю всем и так ясно. Мне это напомнило студенческие годы, когда диплом писался за 3 дня J

 

Ночные билды как показатель прогресса.

Обычной практикой скрама является демо, на котором команда разработки показывает, чего ей удалось добиться за спринт. Примерно 3-4 месяца мы тоже следовали этому процессу и регулярно под конец спринта, каждую неделю, предоставляли билд и показывали, что же мы реализовали. Получается, что каждые 5 дней заказчик может видеть результат. Если же у Вас спринт продолжается 2 недели, то каждые 10 дней. Если в первом варианте это еще не так долго, то второй уже довольно таки длительный срок.

Думаю, что каждый из нас старается осчастливить своего заказчика, и по сути все, что для этого нужно, это прогресс. Он дает возможность нашему клиенту видеть, что мы движемся и, чем большей будет прозрачность процесса и задержки, тем больше он будет доволен. Как по мне, лучший вариант решения это последовать примеру компании Jet Brains. У них есть такая практика -  не выпускать свой «ночной» билд, если в нем более 42 падающих тестов.

Мы тоже решили попробовать у себя на проекте. Что в результате?

Постепенно добились того, что выпускаем билд, если в нем не более 25 падающих тестов;

- Демо теперь проводиться не каждый спринт, а значит больше времени на разработку;

- Получили большое доверие со стороны клиента.

 

Забудьте о "best practices".

Что такое «best practice»? Если говорить просто – это что-то проверенное и рабочее. Так было сделано раньше. Но в современном мире этого уже явно недостаточно. Все меняется очень быстро и тем более технологии. Для того, чтобы выделиться и быть успешным нужно нечто большее, чем лучшие практики. «best practices» должны рассматриваться лишь в качестве ориентира, такой себе отправной точка для дальнейшего развития. Я считаю, что  есть только «хорошие практики», так как все зависит от 3 главных факторов: индустрия применения, контекст использования и целевые пользователи.

Вот на них и стоит сфокусироваться.

 

"Теория разбитых окон" или как можно погубить проект.

Был у меня один интересный проект, работали с клиентом из России. Начали активно заниматься тест дизайном, написали где-то 2500 тест кейсов. В это же время активно велась разработка, и наша команда тестировщиков большую часть времени занималась тем, что проходила все эти тесты. Напоминает такое нон-стоп регресс тестирование. После нескольких недель работы мы уже помнили все эти сценарии, в мозгу фактически сформировался паттерн, и мы на автомате проставляли статусы pass / fail. Обычным явлением стали такие фразы: «это мелкие баги», «неважно для завтрашнего релиза» или «известная проблема, пофиксим позже». Хуже всего в такой ситуации, что люди начинают привыкать к такому порядку дел и это, конечно же, сказывается на качестве продукта. А далее все эти «хвосты» только растут  в количестве, получается такой себе снежной ком, который с каждым метром становится все больше и больше.

Концепт"Теории разбитых окон" (если кто-то разбил стекло в доме и никто не вставил новое, то вскоре ни одного целого окна в этом доме не останется, а потом начнется мародерство) очень прост и в тестировании, как и в жизни, работает на все 100%. В нашем случае все обошлось, так как на проект попали «свежие» люди, и вовремя навели порядок.

 

Метрики могут быть "опасны" или почему не стоит на них полагаться.

Когда речь идет о метриках, мне сразу приходят в голову слова министра Британии Бенджамина Дизраэли: «Существуют три вида лжи: ложь, наглая ложь и статистика». Метрики это как статистика. Причем самое интересное в том, что понимать ее можно по-разному. Много строчек кода это значит много работали или просто много некачественного кода? Если тестировщики нашли много дефектов, получается, что разработчики писали низкокачественный код? А если нашли мало, то плохо искали?

Как же быть в такой ситуации? Ведь менеджеры так любят метрики J

Добавить скриншоты с примерами.

 

Цифры не главное.

Типичная проблема на многих проектах: «не успеваем протестировать версию к концу спринта».

Какие есть варианты решения?

- нанять больше людей

- сдать проект с известными проблемами

- задержать поставку

 

Причем каждый вариант выглядит как проигрышный. Так что же делать?

- Не нанимайте много тестеров (вспомните Де Марко и его роман «Deadline»)

- Обучайте ваши кадры

- В ручном тестировании сделайте фокус на исследовательское тестирование

- Увеличьте продуктивность, работая в сессиях с заранее определенными целями

 

- Оптимизируйте работу и максимально используйте тулы

 

Заключение

1. Идеи по развитию движения "testhacking"

2. Вопросы и ответы

 

Слайды еще в процессе подготовки.

Type of Presentation - Тип доклада
  • Regular Talk - Секционный доклад (40 min)
Level of audience - Уровень аудитории
  • 2 (intermediate)
Contact info - Контактная информация

email: svyat.rymar@gmail.com

phone: +380 (096) 606 10 60

Public profile - Ссылка на публичный профиль
http://www.linkedin.com/profile/view?id=170002252
Subjects of the talk - Тематика доклада
  • Other topic
Last Updated 12 Sep 16:03