34. Основной упор – контент:
• Сравнивали с эталоном
• Валидировали самостоятельно
35. Основной упор – контент:
• Сравнивали с эталоном
• Валидировали самостоятельно
36. Основной упор – контент:
• Сравнивали с эталоном
• Валидировали самостоятельно
• Верифицировали самостоятельно
37. Основной упор – контент:
• Сравнивали с эталоном
• Валидировали самостоятельно
• Верифицировали самостоятельно
• Валидацию раздали заинтересованным
лицам
38. Саппорт:
• Плановая выкатка контента пачками
• Межязыковое единообразие
• Более сговорчивые владельцы
• 7,5К статей на основные локализации
56. ДА статическому тестированию:
• Читаем чужой код
• Обсуждаем чужой код
• Правим чужой код
• Учимся у боевого товарища
• Учим боевого товарища
57. ДА статическому тестированию:
• Читаем чужой код
• Обсуждаем чужой код
• Правим чужой код
• Учимся у боевого товарища
• Учим боевого товарища
• Есть анализатор – очень круто
94. Эмпирический метод:
• Собрали в кучу функционал;
• Прикинули для него ситуации;
• Поставили приоритет;
• Сопоставили с рисками;
95. Эмпирический метод:
• Собрали в кучу функционал;
• Прикинули для него ситуации;
• Поставили приоритет;
• Сопоставили с рисками;
• Обсудили список с остальными;
96. Эмпирический метод:
• Собрали в кучу функционал;
• Прикинули для него ситуации;
• Поставили приоритет;
• Сопоставили с рисками;
• Обсудили список с остальными;
• Отсортировали по убыванию.
99. Спасибо за внимание!
• Я: Роман Ивлиев
• Е-почта: roman.ivliev@mail.ru
• @dumtest
• dumtest.livejournal.com
Editor's Notes
Если сравнить и не брать в рассчет колонки, и что прыгает немного картинка, то отличие серьезное одно – вместо eshop Online Shop и в селекторе страна болдом. Хрен с ним с селектором. Но пункт меню отломал часть тестов на последовательность и состав меню.
А вот теперь пробем стало гораздо больше. До свидания старая DOM-модель, здравствуй новая, очаровательная.
Тестирование контента. К сожалению, к составу контента маркетологи очень требоваетельны. По их науке даже небольшое изменение в тексте роняет или возносит продажи на непомерные высоты. Т.к. все страницы разные, первой идеей было - "а давайте сравним то, что получилось с предыдущей версией сайта". Т.е. по сути воспользуемся подходом тестирования на базе эталонов и попробовать найти ответ на вопрос - "так ли новая кажет, как старая казала". По началу так и делали. В результате потратили кучу времени, т.к автоматически проверять контент оказалось еще сложнее. Дальше решили всех обмануть и проводить тестирование по принципу "работает ли новая система корректно". Т.е. по сути приватизировав право на валидацию. От этой идеи тоже очень быстро отказались, т.к. на русский и английский языки хватило, а вот испанский и итальянский подкачали. Не нашлось носителей языка среди команды миграции. По сути работа миграторов свелась к тому, что проверить, все ли компоненты (картинки, стили и т.д. ) присутствуют и корректно отображаются на странице. А роль читателей отдали носителям языка из группы контент-редакторов. С блоками продаж поступили немного не так: отдали валидацию сотрудникам региональных отделов продаж. Они проверяли корректность работы сайта с интернет-магазинами, настраивали свои трекеры и, заодно, вычитывали тексты и проверяли, что картинки соответвуют дейтсвительности.
Ведь есть же старый сайт. Он то точно правильно работает. Тут же напоролись на то, что работает то он нормально, но вот контент битый. Где очепятка, где картинка не та. Это свойственно системам, где контент контролируется редакторами и не проходит достаточную проверку перед публикацией.
Ведь есть же старый сайт. Он то точно правильно работает. Тут же напоролись на то, что работает то он нормально, но вот контент битый. Где очепятка, где картинка не та. Это свойственно системам, где контент контролируется редакторами и не проходит достаточную проверку перед публикацией.
Не всегда это подходит.
Большие объемы контента. Ребята из саппорта применили неведомый нам доселе прием и не стали сразу запускать новый сайт в продакш, а разрешили нам запустить его в так называемой "бете", чем сделали нам тестирование прогулкой под луной, а не забегом под метеоритным дождем. Что нам это дало - фактор суеты был уничтожен. В результате сейчас в паблике ворочаются оба сайта - старый и новый, не сильно отличающиеся по контенту. При этом новый вежливо просит с вас фидбек. Ура. Мы за бесплатно получили некоторое количество бета-тестеров. Люди пишут отзывы, люди находят баги. Но это баги в бете:) Даже те, кто не пишет баги - тыкают странички, контролы, формочки. А еще афигенная тема признавать свои ошибки - т.е. если пользователь натыкался на несуществующую страницу или на битый контрол (дя, мы иногда отдаем 40е и 50е, но под картинку с извинениями). А еще ниже картинки - письмо разрабу/тестеру, что что-то отвалолось и можно что-то откопать по горячим следам. Функциональное тестирование: ничего умнее не придумали, как сравнение с эталоном. Старый сайт в рабочем состоянии, вот с ним и сравнивали. Объекты для сравнения выковыривали заранее. Т.к. сайт саппорта не является чем-то высокотехнологичным - таких объектов нашлось не очень много. Были правда и те, которые были созданы с нуля. Их пинали по полной и по всем правилам науки.Контролы и прочий функциональный стаф. При условиях работы сайта под естественной нагрузкой - немного более агрессивное логгирование с нотификацией в почту о критических сбоях (да, оно тормозит время отклика, но мы в бете:)) в компонентах залог нахождения объяснения очень интересным эффектам, на получение которых в лабораторных условиях ушло бы очень много времени. Т.о. мы и тут не ушли от классической науки, применив так назывваемое "soak-тестирование" - тестирование системы в естественной среде обитания под естественными нагрузками. Что касается внутреннего тестирования, которое мы, естественно проводили, подход был выбран такой - чтобы не проверять глазками 7, 5К статей, отсортировали их по рейтингу (старая система исправно считала гвозди) и начали проверять сверху вниз. Плюс ребята из саппорта очень дисцеплинированные - привлекают свои локальные офисы, тыкают сами, пишут баги и т.д.
Ребята из саппорта применили неведомый нам доселе прием и не стали сразу запускать новый сайт в продакш, а разрешили нам запустить его в так называемой "бете", чем сделали нам тестирование прогулкой под луной, а не забегом под метеоритным дождем. Что нам это дало - фактор суеты был уничтожен. В результате сейчас в паблике ворочаются оба сайта - старый и новый, не сильно отличающиеся по контенту.
Не всегда это подходит.
Не всегда это подходит.
Затраты напрямую зависят от того что и как мы тестируем. Чем меньше команжда прикладывает усилиц впустую, тем больше толку и с высокой степенью вероятности выше качество.
Затраты напрямую зависят от того что и как мы тестируем. Чем меньше команжда прикладывает усилиц впустую, тем больше толку и с высокой степенью вероятности выше качество.
Затраты напрямую зависят от того что и как мы тестируем. Чем меньше команжда прикладывает усилиц впустую, тем больше толку и с высокой степенью вероятности выше качество.
Затраты напрямую зависят от того что и как мы тестируем. Чем меньше команжда прикладывает усилиц впустую, тем больше толку и с высокой степенью вероятности выше качество.
Дальше немного про то, что мы использовали, чтобы облегчит себе жизнь
Группировка контента и постоянные демы. Использование ресурса заказчика на все проценты
Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
Скажем неткодоунингу. Скажем да - компонентному архитектурингу.
Рассказать про то, что в команде нет выделенного тестировщика, но это совершенно не значит, что нет тестирования.
Да, это может снизить производительность системы, но, для этого есть следующий инструмент. Но все это ради следующего инструмента. Это ведь совсем не сложно. Тут вариантов использования куча целая.
Это было наверное самое ценное предложение из всех. Для всех участников процесса сценарии были сделаны одинаковыми. Составленные в наиболее удобоваримой форме – степ-бай-степ с привлечением маркетинга и саппорта, которые стопитсот лет назад построили эти сценарии на основе статистических данных, собранных на миллионах пользователей. С ними же собрали перечень критичексих для бизнеса страниц, на которые уделяли наибольшее внимание.
Уаля. Вопрос регрессии решен.
Нагрузка. Использовали JMeter в распределенном исполнении и ab. Запаса по производительности у серверов прилично, поэтому в основном силы тратили на снижение ресурсоемкости операций. Плюс к этому нагло пользовались распределенной архитектуров системы. На серверах-балансерах включали и выключали ноды, предварительно настроив системы мониторинга (тут кстати стоит отметить, что сами системы мониторинга, особенно с включенным графическим модулем, сильно поедают ресурсы). Т.о. мы получали возможность наблюдать за поведением сервера при реальных нагрузках (имеетсч ввиду реальное поведение пользователя, который приходит на индекс, затем топает в поиск, потом переходит в продуктовые блоки и т.д.) При этом опять же усиливали логирование. Это конечно не очень правильно, но определенных успехов в поимке слабых мест в системе достичь удалось. Почему не достигали на берегу? Потому что система из коробки, с чрезвычайно нетипичным поведением в некоторых ситуациях. Кстати, вот эти чуваки https://browsermob.com/ абсолютно бесплатно предлагают померять время отдачи контента из разных точек, но и напихали на сайт много интересной информации. А еще можно зарегистрироваться и получить еще кучу плюшек.
Нагрузка. Использовали JMeter в распределенном исполнении и ab. Запаса по производительности у серверов прилично, поэтому в основном силы тратили на снижение ресурсоемкости операций. Плюс к этому нагло пользовались распределенной архитектуров системы. На серверах-балансерах включали и выключали ноды, предварительно настроив системы мониторинга (тут кстати стоит отметить, что сами системы мониторинга, особенно с включенным графическим модулем, сильно поедают ресурсы). Т.о. мы получали возможность наблюдать за поведением сервера при реальных нагрузках (имеетсч ввиду реальное поведение пользователя, который приходит на индекс, затем топает в поиск, потом переходит в продуктовые блоки и т.д.) При этом опять же усиливали логирование. Это конечно не очень правильно, но определенных успехов в поимке слабых мест в системе достичь удалось. Почему не достигали на берегу? Потому что система из коробки, с чрезвычайно нетипичным поведением в некоторых ситуациях. Кстати, вот эти чуваки https://browsermob.com/ абсолютно бесплатно предлагают померять время отдачи контента из разных точек, но и напихали на сайт много интересной информации. А еще можно зарегистрироваться и получить еще кучу плюшек.
Они все делают сами. Даже сценарии писать не надо.
Дальше немного про то, что мы использовали, чтобы облегчит себе жизнь
Низкий приоритет подождетПрикинуть по времени, что есть, а что реально надо прикрывать?Прикинуть, а не пора ли сразу просить людей у Толика из соседнего проекта?Прикинуть по денежке, может ещё есть возможность прикупить стопитсот индусов?
Низкий приоритет подождетПрикинуть по времени, что есть, а что реально надо прикрывать?Прикинуть, а не пора ли сразу просить людей у Толика из соседнего проекта?Прикинуть по денежке, может ещё есть возможность прикупить стопитсот индусов?
Низкий приоритет подождетПрикинуть по времени, что есть, а что реально надо прикрывать?Прикинуть, а не пора ли сразу просить людей у Толика из соседнего проекта?Прикинуть по денежке, может ещё есть возможность прикупить стопитсот индусов?
Низкий приоритет подождетПрикинуть по времени, что есть, а что реально надо прикрывать?Прикинуть, а не пора ли сразу просить людей у Толика из соседнего проекта?Прикинуть по денежке, может ещё есть возможность прикупить стопитсот индусов?
Серьезность. Насколько опасен отказ системы из-за какой-то части функционала? Приведет ли это к потере данных?Приоритет. На сколько силен будет эффект от отказа системы повлияет на пользователей и их лояльность продукту?Вероятность. Какова вероятность того, что пользователь таки воспользуется именно тем куском функционала, который не до конца работает?
Серьезность. Насколько опасен отказ системы из-за какой-то части функционала? Приведет ли это к потере данных?Приоритет. На сколько силен будет эффект от отказа системы повлияет на пользователей и их лояльность продукту?Вероятность. Какова вероятность того, что пользователь таки воспользуется именно тем куском функционала, который не до конца работает?
Серьезность. Насколько опасен отказ системы из-за какой-то части функционала? Приведет ли это к потере данных?Приоритет. На сколько силен будет эффект от отказа системы повлияет на пользователей и их лояльность продукту?Вероятность. Какова вероятность того, что пользователь таки воспользуется именно тем куском функционала, который не до конца работает?
Вдруг повезет
Вдруг повезет
Вдруг повезет
Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
Мой любимый. Маленькие проектики. Тут можно попробовать принимать решение на себя.По категориям выше прикинули, какие реально могут стерьнуть. Вполне вероятно, что будут не все.Сгенерили ситуации. Ну например: для функционала: нет возможности отправит письмо в почтовом клиентеСамым примитивным образом – от одного до 3-х. Можно даже упросить или 1 или 2. Тот, что больше – тот важнееПобегали по конторе, потрясли проектных и околопроектных людей. Внесли коррективыУаля. Имеем план работ по тестированию с указанием коэфициента прикладываемых усилий.
Метод достаточно сложный, основан на определении потенциальных проблем, оценки их влияния, а затем выполнении классификации по серьезности, приоритетности и вероятности возникновения дефекта.В классическом исполнении предполагается оценка потенциальных ошибок по четырем критериям: серьезность, вероятность, приоритетность и обнаружаемость, причем каждый критерий может варьироваться в различных диапазонах для увеличения или уменьшения точности. Таким образом, вероятность может оцениваться по шкале начинающейся с 1 (наибольшая вероятность) и заканчивающейся Х (наименьшая вероятность). Промежуточные значения и их количество определяются исходя из требуемой точности для конкретного проекта. В итоге получается для каждого типа ошибок четыре числовых значения. Их произведение дает приоритет риска, который может принимать значение от 1 до Y. После этого определяются рекомендуемые действия по снижению рисков. Общая шкала значений делится на количество выделенных категорий, в результате каждой ошибке сопоставляется то или иное действие для уменьшения её эффекта. В общем это не для слабонервных, а в условиях, когда надо занижать, а не увеличивать, вообще может не подойти.
На этом месте обычно слайд «Вопросы», но из-за него никогда не получается срисовать контакты выступающего. Поэтому я его упразднил. Большое спасибо за внимание, перезжайте аккуратно, и да прибудет с вами сила! Вопросы
