Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 4540 сообщений
Cообщения с меткой

тестирование - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Проектирование сайтов для людей с деменцией

Вторник, 28 Июня 2016 г. 10:56 (ссылка)

Статья была опубликована на smashingmagazine и была переведенна специально для Хабрахабра.



image



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



Звучит довольно просто, не так ли? А теперь давайте рассмотрим это вот с какой точки зрения… Число интернет-пользователей, страдающих деменцией во всем мире постоянно растет. У них могут быть разные уровни компьютерной грамотности, они могут испытывать следующие проблемы: потеря памяти, спутанность сознания, проблемы, связанные со зрением и восприятием, трудности с упорядочиванием и обработкой информации, речевые проблемы, неспособность решать некоторые проблемы и задачи.



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



Разработка веб-сайтов для людей, страдающих от деменции, до сих пор была относительна неисследованной темой в мире веб-дизайна. Тем не менее, нам в On Our Radar пришлось столкнуться с проблемой удобства дизайна для людей с деменцией в прошлом году при создании «Дневников деменции»: проекта, который должен поощрить людей, страдающих деменцией вести аудио-дневники своей жизни, достижений и проблем, с помощью специального мобильного телефона, напечатанного на 3D-принтере. Коллекция аудио-историй выложена на сайте, их отбирают для медиа-кампаний в СМИ, или используют в службах и организациях, которые работают с людьми, страдающими деменцией.



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



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



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



Что такое деменция?



Слово «деменция» описывает набор симптомов, которые могут включать в себя потерю памяти и трудности в обработке информации, трудности с решением проблем или трудности в общении. Деменция возникает из-за повреждения мозга болезнью (например, болезнь Альцгеймера) или в результате травм. Деменция прогрессирует, и с течением времени симптомы постепенно усиливаются. К менее известным симптомам относятся галлюцинации, сенсорные нарушения, бессонница и перепады настроения.



По некоторым оценкам, в конце 2015 года во всем мире насчитывалось около 46,8 миллиона человек, страдающих деменцией. Число людей с деменцией будет расти почти в два раза каждые 20 лет и достигнет 74,7 миллиона к 2030 году, 131,5 млн. — в 2050 г. Таких интернет-пользователей 3,3 млрд. по всему миру, и поскольку количество людей, страдающих деменцией, продолжает увеличиваться, будет расти и процент пользователей с этой болезнью.



Новые рубежи проектирования сайтов для людей с деменцией



Почему это важно?



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



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



Многие веб-сайты предоставляют услуги, продукты или информацию для людей с деменцией, но они неэффективны, поскольку разработаны без учета особенностей пользователей этой группы. Другие люди могут (и часто это делают) помочь людям с деменцией получить доступ к этой информации, хотя это и снижает независимость людей с деменцией, но все же остается важным фактором для поддержания эмоционального благополучия.



Социальные сети



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



image



Томми Данн, человек с деменцией из Ливерпуля, Великобритания.



Основные особенности сайта для людей с деменцией



Содержание



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



Ключевые моменты



• Все должно быть четко и точно: для чего нужен ваш сайт и почему вы это делаете? Избегайте сложной словесной игры, призывов к действию (например, «Примите участие»).



• Контент должен быть понятным и привлекающим внимание.



• Функция печати контента пригодится людям, у которых проблемы со зрением и восприятием.



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



• Избегайте жаргона, слишком технического или научного языка.



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



Их словами



«Когда у вас деменция, довольно трудно сосредотачиваться на вещах длительный период времени, особенно если вы просто сидите там».



-Пол Хичмау



«Читать не трудно, в этом нет никакой сложности. Запомнить то, что вы прочитали – вот это уже проблема. Тяжело вспоминать прочитанные книги, даже вспомнить название книги… Иногда я беру в руки книгу, и не могу вспомнить, читал я ее или нет».



-Кит Оливер



image



При нажатии на большую кнопку «печать», пользователю открывается таблица стилей для печати. (Изображение взято с: Дневники деменции)



Макет, Навигация И Графический интерфейс



Сделайте вашу навигацию явной и четко обозначьте путь обратно на главную страницу.



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



Пять лет назад в исследованиях Pew Internet и American Life Project выяснилось, что пожилые пользователи, страдающие хроническими заболеваниями, чаще, чем их сверстники, принимают участие в онлайн-дискуссиях и ищут новые сообщества. Принимая во внимание тот факт, что Facebook – самая популярная социальная сеть для людей, старше 50 лет, вы, возможно, захотите максимально упростить возможность поделиться своим контентом в этой сети. Сделайте кнопки большими и заметными.



Ключевые моменты



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



• Сделайте «хлебные крошки» заметными, так чтобы можно было легко перемещаться вперед и назад.



• Не используйте меню-гамбургер, функции типа «Смотреть меню» и «Закрыть меню».



• Используйте кнопку «Home». Не полагайтесь на использование логотипа для возврата к домашней странице.



• Убедитесь, что гиперссылки четко видны.



• Используйте понятные кнопки для обмена контентом, достаточно большие, чтобы их можно было различить на планшетах.



• Используйте четкие разрывы строк. Точно определите участки с важными предложениями и заголовками так, чтобы разрыв был очевиден.



• Вносите изменения постепенно. Если что-то работает, не меняйте этот элемент без надобности.



image



При нажатии на кнопку «Задать вопрос Элейн Стефенсон» (см. с левой стороны), ниже на том же экране что и сама история, появится окно вопроса, (см. с правой стороны), так что человек, задающий вопрос, сможет легко просмотреть оригинальную историю. (Изображения взято с: Дневники деменции)



image



Мы не использовали меню-гамбургер и попытались сделать заголовки меню максимально простыми. (Изображения взято с: Дневники деменции)



И х словами



«Я уже почти не могу отслеживать последовательность действий… я живу одна, и для меня это довольно сложная задача.»



— Агнес Хьюстон



«Приходится все упрощать. В голове все путается. Нужно делать все постепенн. Читать медленно».



— Арчи Латта



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



— Энн Макдональд



Цвета и контраст



Деменция может проявляться в виде трудностей со зрительно-перцептивным восприятием (проблемы, которые влияют и на зрение и на восприятие) или проблем с сенсорикой. Специфические трудности, которые испытывает человек, будут зависеть от типа деменции. Это происходит потому, что каждый тип деменции может по-разному отражаться на зрительном восприятии.



К таким трудностям относятся:



· Снижение чувствительности в различении контраста (в том числе цветовой контраст, например черно-белый, контраст между объектами и фоном).



· Снижение способности улавливать движение (перемещения).



· Изменения в поле зрения (насколько хорошо вы видите объекты по краям поля зрения, глядя прямо перед собой).



· Снижение способности обнаруживать различные цвета (например, у человека могут возникнуть проблемы с описанием разницы между синим и фиолетовым).



· Изменения в реакции зрачка на свет.



· Проблемы направления или смещения взгляда.



Поэтому при выборе соотношения цвета и контраста важно следовать инструкциям Руководства по обеспечению доступности веб-контента (РДВК).



Ключевые моменты



· Используйте цветовую схему с высоким уровнем контрастности, чтобы сделать страницы более читабельными.



· Предложенные коэффициенты РДВК для контраста — 7:1 и 4,5:1. В связи с тем, что наш сайт предназначен для людей, страдающих деменцией, мы вышли за рамки этих рекомендаций.



· Публикуйте текст без наложения на изображения.



· Используйте простой фон, который не будет отвлекать внимание пользователей.



image



1) Синий цвет темы с белым текстом: коэффициент контрастности — 7.4:1



2) Черный текст на белом фоне: коэффициент контрастности – 9,45: 1.



3) Названия каждой части расположены под изображением, и не перекрывается им. Вы можете нажать на название или на картинку, чтобы перейти к посту. (Изображение взято из: Дневники деменции)



Их словами



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



— Агнес Хьюстон



Важно отметить, что высокий контраст может также быть проблемой для некоторых людей, страдающих деменцией, которая влияет и на состояние глаз. Симптомы деменции разнообразны и, к сожалению, не всегда можно учесть потребности каждого. Тем не менее, высокая контрастность является хорошей отправной точкой, и с помощью настраиваемых коэффициентов контрастности веб-сайта, вы можете попытаться обеспечить доступность для максимального количества людей. Общество Альцгеймера предлагает наиболее полный набор настраиваемых параметров доступности (текст, шрифт и расстояние между буквами – настраиваемые).



Текст и шрифты



Текст должен быть понятным и простым!



Sans serif – тип шрифтов с небольшими выступающими черточками (так называемыми засечками) в конце росчерка. Современный, минималистичный, широко используется в Интернете, в частности, для коротких и броских сообщений. Он не так выразителен с визуальной точки зрения, но простота буквенных форм sans serif делает его хорошо читаемым на любом устройстве.



Если сообщение, адресованное людям с деменцией, оформить с помощью sans serif, им в целом будет легче понять его. Возможность изменения размера шрифта – очень удобная функция, если, конечно, ваш бюджет позволяет ее применять.



Люди, страдающие деменцией склонны забывать имена, события, даты и другие важные бытовые вещи. Именно поэтому нужно помнить, что такие люди могут не распознавать часто используемые аббревиатуры и акронимы. Даже если вы отдельно писали о чем-то ранее, человек, читающий новый пост, может об этом и не помнить, даже если эта информация уже встречалась несколькими строками выше.



Ключевые моменты



· Не используйте аббревиатуры и акронимы.



· Используйте шрифт большого размера, или предоставьте читателям возможность менять размер шрифта.



· Используйте шрифт sans serif. Мы используем Source Sans Pro (шрифт в открытом доступе, отлично подходит для разных пользовательских интерфейсов).



· Используйте жирный текст вместе с краткими и точными предложениями, выделяйте важную информацию.



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



Их словами



«Если вы любите читать книги, но у вас возникают трудности, используйте Kindle – так вы можете выбрать оптимальный для себя шрифт. Это облегчает чтение».



— Джо Беннет



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



-Томми Данн



image



Пример изменения размера шрифта, (маленький), на сайте dementiadiaries.org. Функция изменения размера шрифта находится в правом верхнем углу сайта. (Изображение взято с: Дневники деменции)



image



Пример изменения размера шрифта (большой), на сайте dementiadiaries.org. Функция изменения размера шрифта находится в правом верхнем углу сайта. (Изображение взято с: Дневники деменции)



Изображения



Здесь есть определенное противоречие. Изображения увеличивают вероятность того, что таким постом поделятся, добавляют красок вашему сайту, рассказывают историю. Но они могут также дезориентировать и отвлекать людей с деменцией. Они могут неправильно расценивать месторасположение людей или объектов, несмотря на то, что объекты находятся перед людьми: такая визуальная информация может отвлекать (например, фигурные обои), в ней может быть нарушен цветовой контраст. Люди могут также неправильно истолковать свои мысли: они могут начать видеть грабителей, или отказываться идти в ванную, потому что в их воспоминаниях будут эти образы. В некоторых случаях, люди с деменцией, путают изображения на экране телевизора с реальными людьми. Многие из этих проблем связаны с неспособностью последовательно распознавать объекты, лица и цвета.



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

Ключевые моменты



· Изображения должны быть актуальными, тесно связанными с текстом.



· Старайтесь избегать чрезмерно абстрактных иллюстраций.



· Убедитесь в том, что фотографии вносят что-то в основную историю, а не отвлекают от нее.



image



Отображается фото человека, пока его голос звучит на аудио. Материал сопровождается расшифровкой и соответствует рекомендациям по доступности веб-контента. (Изображение взято из: Дневники деменции)



Их словами



«Нам особенно понравились маленькие фотографии и иллюстрации, ясно объясняющие процесс; так текст гораздо проще понять».



— Кэрол Форс, жена и сиделка Криса Форса



Использование мультимедиа



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



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

Ключевые моменты



· Используйте автозапуск на странице, где аудио или видео является единственным центром фокусировки внимания, но не на странице перехода, так как это может шокировать или удивить пользователя.



· Видео или аудио-контент сопровождайте, по возможности, субтитрами или расшифровкой



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



image



Звук загружается с помощью SoundCloud, но мы также используем другой аудио-плеер, он проще. (Изображение взято из: Дневники деменции)



Их словами



«Фоновые шумы… могут затруднить восприятие. У меня очень острый слух, на грани болевого порога. Почему в обществе нас «засыпают» громкими навязчивыми звуками? Просто мысли вслух. Это не значит, что мне не нравятся громкие звуки, но они мешают, когда из-за них я не могу думать и не могу их регулировать. Я могу даже отшатнуться в сторону. Звук заполоняет весь мой мозг, и я не знаю, что мне делать».



— Агнес Хьюстон



«Музыка, кажется, доходит до тех частей поврежденного мозга, до которых не доходят другие формы коммуникации».



— Томми Данн



Личный контакт



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



Поскольку наш проект основан на аудио, мы разработали удаленный инструмент транскрипции, который позволяет волонтерам транскрибировать аудио-рассказы, представленные людьми, страдающими деменцией. Эта задача требует крайней сосредоточенности, и с помощью простого пользовательского интерфейса люди с деменцией, могут сделать это сами. Важно отметить, что мы предоставляем обратную связь всем, кто участвует в проекте. Мы делаем это лично по электронной почте (она запрашивается при загрузке расшифровки). Мы также отмечаем преданных удаленных волонтеров и публично благодарим их за поддержку проекта.



Ключевые моменты



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



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



image



Пример звукового отчета, который был удаленно расшифрован одним из добровольцев. Обратите внимание на короткое «спасибо» под расшифровкой. (Изображение взято из: Дневники деменции)

Их словами



«Я не говорю сходу, что страдаю деменцией; Я говорю, что позову к телефону кого-то другого. Если я очень расстроен, то говорю: „Извините, у меня деменция, вы не могли бы говорить со мной немного медленнее, тогда я попытаюсь все вам объяснить. Мы же говорим не о ракетостроении. Я не глуп. И тогда они отвечают: «О, мне очень жаль слышать это».



— Кэрол Овенстоун



“Если есть возможность поговорить лично, например, с помощью Skype, стоит ею воспользоваться. Людям может помочь язык тела. Они будут видеть, что я все еще на связи, и пытаюсь выразить свои мысли, им не надо будет все время подсказывать, так как они будут видеть, что я пытаюсь ответить. По телефону я чувствую необходимость дать быстрый ответ, так что я, скорее всего, просто соглашусь, или скажу что-нибудь, неважно правильно это или нет – просто даю ответ и пытаюсь поскорее закончить разговор».



— Крис Форс



Сомневаетесь – спросите link



Это, пожалуй, самое главное.



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



Ключевые моменты



· Включайте в работу над проектированием людей, страдающих деменцией.



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



· Не делайте предположений о поведении и возможностях пользователя. Попробуйте найти более приемлемое решение.



Их словами



«Те из нас, кто страдает деменцией – эксперты в понимании собственных условий жизни, у нас есть ценная информация, которой мы можем поделиться. Важно вовлечь нас на ранней стадии проектирования, чтобы понять, что является правильным для каждого из нас… Вокруг много гаджетов. Если вы будете терпеливы и поможете мне, я готова пробовать новые вещи. Мы не кусаемся! „



— Энн Макдональд



Выводы



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



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

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304256/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Как повысить конверсию в екоммерс, используя опросы на выходе

Понедельник, 27 Июня 2016 г. 13:47 (ссылка)

image



Если вы владелец бизнеса е-коммерс, и хотите увеличить конверсию и прибыль, то вы пришли по адресу. В этой статье вы узнаете, как увеличить конверсию с помощью проверенного процесса оптимизации под названием «Exit intent technology» или если по русски «Опрос на выходе».





Как увеличить конверсию и продажи



Самый простой способ – это разбить оптимизацию екоммерс на два этапа:



Этап 1: Узнайте, из какого конкретно раздела ваши посетители покидают сайт



Этап 2: Узнайте, почему ваши посетители покидают сайт и измените это



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



Этап 1 — это информация о цифрах или, как это формально называется, информация о количественных данных. На что именно люди кликают мышкой, находясь на сайте, на какие страницы они переходят и с каких покидают ваш сайт. В качестве примера источника количественных данных может служить ваш аккаунт в Google Analytics.



Этап 2 — это о поведении посетителей сайта, так называемые, качественные данные. Почему польхователи покидают сайт со страницы корзины, почему они не понимают ваших описаний продукта и так далее. Примеры качественных данных – это тестирование пользователями, интервью с клиентами, опросы клиентов или принудительный опрос на выходе из сайта.



Каким образом опрос на выходе вписывается в полный процесс оптимизации конверсии





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



image



Вот общая картина данного процесса:



Шаг 1: Цели бизнеса



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



Шаг 2: Сбор данных



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



Шаг 3: Анализ данных



Третьим шагом является анализ данных, понимание того, что значат эти данные.



Шаг 4: Проверка гипотезы



Четвертый шаг предлагает идею сопоставить ваш сайт с вашими данными. «Гипотеза» исходит из того, что сопоставление и тестирование это наука, а на самом деле это статистика.



При проверке изменений веб-сайта, которые вы пытаетесь подтвердить свои статистические гипотезы и заработать больше денег.



Шаг 5 и 6: Разработка и построение



Пятый шаг заключается в разработке и кодировании новых изменений веб-сайта, которые вы собираетесь тестировать.



Шаг 7: А/В Тестирование



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



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



Шаг 8: Итерация



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



Теперь давайте погрузимся в то, как использовать информацию по опросам на выход для роста электронной коммерции.



Гид по повышению конверсий в е-коммерс с помощью опросов на выходе



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



Шаг 1: Найти, откуда посетители покидают сайт


Самый простой способ узнать, с каких страниц вашего сайта уходят посетители – это просмотр отчета по страницам выхода в Google Analytics.

Чтобы проиллюстрировать эту технику, мы рассмотрим социологическое исследование для ByCharlotte( ювелирная компания из Австралии).



image



Войдите в ваш аккаунт Google Analytics и перейдите к вкладке: Поведение > Контент сайта> Страница выхода



image



Затем отфильтруйте отчеты и удалите страницы с низким трафиком, без трафика и со слишком высоким трафиком. Подтвердите эти изменения и следуйте отфильтрованным установкам.



image



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



image



Шаг 2: Установите принудительный опрос на выход




Итак, сейчас вы видите, с каких страниц уходят посетители сайта, теперь необходимо понять, по какой же причине это происходит.



В данном конкретном примере мы используем приложение Hotjar. (Другие приложения — Foresee, Usabilla, Qualaroo). Устанавливаем софт, регистрируемся, входим в личный кабинет устанавливаем код отслеживания на ваш сайт интернет-магазина.



image



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



Если вы используете Shopify, он находится в theme.liquid файле.



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



Перейдите в меню «Опросы» и нажмите на кнопку «Новый опрос».



image



Дайте название вашему опросу и напишите благодарственное сообщение. В нашем примере мы собираемся спросить наших посетителей сайта: Что вас останавливает от сегодняшней покупки?



image



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



image



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



image



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



Что такое опрос на выходе?



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



image



Наконец, переведите опрос в стадию «Активный» и приступайте к сбору данных.



Шаг 3: Проанализируйте данные вашего опроса


Есть три способа для анализа качественных данных. Имейте в виду, что когда речь идет о качественных данных, анализ занимает много времени. Первый способ – изобразить с помощью картинки, т.е., принимая все ответы по опросам на выходе с сайта, ваш клиент превращает все слова, относящиеся к проблемной зоне, например, в облако из слов.



image



В нашем примере выше опросы на выходе были сосредоточены на доставке.



Второй способ заключается в рассмотрении всех данных и принятии во внимание основных мыслей посетителей. На чем были сосредоточены люди во время опроса – на одном явном большом недостатке или на одной правильной цели? Цель здесь заключается в обобщении каждой точки данных в одно или два предложения.



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



Третий способ — это о количественной оценке ваших качественных данных путем размещения данных по категориям. Это позволяет определить, сколько людей были сосредоточены на крупном недостатке на странице или на верной цели. В нашем случае 21 из 32 посетителей были сосредоточены на доставке.



Шаг 4: A / B тестирование изменений в вашем интернет-магазине




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



Вот первоначальный дизайн странички корзины:



image



И обновленный дизайн страницы:



image



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



Важно проводить A / B тестирования, чтобы убедиться, что ваш новый дизайн действительно улучшает качество обслуживания клиентов и увеличивает прибыль.



Мы добавили новую информацию о доставке, но в то же время мы обновили дизайн темы магазина, поэтому мы не можем приписать подъем конверсии на 20% только к первым изменениям.



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



Запустите рост вашего интернет-магазина



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



Подписывайтесь на наш блог, дальше будет много всего интересного.

Кстати, мы занимаемся комплексным обслуживанием интернет магазинов, может нужно кому? :-)



С уважением команда фулфилмент-оператора «Ямбокс»

(Ямбокс — превращаем ваш интернет магазин в компьютерную игру)




image

Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304200/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Учимся на ошибках в организации контроля качества

Пятница, 24 Июня 2016 г. 15:13 (ссылка)

Привет, Хабр! Меня зовут Илья Кудинов, и я работаю QA-инженером в компании Badoo. Три года назад я начал посещать различные IT-конференции и рассказывать о процессах и технологиях, применяемых нами при контроле качества. И конечно же, после каждого доклада я общался со слушателями, интересовался, как работают они. В этом деле меня всегда мотивировали отзывы вида «Раньше мы работали вот так, но, послушав твой доклад, мы увидели, как можно сделать лучше», а еще лучше — когда люди не копируют наши приемы, а придумывают что-то сами, иногда даже более интересные варианты. Таких историй у меня накопилось много, и я хочу поделиться с вами некоторыми из них (все имена и названия вымышлены, любые совпадения с реальными лицами являются случайностью). Может быть, что-то из этого поможет вам увидеть направление развития вашего собственного проекта — и это будет самой большой наградой для меня! Разумеется, буду рад после этого выслушать и ваши истории — в комментариях или личных сообщениях.



Прежде всего давайте оговорим два момента.

Первое: не для всех видов и масштабов разработки советы из этой статьи окажутся подходящими (для некоторых, я уверен, они будут даже очень вредными), поэтому для представителей разработчиков софта самолётов (а так же для тех гуру тестирования, кому мои советы кажутся очевидными) этот рассказ будет просто занимательным чтивом. Я в первую очередь ориентируюсь на быстроразвивающиеся продукты с плотным графиком релизов. Интереснее всего будет представителям тех компаний, где QA-отдел существует только в зародыше или пока не существует вообще.

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



Визуализации мыслей и идей будут помогать вот эти три товарища, знакомьтесь:





Итак, давайте начнем с того, что определимся, кто же мы, собственно такие. QA-инженеры? Тестировщики? Тестеры?

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

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

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



Впрочем, с целью упрощения речи, «тестировщик» тоже сойдет, но только если вы говорите это с должным уважением.



Я гордо говорю, что я QA-инженер. Моя работа (и работа моих коллег как по компании, так и по сфере вообще) направлена на обеспечение максимально достижимого качества продукта — на то, в чем в любом случае заинтересованы все остальные участвующие в проекте стороны. Именно поэтому мне очень жаль, что во многих компаниях мои собратья зачастую рассматриваются как сугубо вспомогательный персонал, роль которого в проекте самая незначительная (уборщики хотя бы грязные кружки из-под кофе убирают за разработчиками).



На самом деле роль тестировщика в проекте в конечном счете является ничуть не менее важной, чем роль разработчика. Бьёрн Страуструп (дат. Bjarne Stroustrup) в своей книге «Язык программирования C++» писал: «Программа, которая не прошла тестирование, не работает». Зачем вам нужны программисты, продукты которых никогда не будут работать? Тестировщик — не раб разработчика, великодушно выдающего задачи типа «проверь, пока я раскладываю на прод». Наоборот, разработчик и тестировщик совместными усилиями достигают поставленной цели — выпустить продукт к назначенному сроку в максимально высоком качестве. Именно для этого и создается отдел контроля качества. Но… как его организовать?




QA-отдел



Итак, компания «ФОЛИАНТ ЛИЦ» решила заниматься разработкой программного обеспечения. Она подошла к этому делу основательно, даже отважилась на создание QA-отдела! Сколько нужно набрать туда людей, если у нас уже есть 12 разработчиков? Классический подход подсказывает, что приблизительное соотношение рабочей силы должно быть таким: 1 QA-инженер на 3-4 разработчиков. Сказано — сделано! Нанимаем трех инженеров и считаем себя большими молодцами.

Проект начинает развиваться, к QA-отделу предъявляются все новые и новые требования. Вот мы уже достаточно повзрослели, чтобы производить релизы не просто выкладкой gzip-архива на продакшен, а путем хорошо построенного и налаженного деплой-процесса. Кто будет этим заниматься? Отдадим это нашему специалисту в отдел контроля качества!

Функционала становится все больше — тестировать регрессию все сложнее. Один из наших тестировщиков имеет опыт разработки? Отлично! Пусть он теперь занимается разработкой автотестов! Хорошо мы придумали, да?

Что мы получили в итоге такого замечательного плана? Тестированием задач наших двенадцати разработчиков постоянно теперь занимается только один из QA-инженеров. Интересно, почему очередь на тестирование начала расти и наши отлично организованные релизы регулярно задерживаются?



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




Смотрите, другая маленькая компания — «ЩЕБЕТАЛКА»! И у нее очень большие и серьезные планы. Начинают они с малого: четыре разработчика, пара менеджеров и один (очень гордый) тестировщик. Время проходит, бизнес идет в гору, количество заказов на разработку все увеличивается и увеличивается. Счастливые и довольные результатом руководители проекта объявляют расширение штата. Для начала наймем еще одного продакт-менеджера, пусть генерирует больше взрывных идей. Запросов на новые фичи становится все больше? Срочно набираем новых разработчиков!

Ого, больше пользователей? Больше прибыли? Ребята, мы идем верной дорогой — нанимаем еще разработчиков, пусть засыпят наш проект фичами! Как же это все здорово! Но что же это? Почему стало больше багов? Почему пользователи недовольны? Мы ведь наняли больше людей, почему мы отстаем от графиков? Ах, наш несчастный тестировщик, мы совсем про него забыли!



Урок: отдел контроля качества стоит развивать параллельно отделу разработки. Возможно, даже с опережением. Сложно бороться с конкурентами и доставлять пользователям новаторский функционал, если вы не можете обеспечить проекту должное качество.




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

Завершив работу над задачей, разработчик со всей злостью, доступной при нажатии на кнопку Assign в Jira, кидает задачку на тестирование. Тестировщик недоверчиво смотрит на задачку, с отвращением открывает ее и спустя несколько секунд с достойной зависти яростью возвращает задачу на доработку с пояснением: «У вас опечатка в комментарии!» Казалось бы, при таком рвении к работе качество должно быть на высоте. Наверное, оно там и есть. Но мы этого никогда не узнаем, потому что при таком подходе задача доберется до продакшена примерно… никогда.



Урок: отделы тестирования и разработки — не враги друг другу. Они не должны сидеть по разные стороны укрепрайонов, стараясь при первой же возможности свалить работу друг на друга. Как я уже говорил, их совместная цель — релиз задачи в поставленный срок, и их обязанностью является объединение усилий для достижения этой цели. Это вовсе не значит, что нужно закрывать глаза на ошибки: просто после обнаружения незначительного дефекта не обязательно сразу же отправлять задачу на доработку, вполне можно записать ее в сторонку, проверить, насколько это возможно, и отправить уже с полным списком ошибок, чтобы сэкономить горы времени на постоянно повторяющихся этапах разработки и тестирования.



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




QA-процесс



И вот QA-отдел организован. Чем он будет заниматься? Правильно, контролем качества. Но как это процесс будет устроен?



Любые QA-процессы всегда строятся вокруг балансирования между качеством и скоростью. Абсолютное качество недостижимо (если вы со мной будете спорить — надеюсь, вы разрабатываете самолеты), тестировать задачи мгновенно тоже невозможно. Где же найти это равновесие? Здесь каждая команда может придумать свое решение. Для кого-то это Continious Integration, кто-то отдает предпочтение строго регламентированным и спланированным релизам — и нельзя просто подсмотреть процессы, поставленные вашими соседями по гаражу.



Как QA-процессы встраиваются в процессы развития проекта? Давайте поделим их на три этапа: продакт-дизайн, разработка и тестирование. Два молодых стартапа подошли к этому вопросу совершенно по-разному: компания «БОДУНЫ» плотно связала QA-инженеров с каждым из них, а «ПОЧТИ.РУ» оставила им только тестирование. Кто из них прав? Как говорится, истина может быть где-то посередине.

Что мы получаем с каждым новым этапом QA-процесса? Качество. Что мы при этом теряем? Скорость. Какими же этапами контроля качества можно жертвовать?



Тестированием? НЕТ.



Контролем качества при разработке? Звучит важно. Нет, конечно не нужно чтобы тестировщик сидел за плечом у разработчика и больно щипал его каждый раз, когда тот забывает поставить точку с запятой. Есть много других способов помочь разработчикам соблюдать определенный уровень качества. Удачно настроенная система контроля версий, различные хуки и скрипты для проверки корректности кода, написание юнит-тестов (здесь, правда, QA может выступать только в роли надзирателя с кнутом и пряником), удобная система code review — все это в области ответственности отдела контроля качества.



Контролем продакт-дизайна? Ну… В «промышленной» разработке существует целое направление контроля качества — тестирование и анализ ТЗ. Это помогает избежать логических и архитектурных ошибок на начальных этапах развития каждого проекта — и катастрофически отдаляет возможность начала разработки.

Наверное, в молодом стартапе это излишние предосторожности. Высокая интеграция различных отделов друг с другом позволит всем участникам проекта (и разработчикам, и тестировщикам) увидеть подробности проекта, определить шероховатости и донести до менеджмента полезные (и не очень) идеи. К тому же, в нашем мире динамичных проектов и Agile-методологий ТЗ зачастую изменяется уже во время разработки (и даже после релиза, в конце концов), так что имеет смысл позволить продакт-менеджерам выражать себя бесконтрольно и уже потом вносить свои предложения и поправки.



Урок: контроль качества на каждом этапе развития проекта положительно влияет на качество и катастрофически понижает скорость. Нужно строить процессы так, чтобы они соответствовали требованиям к вашему проекту, и не копировать бездумно чужие практики и статьи из книжек (и из Хабра, да-да).




Смотрите, разработчик компании «БУБЛ» отдал свою задачу на тестирование и абсолютно уверен, что увидит ее снова только в случае возврата на доработку. И что же, в этапе тестирования участвуют только QA-инженеры? Вовсе не обязательно. Конечно, при обнаружении каждой неясности можно сразу же возвращать задачку, но это вполне может оказаться обычным недопониманием, а задача при этом повиснет в каких-то промежуточных статусах. Поэтому (и не только поэтому, конечно) общение и взаимодействие в процессе тестирования — бесценно. В случае обнаружения странных и непонятных моментов всегда можно сесть вместе с разработчиком и попробовать разобраться. С одной стороны, если это поведение ошибкой не является, то можно разобраться в алгоритме и избежать всех задержек с переходом статуса. А если это оказывается неожиданной ошибкой, то подобное изучение может помочь разработчику решить проблему с ходу, а не добраться до переоткрытой задачи спустя несколько дней и пытаться с нуля сообразить, что же там происходило.



Урок: не стоит возвращать задачку при первом же непонятном моменте. Совместный с разработчиком дебаг — не только полезный и эффективный процесс, но и зачастую поучительное (оба участника могут глубже вникнуть в происходящее) и веселое занятие.




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

А вот у их отдела контроля качества все давно не так безоблачно. Исторически сложилось так, что релизы на тестирование отправлялись им в качестве архивов, вложенных в почту. Ну, кто-то когда-то так придумал, и все привыкли. Они пишут свою документацию на бессчетных бумажках, разбросанных по всему отделу (некоторые особо хитрые инженеры завели самый настоящий совместный Google Doc, но очень боятся, что их рано или поздно поймают и заставят все переписать на бумажки). Очень жаль, что никто не может проявить инициативу и попробовать объединить используемые технические средства!

Ведь можно было бы использовать общие репозитории, общие базы знаний, интегрировать друг в друга системы баг-трекинга, сборки приложений и сделать все таким красивым, автоматизированным и целостным… Но нет, к сожалению, разработчикам пришлось бы для этого отвыкать от привычного flow и даже (!) разрабатывать и настраивать что-то новое. Но нет, письмами как-то сподручнее…



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




Тестировщики компании «КРУПНОЖЕСТЬ» всегда работают по строгим тест-кейсам. Запрещена любая свобода действий — и не дай бог кто-то позволит себе пропустить хоть один пункт в тест-плане! Отсутствующая галочка в чек-листе равносильна преступлению и карается чтением «Войны и Мира» вслух перед всем отделом. Отдельные инженеры целыми днями занимались исключительно поддержкой этой документации, а каждый тестировщик был обязан составлять кейсы для каждого затронутого им функционала. Конечно, качество было на высоте! Поначалу… Выяснилось, что на продакшене начали появляться баги. Баги на продакшене, Карл! При проверке чек-листов выяснилось, что этот функционал проверялся, и ответственный тестировщик с самым невинным видом активно кивает головой: проверял, проверял! А затем выяснилось, что некоторые компоненты продукта не проверялись уже годами просто потому, что они не нашли себе места в тест-документах. Руководителя отдела заставили писать отчет и объяснительную относительно происходящего в четырех томах с оглавлением.

Наверное, было бы лучше, если бы тестировщики при работе думали своей головой, а не следовали строгим инструкциям. Имели бы общий источник информации, но не в виде «Что делать», а в виде «Как это работает». Конечно, это может отрицательно повлиять на скорость тестирования, ведь каждый раз будет необходимо исследовать фичу или (не дай бог!) общаться с другими тестировщиками и (!) разработчиками, чтобы понять, что надо бы тут проверять.



Урок: общая документация, позволяющая определить, что стоит тестировать в той или иной задаче — хорошо. Подробные инструкции и кейсы… наверное, не очень. (разработчики самолетов — забудьте, что сейчас прочитали. ПОЖАЛУЙСТА!)




В компании «ПРИНТЕЛ» очень ценят разделение труда. Каждый тестировщик привязан к тому или иному функционалу и компоненту — и он прекрасно знает, что и как имеет смысл в нем тестировать. Качество и скорость на высоте, компания идет к успеху. А потом один из QA-инженеров выигрывает в лотерею и уезжает жить на Канары. Оставшиеся переглянулись и попробовали разобраться в том, что он за собой оставил. Никто ничего не понял, и тестировали кое-как, пока не был найден новый инженер на место счастливчика. Все вздохнули от облегчения…Пока не выяснилось, что в мечтах уехавший был врачом и все его записи велись немного непонятным почерком. Разработка компонента встала почти целиком до тех пор, пока новичок не смог освоиться в нем с нуля.



Урок: имеет смысл иметь практику обмена знаниями внутри QA-отдела. Можно периодически обмениваться задачами, чтобы не привыкать к одному компоненту (одно из плохих последствий такой «специализации» — «замыливающийся» глаз), можно проводить внутренние семинары и лекции, на которых специалисты расскажут о новшествах в своей сфере ответственности, интересных кейсах и технологиях: это приведет не только к взаимозаменяемости специалистов, но профессиональному росту каждого из них.




QA-инженер компании «КРАБЫРАДЫ» наконец-то закончил работу над сложной системной задачей, на которую он потратил не один рабочий день. Он проследил за ее отправкой на продакшн, вздохнул свободно и отправился пить пиво с друзьями. Правильно ли он поступает? Я так не думаю.

Даже если у его компании есть серьезный отдел мониторинга, круглосуточно красными глазами наблюдающий за десятками и сотнями графиков и метрик, ему может потребоваться немало времени, чтобы локализовать внезапно возникшую из ниоткуда ошибку или падение активности. Вот было бы здорово, если бы кто-то мог им помочь или даже просто не допустить того, чтоб им пришлось искать причины этого беспорядка…

А ведь тот самый инженер мог выпить сегодня всего на одну пинту «Гиннеса» меньше, зато спасти немало человеко-часов (и, возможно, денег компании), если бы потратил какое-то время на изучение поведения продакшена после релиза. Изучить логи ошибок, проверить тренды тех графиков, которые описывают состояние затронутых в задаче компонентов. Да, иногда баги добираются до продакшена. Виной тому может быть человеческий фактор, различия в окружении или даже просто одна из тех миллионов user story, которые генерируют настоящие пользователи.



Урок: QA-процесс не прекращается сразу же после релиза задачи на продакшен. Всегда имеет смысл последить за поведением нового функционала, и крайне важно иметь инструменты, которые это позволяют.




Тестировщик компании «ЯБЛОЧКО» впервые в жизни пропустил на продакшен досадный баг. Наверное, он мог его обнаружить, если бы потратил на это еще пару часов, но это уже случилось. Баг починили, но он успел затронуть пользователей. Компания очень недовольна тестировщиком. Разработчик фичи недоволен тестировщиком. Он получает взыскание и лишается премии, чтобы неповадно было и в дальнейшем не щадил себя при тестировании. Правильно ли поступила компания? Я думаю, что нет.

QA-процессы не отменяют возможность появления дефектов — они направлены на понижение вероятности их возникновения. И в этих процессах участвуют все затронутые в проекте люди. И ответственность за дефекты в равной степени ложится на всех: на руководителя, который недостаточно замотивировал и обучил своих сотрудников; на разработчика, который допустил ошибку; на тестировщика, который эту ошибку пропустил. Даже на тех инженеров, которые покрывали этот функционал автотестами — ведь их тесты могли поймать этот баг, но не смогли! Стоит ли их наказывать? Возможно, но только при системных проколах. Гораздо полезнее будет провести глубокое изучение причин произошедшего, организовать образовательные семинары и все возможные мероприятия, для того чтобы понизить вероятность возникновения подобных дефектов в будущем.



Урок: в возникновении дефектов виноваты все участвующие в проекте стороны, не стоит обвинять в его возникновении только тестировщика.




Автоматизация



В компании «СЦОННИ» приняли решение начать разработку автоматизированных тестов. Один из тестировщиков имеет навыки программирования, и эту задачу отдали ему. Он писал тесты, был доволен своей работой и в какой-то момент покрыл тестами почти весь продукт. Все были рады, пока не заметили, что ушедшему в другой проект тестировщику не стали искать замену.

Событие превратилось в тенденцию, и QA-отдел начал таять. Когда перепуганные инженеры прибежали к руководству, то с улыбкой ответило: «У нас теперь такие замечательные автотесты, зачем нам скучные несовременные ручные тестировщики?» Объяснить им ничего не получилось, и все осталось на своих местах. Дела шли хорошо до тех пор, пока на продакшене не стало появляться все больше и больше ошибок, и все они — в самом новом, еще не покрытом тестами функционалом. Руководство осознало свою ошибку, но было уже слишком поздно… *громкая драматическая музыка*



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




А вот в компании «ШАНТСУНГ» такой проблемы не испытывали. Их отдел автоматизации тестирования был полностью отделен от отдела ручного тестирования. «Автоматизаторы» даже чувствовали себя представителями какой-то более высокой касты и снисходительно наблюдали за теми, кого они называли «ручниками». И было такое разделение, казалось, удобно всем, пока не стали возникать проблемы. «Автоматизаторы» стали так глубоко погружены в поддержку сотен своих тестов, что потеряли всякую возможность разрабатывать что-то новое (и соблюдать поставленные KPI, конечно), а «ручники» совершенно не представляли, что там происходит у их коллег, и перестали полагаться на тесты, проверяя вручную все то, что было тестами вполне покрыто (но про это никто не знал!), и это существенно уменьшило пользу от всего мероприятия.



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




Вместо послесловия



Надеюсь, что-то из того, о чем я многословно писал, окажется для вас полезным. Кому-то поможет найти шероховатости в процессах, другим подскажет выход из уже изучаемой проблемы. Даже если и не так, может, вы хотя бы посмеялись над тем, что я вам рассказал. Или хотя бы над моей наивностью. Главное — сделать мир лучше хоть в чем-то, хоть немножко. Правда?
Original source: habrahabr.ru.

https://habrahabr.ru/post/301764/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Тестирование. Ошибки при сертификации или ISTQB мне очень нужен

Пятница, 24 Июня 2016 г. 14:06 (ссылка)

Статья полезна тем, кому небезразлична их квалификация и хочется стать лучше. Учиться никогда не поздно.



Любой тестировщик рано или поздно задумывается о качестве не только в рабочем процессе, но и в отношении себя, качестве своего образования и способностей. В данный момент далеко не все вузы способны подготовить такого специалиста. Остаются всяческие курсы, как правило, дистанционные, чтобы была возможность поучиться у людей из этой же области, добившихся успеха. Но есть и ещё один способ самоутвердиться. Это сертификаты. Их много, перечислять, смысла нет. Но практически во всех областях они есть и их получение, скорее плюс, чем минус.



image



Мне бы хотелось написать о ISTQB, т.н. International Software Testing Qualifications Board. Это признанная во всём мире сертификация для тестировщика. Если ты такое получил, то по идее владеешь базовыми знаниями и теорией, то есть и плюсик тебе на собеседованиях добыть можешь, и в общем самоутверждаешься.



В статье я бы поговорила об ошибках. О глупых и не очень. О тех, которые я лично совершила в таком тесте или могла. И не хотела бы, чтобы кто-то тоже так попался.



Исчерпывающее тестирование



Хотелось бы для начала, чтобы запомнили следующее, “исчерпывающее тестирование невозможно, независимо от того, сколько усилий затрачено на тестирование (т.н. Принцип # 2)”. Этот принцип запомнить придется. Много ссылок на материалы для подготовки кидать не буду, одну приведу в конце статьи. Пункт, в котором засомневалась я, был “При достаточных усилиях и инструментальной поддержке исчерпывающее тестирование возможно для любого программного обеспечения". Первые мысли были о том, что терпение и труд всё перетрут. Это верно только для тривиальных ситуаций, в любой реальной системе предусмотреть все ситуации не сможем, остается только свести к минимуму количество проблем.



image



Стадии и задачи



Информация для запоминания. Основной процесс тестирования можно поделить на этапы, направления деятельности:




  • Планирование (Этап 1)

  • Анализ и проектирование (Этап 2)

  • Внедрение и реализация (Этап 3)

  • Оценка критериев выхода и создание отчетов (Этап 4)

  • Действия по завершению тестов (Этап 5)



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



Вопрос, с которым я столкнулась, по сути, был таким, какие задачи мы выполняем на этапе анализа и проектирования. Были разные варианты ответов.




  • Определение целей тестирования

  • Рецензирование базиса тестирования

  • Создание тестовых наборов из тестовых процедур

  • Анализ накопленного опыта для улучшения процесса



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



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



Итак, этап номер 1, планирование. На этом этапе самое важное определить цель тестирования и описать для себя (или лицу вышестоящему) задачи, которые эту цель помогут достичь. Тут и объём, и риски, и подходы, и люди. Этот этап так же включает ещё и управление тестированием. Мы не только план составили, но и на протяжении всего процесса следим, что он выполняется, задача за задачей. Таким образом, не только ставили задачи, но и занимаемся их мониторингом.



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



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



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



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



Тестирование в период сопровождения



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



Например, смена платформы. Что будет являться тестированием сопровождения? Все эксплуатационные тесты, тестирование изменений, стоит так же добавить в список планов регрессионное тестирование тех областей, которые при этом не были затронуты. При этом основная проблема — это границы области, которую стоит включить в тестирование. Если позволяет время и ресурсы, то стоит включить их все. Но на это времени хватает далеко не всегда. Поэтому для принятия решения придется оценить риск и соотношение размера системы к размеру внесенных изменений.



Системное и компонентное тестирование



Главное помнить, что компонентное тестирование обычно является ответственностью разработчиков, в то время как системное тестирование — типичная ответственность тестировщиков.



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



Противоположным тестированием является системное. Если в компонентном мы рассматривали каждую часть, как отдельную, то тут мы смотрим на систему, как на единый объект. При тестах применяем множество методов, и исследуем как функциональные, так и не функциональные требования. Тут уже подходят для исследования тестовые описания, варианты использования системы и прочие всевозможные способы поиска багов, но сама система рассматривается в виде “черного ящика” без доступа к коду.



Формальное рецензирование и его шаги



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



Основные фазы формального рецензирования — это планирование, старт, индивидуальная подготовка, изучение/оценка/запись результатов, повторная обработка, отслеживание. Этапы на самом-то деле все последовательные и логичные. Спланировали, какие критерии нужны, и выбрали людей, при запуске поделились со всем своими планами, подготовились индивидуально, учитывая все особенности и требования именно этой системы. Далее получили результаты, которые показали нашим экспертам, и все проблемы, что всплывали, поправили. И дальше следим, чтобы нигде ничего не нарушалось.



Заключение



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



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



Полезные ссылки



Материалы для подготовки

Хорошая статья о тестировании от Натальи Руколь


Original source: habrahabr.ru.

https://habrahabr.ru/post/304030/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Разоблачение скрытых полей C#

Четверг, 23 Июня 2016 г. 15:56 (ссылка)





Скрытые поля C# недоступны за пределами класса – ясно как дважды два. Поэтому следующий код не должен работать.



public class Example
{
private string _someValue;
public void DoSomething(Example otherObject)
{
_someValue = otherObject._someValue; // What!? You can't access a private variable from another object! Can you?
}
}


Но, как ни странно, он работает.



Оказывается, к переменной Private можно получить доступ из другого объекта того же типа. И, если задуматься, это вполне логично. Зачем нужны переменные Private? Для инкапсуляции и управления состоянием объекта.



Представьте, что нам нужно создать контейнер с ограниченной емкостью – коробку конфет. Мы могли бы сделать это так:



public class Chocolate
{
public string Name { get; set; }
}

public class ChocolateBox
{
public List Chocolates { get; set; }

public bool IsValid()
{
return Chocolates.Count > -1 && Chocolates.Count < 11;
}
}


Догадайтесь, в чем проблема



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



public class Chocolate
{
public string Name { get; set; }
}

public class ChocolateBox
{
private List _chocolates;

public void AddChocolate(Chocolate chocolate)
{
if(_chocolates == null) _chocolates = new List();
if(_chocolates.Count > 10) throw new Exception("No more space");
_chocolates.Add(chocolate);
}

// Other methods removed for brevity
}


Но здесь есть одно условие.



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



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



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



Доступ к скрытым переменным при создании объектов-значений



Объекты-значения – это один из шаблонов проблемно-ориентированного программирования, который также можно использовать за пределами этой модели. Отличительная черта таких объектов в том, что их равенство основывается не на идентификаторе, а на значении.



Простой пример – строка. Две строки с одними и теми же символами в одинаковом порядке считаются равнозначными. Аналогично можно сравнивать телефонные номера из системы CRM, если, конечно, вы не пишете ПО для оператора телефонной связи – в таком случае телефонный номер может выступать идентификатором клиента и, следовательно, не быть объектом-значением.



В большинстве случаев объекты-значения неизменяемы. В том числе это касается строк: «изменяя» строку, вы, по сути, создаете новый объект. Чем полезна такая неизменяемость? Мне приходит на ум 4 причины:




  • Объекты намного легче тестировать.

  • Объекты легче распараллелить.

  • Можно быть уверенным, что они всегда в действительном состоянии.

  • Не нужно отслеживать много идентификаторов в приложении (пожалуй, основная причина).



Пример объекта-значения



В качестве примера давайте смоделируем контейнер для жидкости или, проще говоря, чашку с максимальной емкостью в 1 литр. При этом мы можем перелить содержимое из одной чашки в другую (с точки зрения кода для этого понадобится еще один экземпляр чашки). Жидкость, превышающая максимальный объем, считается утерянной. Если же две чашки содержат одинаковый объём жидкости, они равны.



Начнем с тестирования. Чтобы чашка была неизменяемой, передадим текущий объем жидкости в конструктор. Для начала проверим, можем ли мы создать чашку, наполненную жидкостью.



[Test]
public void Constructor_ValidVolume_ObjectIsNotNull()
{
var cup = new Cup(0.5m);
Assert.NotNull(cup);
}


Теперь удостоверимся, что чашка не может содержать недопустимый объем – более одного или менее нуля литров.



[TestCase(-0.1)]
[TestCase(1.1)]
public void Constructor_InvalidVolumes_ThrowsException(decimal invalidVolume)
{
ArgumentOutOfRangeException expected = new ArgumentOutOfRangeException("volume");
ArgumentOutOfRangeException actual = null;
try
{
var cup = new Cup(invalidVolume);
}
catch (ArgumentOutOfRangeException ex)
{
actual = ex;
}

Assert.AreEqual(expected.ParamName, actual.ParamName);
}


А теперь самое интересное. Как сделать, чтобы чашки были одинаковыми? Для этого нам нужен доступ к скрытым переменным.



[Test]
public void Equals_TwoEqualCups_AreEqual()
{
var cup1 = new Cup(0.5m);
var cup2 = new Cup(0.5m);
Assert.AreEqual(cup1, cup2);
}


На досуге можете потренироваться с переливанием жидкости. Впрочем, возникает интересный вопрос: как перелить жидкость из чашки, если она неизменяема? :)



Вывод



Объекты-значения – полезный концепт проблемно-ориентированного программирования. При переопределении метода equals вы можете воспользоваться преимуществами этой особенности в C#, чтобы получить доступ к скрытым переменным однотипных классов.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303932/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Readme Driven Development

Четверг, 23 Июня 2016 г. 15:27 (ссылка)

RDD — это крайне простая практика. И здесь «DD» может означать «минута на освоение и вся жизнь для мастерства». Но, к счастью, не в этом случае.



Пишите Readme в первую очередь. Вот в принципе и все. Но почему?



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



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



Работа программы это не только о её код. Если никто не может использовать программу, потому что не знает как, то не важно содержит ли она кучу ошибок или не содержит ни одной.



Скромняга Readme



Readme — это самый важный файл во всем проекте. Он должен содержать краткий обзор задач проекта (его назначение, зачем он создан), инструкции по установке, известные проблемы и достаточно подробное описание того, что нужно сделать чтобы быстро начать пользоваться программой, для тех людей, которые никогда до этого не пользовались вашим программным обеспечением.



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



Если вы напишете свой Readme, до того как приступить к написанию кода, вы получите несколько крутых преимуществ:




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

  2. Когда вы начнёте писать код, вы будете иметь чёткое представление, что и как именно должно быть реализовано.

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

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

  5. Обсуждения очень важны. И гораздо легче обсуждать, то что записано. Легче изменить Readme чем бесконечно спорить о том, как что-то должно работать, когда и если вы до него доберётесь.

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

  7. Изменяются даже самые продуманные проекты, надеюсь, что эти изменения будут происходить не из-за каких-либо проблем. а для добавления новой функциональности. Но они все равно неизбежны и как правило происходят путем развития. Единственный документ (надеюсь, в системе контроля версий) может выступать идеальной средой для связи между изменениями по мере того, как они происходят. Также стоит отметить, что записывать изменения по мере того как они происходят гораздо проще, чем пытаться вспомнить их все потом.



Добавление RDD в существующий проект требует отдельной статьи. Но на данный момент, надеюсь, у вас появилась пища для размышлений.
Original source: habrahabr.ru.

https://habrahabr.ru/post/303262/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
bremer

Без заголовка

Четверг, 23 Июня 2016 г. 20:39 (ссылка)
spayte.ru/post393260414/

Жесткий диск (на англ. HDD — Hard Disk Drive) — устройство хранения информации в вашем компьютере. Все ваши программы, игры, документы, фотографии, музыка, фильмы и прочие файлы компьютера хранятся на этом устройстве, поэтому рекомендую п...
Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Тестируем асинхронный код

Вторник, 21 Июня 2016 г. 14:44 (ссылка)

Асинхронный код – сложный. Все это знают. Писать асинхронные тесты – еще сложнее. Недавно я починил мигающий (flaky) тест и хотел бы поделиться некоторыми мыслями по поводу написания асинхронных тестов.



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







Тестируем throttler



Throttler (Ограничитель) – это класс, отвечающий за ограничение количества одновременных операций, выполняемых с некоторым ресурсом (например, пул соединения, сетевой буфер или ресурсоемкие операции процессора). В отличие от других инструментов синхронизации, роль ограничителя заключается в том, чтобы запросы, превышающие квоту, завершались ошибкой немедленно, без ожидания. Быстрое завершение важно, поскольку альтернатива, ожидание, потребляет ресурсы – порты, потоки и память.



Вот простая реализация ограничителя (в своей основе это обертка вокруг класса Semaphore; в реальном мире тут может встречаться ожидание, повторные попытки и т.д.):

class ThrottledException extends RuntimeException("Throttled!")
class Throttler(count: Int) {
private val semaphore = new Semaphore(count)
def apply(f: => Unit): Unit = {
if (!semaphore.tryAcquire()) throw new ThrottledException
try {
f
} finally {
semaphore.release()
}
}
}


Начнем с простого юнит-теста: тестируем ограничитель для одного потока (для тестов мы используем библиотека specs2). В этом тесте мы проверяем, что можем выполнить больше последовательных вызовов, чем установленное для ограничителя максимальное количество одновременных вызовов (переменная maxCount ниже). Заметьте, что поскольку мы используем единственный поток, мы не проверяем способность ограничителя к «быстрому завершению», так как мы не нагружаем ограничитель. По сути, мы проверяем лишь тот факт, что пока ограничитель не нагружен, он не прерывает выполнение операций.

class ThrottlerTest extends Specification {
"Throttler" should {
"execute sequential" in new ctx {
var invocationCount = 0
for (i <- 0 to maxCount) {
throttler {
invocationCount += 1
}
}
invocationCount must be_==(maxCount + 1)
}
}
trait ctx {
val maxCount = 3
val throttler = new Throttler(maxCount)
}
}




Тестируем ограничитель асинхронно



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



Подготовка:

val e = Executors.newCachedThreadPool()
implicit val ec: ExecutionContext = ExecutionContext.fromExecutor(e)
private val waitForeverLatch = new CountDownLatch(1)

override def after: Any = {
waitForeverLatch.countDown()
e.shutdownNow()
}

def waitForever(): Unit = try {
waitForeverLatch.await()
} catch {
case _: InterruptedException =>
case ex: Throwable => throw ex
}


Объект ExecutionContext используется для конструкции Future; метод waitForever держит поток до момента, пока не обнулится счетчик waitForeverLatch – перед окончанием теста. В следующей за этим функции мы закрываем ExecutorService.



Упрощенный способ проверки многопоточного поведения ограничителя выглядит так:

"throw exception once reached the limit [naive,flaky]" in new ctx {
for (i <- 1 to maxCount) {
Future {
throttler(waitForever())
}
}
throttler {} must throwA[ThrottledException]
}


Здесь мы создаем потоки в количестве равном maxCount. В каждом потоке мы вызываем функцию waitForever, которая ждет до окончания теста. Затем мы пытаемся выполнить еще одну операцию, чтобы обойти ограничитель – maxCount +1. Предполагается, что в этом месте мы должны получить исключение ThrottledException. Однако, хотя мы ждем исключения, оно не наступает. Последний вызов ограничителя (с ожиданием) может произойти до запуска любого из future (это приводит к тому, что исключение бросается в этом экземпляре future, но не в рамках ожидания).



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

"throw exception once reached the limit [naive, bad]" in new ctx {
for (i <- 1 to maxCount) {
Future {
throttler(waitForever())
}
}
Thread.sleep(1000)
throttler {} must throwA[ThrottledException]
}


Хорошо, теперь наш тест будет почти всегда проходить. Но это неправильный подход, как минимум по двум причинам:

Длительность теста будет в точности равна установленной нами «разумной длительности».

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



Если вы все еще сомневаетесь, поищите в Google иные причины.

Более правильный подход заключается в синхронизации старта наших потоков (future) и нашего ожидания.



Будем использовать класс CountDownLatch из пакета java.util.concurrent:

"throw exception once reached the limit [working]" in new ctx {
val barrier = new CountDownLatch(maxCount)

for (i <- 1 to maxCount) {
Future {
throttler {
barrier.countDown()
waitForever()
}
}
}

barrier.await(5, TimeUnit.SECONDS) must beTrue

throttler {} must throwA[ThrottledException]
}


Мы используем CountDownLatch для барьерной синхронизации. Метод await блокирует главный поток до обнуления счетчика latch. При запуске других потоков (будем обозначать эти другие потоки как futures), каждый из этих futures вызывает барьерный метод countDown, чтобы снизить значение счетчика latch на единицу. Когда счетчик latch становится равным нулю, все futures располагаются внутри метода waitForever.

К этому моменту мы убедились, что ограничитель нагружен и содержит количество потоков, равное maxCount. Попытка другого потока задействовать ограничитель приведет к исключению. Таким образом, мы получили детерминированный порядок исполнения, при котором мы можем проверить поведение ограничителя в главном потоке. Главный поток может и будет продолждать выполнение в этой точке (счетчик barrier достигает нуля и CountDownLatch освобождает ожидающий поток).

Мы используем несколько завышенный таймаут во избежание бесконечной блокировки, если произойдет что-то непредвиденное. Если что-то произойдет – тест упадет. Этот таймаут не повлияет на длительность теста, поскольку, если ничего непредвиденного не произойдет, нам не надо его ждать.



Напоследок



При тестировании асинхронного кода достаточно часто есть потребность в определенном порядке потоков для определенного теста. Если не применять никакой синхронизации, получим нестабильные тесты, которые иногда отрабатывают, а иногда падают. Использование Thread.sleep снижает нестабильность тестов, но не решает проблемы. В большинстве случаев, когда нам необходимо определять порядок потоков в тесте, мы можем использовать CountDownLatch вместо Thread.sleep. Преимущество CountDownLatch в том, что мы можем указать, когда сбросить ожидание (удержание) потока, что дает нам два важных преимущества: детерминированное определение порядка и, благодаря этому, более стабильные тесты и более быстрое прохождение тестов. Даже для обычного ожидания, например, функции waitForever, мы могли бы использовать что-нибудь вроде Thread.sleep(Long.MAX_VALUE), но ненадежных подходов лучше всегда избегать.



Разработчик конструктора сайтов Wix,

Дмитрий Команов

Оригинал статьи: блог инженеров компании Wix
Original source: habrahabr.ru.

https://habrahabr.ru/post/301644/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Опыт автоматизации тестирования серверного REST API с помощью Jmeter

Суббота, 18 Июня 2016 г. 21:58 (ссылка)

В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.



RTLSCP реализует архитектуру REST и позволяет в запросах и ответах передавать данные в форматах JSON, KML и PNG. Причем общение по нему может происходить как по HTTP/HTTPS, так и по WS/WSS (Websocket). Этот протокол обеспечивает внешнего клиента обширным функционалом:




  • получение различной информации об устройствах — локация, статусы, состояние и т. д.;

  • передача управляющих команд на сервер — изменение параметров устройств, настроек сервера, отправка оповещений на устройства, загрузка карты и т. д.;

  • получение отчетов по устройствам, статуса работы системы от Quality of Service.

  • множество других полезных функций.



Важно, что протокол, со стороны сервера приложений обрастает дополнительным клиент-специфик функционалом от проекта к проекту. Как же это всё тестировать? Вручную получается долго и муторно, тестировщик скорее возненавидит весь мир пока пройдётся по всем командам спецификации RTLSCP API более чем в 120 страниц. Очевидно, этот процесс необходимо автоматизировать.



Тестирование системы проводится под Linux. Изначально мы пытались написать автотесты “на коленке“. Перепробовали несколько вариантов. Генерация запросов со случайными данными и отправка их на вход утилиты для нагрузочного тестирования Siege. В этом случае мы получаем только нагрузочное тестирование без возможности анализа содержимого ответа от сервера. Реализация автотестов на Python и простая отправка запросов через urllib. Тут всё веселее с анализом ответа, но получается громоздкий код, в который сложно вникать стороннему человеку и долго модифицировать.



Решением всех наших проблем стал неожиданно найденный Jmeter от Apache. Хоть на первый взгляд его графический интерфейс вызывает страх у обывателя, на деле этот инструмент помог найти большое количество багов и сэкономить много времени на тестировании RTLSCP API.



Рис. 1. Графический интерфейс Jmeter.



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



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



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





Рис. 2. Так выглядит реализация проверки создания аккаунтов.



С помощью BeanShell PostProcessor (Post тут означает, что скрипт запускается после выполнения запроса) обрабатываем ответ на запрос всех доступных в системе ресурсов. Получаем их количество и генерируем случайные Id ресурсов для последующего присвоения созданным аккаунтам прав доступа к ним. Это осуществляется следующим кодом на BeanShell:

import java.util.regex.*;
import java.util.*;
import java.util.Random;

String response = prev.getResponseDataAsString();
Pattern pattern = Pattern.compile("id");
Matcher matcher = pattern.matcher(response);
int count = 0;
while (matcher.find())
count++;
Random rd=new Random();
Set resSet = new HashSet();
while (resSet.size()<4)
resSet.add(rd.nextInt(count));
int i=1;
Iterator iterator = resSet.iterator();
while (iterator.hasNext()) {
vars.put("resForCombo"+i,iterator.next().toString());
i++;
}




Затем из ответа на запрос информации о ресурсе по его Id получаем его URL с помощью Regular Expression Extractor:





Рис. 3. Использование Regular Expression Extractor.



Тут всё очевидно, в переменную res1Addr помещается содержимое ответа, вырезанное по регулярному выражени. В конце проводим проверку всех созданных аккаунтов и их права доступа к ресурсам. Кстати, обработка Cookies для авторизации в Jmeter реализуется простым добавлением элемента HTTP Cookie Manager.



Элементы типа check AUTH_ACCOUNT_ADDED_INTO_GROUP на рисунке 2 нужны для проверки того, что каждое действие пользователя, совершенное над аккаунтами записалось в соответствующее событие в истории событий (Получаемой также через RTLSCP).



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



${__Random(300,180000)}




Или сгенерировать строку определенного размера и случайного содержания:



${__RandomString(${__Random(3,30)},ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789,)}




Понравилось, что в Jmeter любое действие можно реализовать как в коде BeanShell, так и с помощью встроенных инструментов. К примеру, получить количество доступных в системе ресурсов (выше мы это делаем через BeanShell PostProcessor ) можно реализовав Regular Expression Extractor, в котором в поле Match No. следует просто указать -1. В этом случае создаётся переменная {Reference Name}_matchNr, содержащая количество найденных в ответе по регулярному выражения строк. Так и ответ на любой запрос можно анализировать в коде BeanShell и выставлять флаги статуса выполнения элемента:



//Get response
response = prev.getResponseDataAsString();
//Check login
if (!response.contains("\"login\":\"${ulogin_g1}\"")) {
log.error("### login NOK!");
Failure= true;
//Check timestamp
} else if(!response.contains("\"create_ts\":${createTS_g1}")) {
log.error("### create_ts NOK!");
Failure= true;




Возможность комментирования каждого элемента делает автотест читабельным и позволяет ссылаться на тикет в багтрекере, например, Redmine:





Рис. 4. Комментирование элементов.



Отключение ресурсоемких проверок и добавление в Thread Group автотеста пользователей в поле Number of Treads (users) превращает наш функциональный автотест в нагрузочный. Теперь проект запускается одновременно из указанного количества потоков и нагружает сервер.





Рис. 5 Нагрузочное тестирование.



Результаты выполнения автотеста можно получить в любом удобном виде, как просмотреть в графической оболочке через View Results Tree, так и файлами логов с различными настройками:





Рис. 6 Получение результатов.



Также стоит отметить возможность в режиме реального времени отправлять результаты или любую другую информацию о статусе автотеста в различные сервисы (JDBC, JMS, Webservice). Например, на Graphite с последующим отображением в Grafana:





Рис. 7 Отправка результатов.



Естественно, у Jmeter существует некоторое количество отрицательных свойств. Например, не всегда удобный графический интерфейс и баги в нём. Но в нашей ситуации, когда срочно (и самое важное, бесплатно) требуется покрыть автоматическими тестами большое количество функций общения клиентов с сервером через протокол, Jmeter оказался незаменимым инструментом тестировщика.
Original source: habrahabr.ru.

https://habrahabr.ru/post/303584/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Опыт автоматизации тестирования серверного REST API с помощью Jmeter

Суббота, 18 Июня 2016 г. 21:58 (ссылка)

В данной статье речь пойдёт об опыте автоматизации функционального и нагрузочного тестирования API протокола RTLSCP. Серверная часть системы локального позиционирования RealTrac состоит из основного (core) сервера, который связывается с устройствами по протоколу INCP (InterNanoCom Protocol) и сервера приложений (appserver). Сервер приложений общается с внешними клиентами и основным сервером по протоколу RTLSCP (Real Track Location System Communication Protocol). Клиенты также могут напрямую обращаться к основному серверу по RTLSCP.



RTLSCP реализует архитектуру REST и позволяет в запросах и ответах передавать данные в форматах JSON, KML и PNG. Причем общение по нему может происходить как по HTTP/HTTPS, так и по WS/WSS (Websocket). Этот протокол обеспечивает внешнего клиента обширным функционалом:




  • получение различной информации об устройствах — локация, статусы, состояние и т. д.;

  • передача управляющих команд на сервер — изменение параметров устройств, настроек сервера, отправка оповещений на устройства, загрузка карты и т. д.;

  • получение отчетов по устройствам, статуса работы системы от Quality of Service.

  • множество других полезных функций.



Важно, что протокол, со стороны сервера приложений обрастает дополнительным клиент-специфик функционалом от проекта к проекту. Как же это всё тестировать? Вручную получается долго и муторно, тестировщик скорее возненавидит весь мир пока пройдётся по всем командам спецификации RTLSCP API более чем в 120 страниц. Очевидно, этот процесс необходимо автоматизировать.



Тестирование системы проводится под Linux. Изначально мы пытались написать автотесты “на коленке“. Перепробовали несколько вариантов. Генерация запросов со случайными данными и отправка их на вход утилиты для нагрузочного тестирования Siege. В этом случае мы получаем только нагрузочное тестирование без возможности анализа содержимого ответа от сервера. Реализация автотестов на Python и простая отправка запросов через urllib. Тут всё веселее с анализом ответа, но получается громоздкий код, в который сложно вникать стороннему человеку и долго модифицировать.



Решением всех наших проблем стал неожиданно найденный Jmeter от Apache. Хоть на первый взгляд его графический интерфейс вызывает страх у обывателя, на деле этот инструмент помог найти большое количество багов и сэкономить много времени на тестировании RTLSCP API.



Рис. 1. Графический интерфейс Jmeter.



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



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



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



image

Рис. 2. Так выглядит реализация проверки создания аккаунтов.



С помощью BeanShell PostProcessor (Post тут означает, что скрипт запускается после выполнения запроса) обрабатываем ответ на запрос всех доступных в системе ресурсов. Получаем их количество и генерируем случайные Id ресурсов для последующего присвоения созданным аккаунтам прав доступа к ним. Это осуществляется следующим кодом на BeanShell:

import java.util.regex.*;
import java.util.*;
import java.util.Random;

String response = prev.getResponseDataAsString();
Pattern pattern = Pattern.compile("id");
Matcher matcher = pattern.matcher(response);
int count = 0;
while (matcher.find())
count++;
Random rd=new Random();
Set resSet = new HashSet();
while (resSet.size()<4)
resSet.add(rd.nextInt(count));
int i=1;
Iterator iterator = resSet.iterator();
while (iterator.hasNext()) {
vars.put("resForCombo"+i,iterator.next().toString());
i++;
}




Затем из ответа на запрос информации о ресурсе по его Id получаем его URL с помощью Regular Expression Extractor:



image

Рис. 3. Использование Regular Expression Extractor.



Тут всё очевидно, в переменную res1Addr помещается содержимое ответа, вырезанное по регулярному выражени. В конце проводим проверку всех созданных аккаунтов и их права доступа к ресурсам. Кстати, обработка Cookies для авторизации в Jmeter реализуется простым добавлением элемента HTTP Cookie Manager.



Элементы типа check AUTH_ACCOUNT_ADDED_INTO_GROUP на рисунке 2 нужны для проверки того, что каждое действие пользователя, совершенное над аккаунтами записалось в соответствующее событие в истории событий (Получаемой также через RTLSCP).



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



${__Random(300,180000)}




Или сгенерировать строку определенного размера и случайного содержания:



${__RandomString(${__Random(3,30)},ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789,)}




Понравилось, что в Jmeter любое действие можно реализовать как в коде BeanShell, так и с помощью встроенных инструментов. К примеру, получить количество доступных в системе ресурсов (выше мы это делаем через BeanShell PostProcessor ) можно реализовав Regular Expression Extractor, в котором в поле Match No. следует просто указать -1. В этом случае создаётся переменная {Reference Name}_matchNr, содержащая количество найденных в ответе по регулярному выражения строк. Так и ответ на любой запрос можно анализировать в коде BeanShell и выставлять флаги статуса выполнения элемента:



//Get response
response = prev.getResponseDataAsString();
//Check login
if (!response.contains("\"login\":\"${ulogin_g1}\"")) {
log.error("### login NOK!");
Failure= true;
//Check timestamp
} else if(!response.contains("\"create_ts\":${createTS_g1}")) {
log.error("### create_ts NOK!");
Failure= true;




Возможность комментирования каждого элемента делает автотест читабельным и позволяет ссылаться на тикет в багтрекере, например, Redmine:



image

Рис. 4. Комментирование элементов.



Отключение ресурсоемких проверок и добавление в Thread Group автотеста пользователей в поле Number of Treads (users) превращает наш функциональный автотест в нагрузочный. Теперь проект запускается одновременно из указанного количества потоков и нагружает сервер.



image

Рис. 5 Нагрузочное тестирование.



Результаты выполнения автотеста можно получить в любом удобном виде, как просмотреть в графической оболочке через View Results Tree, так и файлами логов с различными настройками:



image image

Рис. 6 Получение результатов.



Также стоит отметить возможность в режиме реального времени отправлять результаты или любую другую информацию о статусе автотеста в различные сервисы (JDBC, JMS, Webservice). Например, на Graphite с последующим отображением в Grafana:



image

Рис. 7 Отправка результатов.



Естественно, у Jmeter существует некоторое количество отрицательных свойств. Например, не всегда удобный графический интерфейс и баги в нём. Но в нашей ситуации, когда срочно (и самое важное, бесплатно) требуется покрыть автоматическими тестами большое количество функций общения клиентов с сервером через протокол, Jmeter оказался незаменимым инструментом тестировщика.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303584/

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<тестирование - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda