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


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

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

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

Как настроить расширяемую систему для регрессионного тестирования на телефонах: опыт мобильной Почты Mail.Ru

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





Привет, Хабр! Сегодня я хочу рассказать, как мы построили с нуля гибкую и расширяемую систему для выполнения автотестов на Android-смартфонах. Сейчас у нас используется около 60 устройств для регрессионного тестирования мобильного приложения Почты Mail.Ru. В среднем они тестируют около 20 сборок приложения ежедневно. Для каждой сборки выполняется около 600 UI-тестов и более 3500 unit-тестов.



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



Мы рассмотрим, как всё делать с самого начала тем, кто занимается написанием автотестов, а не инфраструктурой: начиная от покупки телефона, его перепрошивки и заканчивая созданием docker-контейнеров, внутри которых будет доступен телефон для автотестов.



Какие телефоны выбрать для автотестов на Андроиде?





Когда Android только-только становился популярным, у разработчиков тестов был выбор из двух зол: покупать дорогой зоопарк телефонов либо работать с медленными и глючными виртуалками. Сегодня всё несколько проще, на рынке появились дешёвые аппараты «эконом»-класса, а виртуальный Андроид обзавёлся образом для x86 и HAXM. Однако выбор всё ещё остался, многие предпочитают для автотестов виртуальные машины, но телефоны уже стали вполне доступной опцией даже для скромного бюджета на автотестирование. Так как же выбрать телефон для регрессионных автотестов и какое оборудование ещё нужно, чтобы всё вместе оно могло работать 24/7?



Рынок телефонов очень большой — глаза разбегаются. Какие же критерии выставить при выборе телефона? У меня после череды проб и ошибок вышел такой список (цену на аппарат опускаю, с ней, надеюсь, всё понятно):




  1. Есть возможность получить права root.

  2. Есть возможность анлока boot-раздела телефона.

  3. На телефоне стоит версия Андроида, максимально близкая к стоковой, или подобные можно установить (чтобы не пришлось лопатить кучу вариантов теста под разные интерфейсы).

  4. Оперативная память на телефоне желательно должна быть размером от 1 Гб (можно работать и на меньшей, но, даже если тесты написаны стабильно, различные проверки отображения «тяжёлых» объектов на телефоне с низкой оперативной памятью окажутся долгими).

  5. Совсем здорово, если у телефона будет долгий саппорт от производителя/пользователей, тогда у нас остаётся шанс продлить ему жизнь новыми версиями ОС.



Основная часть критериев достаточно прозрачна. Если окажется, что на телефоне что-то работает не так, то мы должны хотя бы иметь шанс заставить это работать сами. :) К сожалению, большая часть критериев — это не те вещи, о которых можно спросить продавца при покупке, поэтому в первую очередь наш путь лежит на forum.xda-developers.com и 4pda.ru/forum, где о рыночной модели можно узнать все подробности. Плюс ко всем перечисленным критериям, если модель уже долго продаётся, обращайте на форумах внимание на отзывы о браке и времени ресурса памяти и батареек, без них ваше устройство превратится в тыкву. Проблемы экрана, кнопок, корпуса, динамиков и прочего, что обычно интересует пользователя, вас, как правило, пугать не должны: телефон прекрасно будет работать с браком этих элементов, хотя всё зависит от специфики проекта.



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



1. Модель телефона имеет кучу региональных подвидов, при этом только на части из них можно получить рут или разлочить бутлоадер. Мало того что наткнуться на российский сертифицированный телефон в неофициальном магазине сложно — серые и белые телефоны выглядят одинаково, — так ещё и многие продавцы или их поставщики перепрописывают названия моделей, характеристики железа, регионы и даже версии операционных систем. Вполне возможен случай, когда внутри «Настроек» в Андроиде вы видите одну модель, внутри бутлоадера другую, а в шелле, когда набираете getprop и получаете айдишники, — третью. Просто телефон прошёл пару рук и пару регионов до вас. Сначала его хозяином был пользователь Веризона из Южной Дакоты, потом тот сдал его, в refurbished-состоянии аппарат как-то попал торговцу в Тель-Авиве, который его криво перепрошил на их версию операционной системы, а через ещё какое-то время телефон перекупил продавец в Москве, который уже стал продавать его как новый. Вам привозит его курьер, вы берёте в руки своё новое восьмиядерное перепрошиваемое российское устройство, не подозревая, что это шестиядерный залоченный региональный эксклюзив для контрактных пользователей оператора сотовой связи из США.





Элементы коробки и телефона с «современной» начинкой и высокой ценой, который по внутренним характеристикам оказался перепрошитой младшей моделью от AT&T



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





Типичные значения серийников у бюджетных телефонов



3. Псевдослучайный MAC-адрес у Wi-Fi-модуля после перезагрузки телефона. Это была довольно серьёзная проблема, потому что мы узнали о ней, когда я убедился, что «всё хорошо», телефон нам подходит, и мы заказали 20 штук точно таких же. :) В процессе работы автотестов телефоны иногда перезагружаются, через какое-то время тесты начали падать из-за отсутствия доступа к сети по Wi-Fi, хотя всё при этом выглядело нормально: соединение с сетью было и после включения/выключения Wi-Fi-модуля всё работало корректно. Просто после ребутов в какой-то момент у пары телефонов оказывался одинаковый MAC, Wi-Fi-точка доступа же пускала только последний присоединившийся. На тех телефонах, где в итоге генерился MAC-адрес, я, к сожалению, не нашёл, пришлось в загрузочном разделе поместить скрипт, который устанавливал его насильно на уникальный.





Телефон демонстрирует чудеса spoofing’а из коробки



Тем не менее, если соблюдать при выборе телефона перечисленные выше критерии, эти проблемы не должны быть фатальными — всё это можно исправить руками и заставить телефон работать как нужно.



Кроме телефонов, для запуска автотестов понадобится сам компьютер и USB-хабы, тут тоже есть несколько нюансов. Постоянно работающим телефонам нужно хорошее питание (минимум 0,5 А на устройство, лучше больше), многие хабы на рынке идут со слабыми адаптерами и никак не рассчитаны на то, что в каждый порт будет подключён постоянно работающий телефон. С планшетами ещё сложнее, девятидюймовые планшеты при постоянной работе разряжаются, экран слишком большой, приходится выбирать из семидюймовых. Из практики у нас вышло, что на адаптер в 4 А можно подключить 6–7 телефонов (в зависимости от их загрузки работой), т. е. большая часть многопортовых хабов с характеристиками типа «адаптер на 3 А, 20 USB-портов», мягко говоря, бесполезны. Самые крутые — серверные решения, но цена у них зашкаливает, так что ограничимся пользовательским рынком. Чтобы телефоны не разряжались, стоит брать хабы на четыре порта с питанием в 3 А, либо хабы на шесть портов с питанием на 4 А. Если есть хабы с хорошим питанием, но с большим количеством портов, — часть портов можно просто не использовать.



Готовим телефон к работе



Давайте для примера возьмём одну модель телефона, решим одну из проблем его операционной системы, а дальше попробуем собрать эти устройства в примитивный тестовый стенд для автотестов. Телефон сам по себе дешёвый и хороший, но с некоторыми недостатками (описанными выше). В частности, у этих телефонов одинаковый iSerial, adb видит только одно устройство. :( Совсем везде на телефоне его менять не будем, но сделаем так, чтобы adb отдельные телефоны отличал.



Для этого нам нужно будет перепрошить у телефона boot-раздел и установить на устройстве кастомный раздел восстановления — так вы сможете уберечься от неудачных экспериментов. У наших телефонов стоит МТ6580, т. е. процессор фирмы Mediatek, значит, для перепрошивки можно использовать SP Flash Tool. Ещё нужны готовый образ recovery.img и scatter-файл устройства. Почти для всех устройств их можно найти в интернете, на тех же самых ресурсах XDA и 4PDA, но при желании recovery можно перекомпилировать для своего устройства, взяв за основу TWRP, а scatter-файл создать самому. В любом случае берём наши готовые файлы и перепрошиваем:







После установки раздела восстановления сохраните через него бэкап boot-раздела и переместите его к себе на машину, обычно в этом разделе располагаются конфигурационные файлы ОС. Чтобы захардкодить свой iSerial, нужно распаковать образ загрузочного раздела телефона, это можно сделать с помощью Android Image Kitchen. Запускаем unpackimg.sh и получаем распакованный образ в папке ramdisk:







Здесь много init-файлов, в которых указываются различные переменные, в том числе и серийный номер.







Находим файл, где устанавливается серийный номер ${ro.serialno}, и заменяем его на свой номер, например 999222333019:



find ramdisk/ -maxdepth 1 -name "init.mt*" -exec sed -i 's/${ro.serialno}/999222333019/g' {} +


Запаковываем образ обратно с помощью repackimg.sh, перекидываем его на телефон и устанавливаем с помощью кастомного рекавери. Теперь adb будет отличать устройства, нам остаётся включить режим разработчика на телефоне и разрешить debug в меню разработчика. Любые подобные проблемы можно решать точно таким же путём, практически всё в телефоне можно перепрошить или поправить, если этого потребуют задачи тестирования.



Настройка тестовой машины



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



При заказе/сборке машины, к которой будут подключены телефоны, есть специфика. Кроме стандартных HDD/RAM/CPU, нужно обратить внимание на количество USB-контроллеров на материнской плате и поддерживаемый протокол USB. Телефоны, работающие на USB 3.0 (xHCI), могут существенно ограничить максимальное количество устройств на машине (обычно 8 на контроллер, в итоге 16 устройств на машину с двумя контроллерами), поэтому стоит проверить, есть ли возможность его отключить и использовать только EHCI. Такие опции есть в биосе или ОС, лучше всего насильно отключить xHCI в биосе, если вам не нужны высокоскоростные устройства.



Создаём контейнер для телефона



Если нужно, чтобы слейв / агент системы интеграции работал с отдельным телефоном, то их следует как-то разделить. У нас агенты запускаются в отдельных docker-контейнерах, каждому из которых доступно по одному устройству, — так мы можем распределять задачи в CI на отдельные устройства, а точнее на их возможности (например, контейнер с планшетом может выполнять тесты, для которых требуется широкая диагональ экрана, а контейнер с телефоном — тесты, для которых нужна возможность принимать SMS-сообщения). Пример установки и настройки системы на Ubuntu описан далее. Устанавливаем сам Docker:



sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D
echo 'deb https://apt.dockerproject.org/repo <версия ubuntu> main' >> /etc/apt/sources.list.d/docker.list
sudo apt-get update
sudo apt-get install docker-engine


В качестве сторадж-драйвера будем использовать overlayFS (работает быстрее дефолтного):



echo 'DOCKER_OPTS="-s overlay"' >> /etc/default/docker


Создаем dockerfile, из которого будем делать образы. Добавим в него Android SDK:



FROM ubuntu:trusty
ARG DEBIAN_FRONTEND=noninteractive

RUN apt-get update -y && \
apt-get install -y software-properties-common && \
add-apt-repository ppa:webupd8team/java -y && \
apt-get update -y && \
echo oracle-java8-installer shared/accepted-oracle-license-v1-1 select true | /usr/bin/debconf-set-selections && \
apt-get install -y oracle-java8-installer && \
apt-get remove software-properties-common -y && \
apt-get autoremove -y && \
apt-get clean
ENV JAVA_HOME /usr/lib/jvm/java-8-oracle
ENV ANT_VERSION 1.9.4

RUN cd && \
wget -q http://archive.apache.org/dist/ant/binaries/apache-ant-${ANT_VERSION}-bin.tar.gz && \ tar -xzf apache-ant-${ANT_VERSION}-bin.tar.gz && \ mv apache-ant-${ANT_VERSION} /opt/ant && \ rm apache-ant-${ANT_VERSION}-bin.tar.gz

ENV ANT_HOME /opt/ant
ENV PATH ${PATH}:/opt/ant/bin

ENV ANDROID_SDK_VERSION r24.4.1
ENV ANDROID_BUILD_TOOLS_VERSION 23.0.3

RUN dpkg --add-architecture i386 && \
apt-get update -y && \
apt-get install -y libc6:i386 libncurses5:i386 libstdc++6:i386 lib32z1 && \
rm -rf /var/lib/apt/lists/* && \
apt-get autoremove -y && \
apt-get clean

ENV ANDROID_SDK_FILENAME android-sdk_${ANDROID_SDK_VERSION}-linux.tgz
ENV ANDROID_SDK_URL http://dl.google.com/android/${ANDROID_SDK_FILENAME}
ENV ANDROID_API_LEVELS android-15,android-16,android-17,android-18,android-19,android-20,android-21,android-22,android-23
ENV ANDROID_HOME /opt/android-sdk-linux
ENV PATH ${PATH}:${ANDROID_HOME}/tools:${ANDROID_HOME}/platform-tools
RUN cd /opt && \
wget -q ${ANDROID_SDK_URL} && \
tar -xzf ${ANDROID_SDK_FILENAME} && \
rm ${ANDROID_SDK_FILENAME} && \
echo y | android update sdk --no-ui -a --filter tools,platform-tools,${ANDROID_API_LEVELS},build-tools-${ANDROID_BUILD_TOOLS_VERSION}

###Добавим файл системы интеграции, это может быть слейв дженкинса, агент Bamboo и т. п., в зависимости от того, с чем вы работаете
ADD moyagent.sh /agentCI/


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



docker build .


Теперь у нас есть образ с Android SDK, осталось сделать так, чтобы он видел только одно устройство. Для этого будем цеплять его через симлинк c помощью udev:



echo ‘"SUBSYSTEM=="usb", ATTRS{serial}=="$DEVICE_SERIAL", SYMLINK+="androidDevice1"’ >> /etc/udev/rules.d/90-usb-symlink-phones.rules


Вместо $DEVICE_SERIAL вписываем наш свежепрошитый серийник. Перезапускаем определение правил устройств:



udevadm control --reload
udevadm trigger


Теперь в пути /dev/androidDevice1 у нас будет симлинк на устройство, осталось передать его в контейнер при запуске:



docker run -i -t --rm --device=/dev/androidDevice1:/dev/bus/usb/001/1 android-docker-image:latest adb devices


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



docker run -i -t --rm --device= /dev/androidDevice1:/dev/bus/usb/001/1 android-docker-image:latest /bin/sh /agentCI/moyagent.sh


Кстати, ключ --device стал работать с симлинками относительно недавно (master-ветка на Гитхабе), до этого приходилось генерить из симлинка realpath c помощью скрипта и уже его передавать Докеру, так что если у вас не выходит подключение устройства, то добавьте в udev в параметр RUN+= такой скрипт:



realpath /dev/androidDevice1 | xargs -I linkpath link linkpath /dev/bus/usb/010/1


После этого в старых версиях Docker добавить телефон можно так:



docker run --privileged -v /dev/bus/usb/010/:/dev/bus/usb/100/ -i -t  android-docker-image:latest adb devices


Всё, можно подключать свой слейв к системе интеграции и работать с ним.



Заключение



Физические мобильные устройства в системе интеграции рано или поздно появляются у любого более-менее крупного проекта на Андроиде — неизбежно возникают необходимость покрытия ошибок, нестандартные тестовые случаи или просто фичи, которые требуют реального устройства. Кроме всего этого, устройства не используют ресурсы ваших серверов, так как процессоры и память у них свои, а хост для телефонов не должен быть супермощным, «домашний» десктоп со всем этим вполне справится. Соизмеряйте плюсы и минусы, считайте, что выгоднее, — наверняка в вашей системе автоматизированного тестирования есть место реальным устройствам. Желаю вам поменьше багов и побольше тестового покрытия. :)
Original source: habrahabr.ru.

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

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

Результаты теста "Сколько баллов ваш ветер?"

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



 






















 


Ветер порывистый


Ваш ветер непостоянен. То он слегка дует, неспешно разглядывая всё вокруг, то вдруг начинает торопиться, сбиваясь с ног и куда-то опаздывая.


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


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


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












 

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

Отчёт с прошедшего 17 июня QA MeetUp

Понедельник, 18 Июля 2016 г. 17:40 (ссылка)





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



— Никита Макаров, Одноклассники



«API, Облака и зачем это все тестировщику»




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







Видеозапись:

Часть 1 it.mail.ru/video/728

Часть 2 it.mail.ru/video/729



— Юлия Сомова, Mail.Ru Group



«Микросервисный подход реализации приложения на примере автоматизации тестирования проекта Почта Mail.Ru»




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







Видеозапись: it.mail.ru/video/730



— Наталья Чуфырина, Mail.Ru Group



«Как создать команду по автоматизации тестирования»




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




  • отборе рекрутов в программу обучения автоматизации тестирования;

  • первичном пороге для вхождения в рекруты;

  • составлении учебной программы;

  • промежуточном контроле и испытаниях;

  • начале работы над реальными проектами;

  • подводных камнях и ошибках, которые можно допустить.



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







Видеозапись:

Часть 1 it.mail.ru/video/733

Часть 2 it.mail.ru/video/734



— Алексей Халайджи, Mail.Ru Group



«Как мы автоматизируем UI-тестирование в iOS Почте Mail.Ru»




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







Видеозапись:

Часть 1 it.mail.ru/video/735

Часть 2 it.mail.ru/video/736



— Максим Богуславский, Banki.ru



«Как вырастить в себе автоматизатора и разработчика»




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







Видеозапись:

Часть 1 it.mail.ru/video/731

Часть 2 it.mail.ru/video/732



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




  • о том, с чего начать автоматизацию тестирования;

  • о том, что делает автоматизированные тесты выгодными;

  • о том, как превратить точечное написание автоматизирвоанных тестов в стройный конвейер с отлаженными процессами;

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



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







Видеозапись: it.mail.ru/video/738
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/305862/

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

Анализ обнаружения обфусцированных вирусов мобильными антивирусными приложениями на платформе Android

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

Команда УЦСБ провела независимое исследование для того, чтобы протестировать работу популярных антивирусных приложений для Android. С результатами этого исследования я делилась на конференции phdays VI, но хотелось бы более подробно остановиться на применении обфускаторов для обхода механизмов обнаружения вирусов.

Читать дальше →

https://habrahabr.ru/post/305730/

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

Тонкости подбора респондентов для UX-исследований

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





Привет, Хабр! Меня зовут Наталия Спрогис, и я руковожу направлением UX-исследований в Mail.Ru Group. Сегодня я бы хотела поговорить о тех людях, без которых мы не могли бы помогать нашим проектам. Поиск участников UX-исследований — краеугольный камень успеха всего мероприятия. И, судя по количеству вопросов «А как вы ищете респондентов?», которые получают наши исследователи на любой конференции, актуальная тема. Давайте попробуем разобраться: кого нужно звать, сколько их должно быть и как их можно найти. Речь в первую очередь пойдет о рекрутинге для качественных исследований, в частности для юзабилити-тестирований.



Часть 1. Кого?



Кого пригласить на исследование?



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



Не отталкивайтесь от демографии. Часто, когда мы впервые работаем с каким-нибудь продуктом и обсуждаем с менеджером аудиторию для теста, получаем примерно такой портрет пользователя: «женщины 60%, преимущественно в возрасте 25–35 лет, пользователи Mail.Ru». Несмотря на то что это ценные и полезные данные, это не может быть профилем для исследования. Представьте, что мы решили протестировать дизайн страницы создания письма в веб-почте Mail.Ru. И позвали на тест пользователей, имеющих ящик на Mail.Ru, распределенных по полу и возрасту согласно данным статистики. Скорее всего, окажется, что кто-то из них вообще не пишет письма, а лишь получает рассылки, кто-то пользуется только мобильным клиентом, а у кого-то этот ящик не является основным. Опыт этих людей будет для нас бесполезен. Это не значит, что нужно вообще игнорировать знания о демографии, просто эти критерии не должны быть основными.



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




  • опытный пользователь;

  • пользователь с аналогичным опытом (конкурентный продукт или решение задачи каким-то другим способом);

  • неопытный пользователь.



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



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



Аккуратнее с неопытными пользователями. Часто нам важно увидеть, как с нашим продуктом взаимодействуют совершенно неопытные пользователи. Ведь этим мы имитируем момент первого знакомства с проектом новой аудитории. Так вот, «неопытную» аудиторию нужно подбирать тоже вдумчиво. В идеальном варианте это должны быть не просто люди, которые не пользуются текущим продуктом. А люди, у которых потенциально в нем есть потребность. Например, в свое время у нас сорвался тест регистрации в Одноклассниках. Участница отказалась от выполнения заданий. Выяснилось, что она сознательно не регистрируется ни в одной соцсети, так как боится контроля «Большого Брата», и не готова этого делать даже на тесте. Это, конечно же, крайний случай. Но если вы позовете людей, не имеющих вообще никакого интереса в предметной области, скорее всего, их выполнение заданий будет механическим. А значит, они принесут вам сильно меньше знаний. Например, для тестирования сервиса «Разбери ящик» в Почте Mail.Ru, позволяющего автоматически сортировать входящие рассылки, мы сознательно звали людей, страдающих от того, что их почта завалена многочисленными подписками. Пользователи разбирали собственные ящики, а не созданные для них тестовые. Поэтому мы на живых примерах видели, действительно ли сервис решает их проблемы с рассылками, а не просто проверяли механически понятность каждой формы.



Другие частые параметры. То, какие еще требования к участникам исследования у вас будут, всегда зависит от конкретных задач. Помимо опыта и демографии, часто встречается:




  • Мобильная платформа. При тестировании мобильных приложений и сайтов, даже если версия имеет единый интерфейс для разных платформ, важно протестировать ее на разных пользователях. Практика показывает, что очень часто проблемы на iOS и Android сильно отличаются, а пользователи этих платформ имеют разные навыки и привычки.

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

  • «Хардкорность». Этот критерий всплывает при тестировании игр. Любой продюсер игры расскажет вам, что существуют казуалы, мидкорщики и хардкорщики. Сложность в том, что четкого определения, кто к какой группе относится, не существует. Поэтому для каждой игры приходится придумывать свои. Как правило, они складываются из часов, проводимых в игре, и предпочтений в аналогичных играх в жанре.



Тесты на друзьях и коллегах



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




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


  • Перекошенная лояльность. Опыт проведения тестов на сотрудниках нашей компании показывает, что они либо очень лояльны к родному продукту (рассуждая примерно так: «Ой, ну я знаю ребят из команды, они же очень старались. А это у них не работает, потому что это тяжело реализовать, в нашем проекте с этим тоже мучились»), либо, наоборот, оказываются излишне требовательны и придирчивы, ожидая от своих коллег самого лучшего. Похожая ситуация возникает с друзьями. Чтобы не обидеть нас, они могут стараться закрывать глаза на какие-то недостатки продукта. Или, наоборот, захотят помочь нам найти больше проблем и станут придираться ко всему подряд. Любой хороший UX-специалист, конечно же, помнит, что нужно смотреть на поведение, а не слушать слова пользователя. Но эти отзывы могут создать ложное впечатление у команды проекта, наблюдающей за ходом тестирования. И вам придется потратить много усилий, чтобы объяснить им, что излишне позитивное или негативное впечатление на тесте еще не значит такую же реакцию реальной целевой аудитории.

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



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



Часть 2. Сколько?



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



«Just a handful of users»



Гуру юзабилити Якоб Нильсен более 20 лет назад начал популяризировать идею, что для любого юзабилити-теста достаточно пяти человек (Jakob Nielsen and Thomas Landauer, 1993). Это утверждение прочно засело во многих головах. Кто-то начал всегда брать по пять человек, независимо от задачи. Другие стали скептически воспринимать все юзабилити-исследования, ведь они основываются на изучении такой маленькой выборки.



Давайте разберемся, откуда взялось волшебное число пять. Как показывает практика, после первых нескольких участников юзабилити-тестирования количество новых обнаруженных проблем снижается. Нильсен постулирует, что выборка из пяти человек позволяет обнаружить 85% проблем интерфейса (Why You Only Need to Test with 5 Users). То есть брать больше людей может быть просто нецелесообразно.



На самом деле те 85%, о которых говорит Нильсен, относятся к наиболее серьезным и частотным проблемам (число справедливо для проблем, затрагивающих 31% аудитории). Если мы возьмем любой интерфейс, то в нем, скорее всего, кроется ряд частотных проблем, с которыми сталкивается много пользователей (например, проблемы при регистрации в игре), а также разнообразные менее частотные, но, возможно, достаточно критичные проблемы. Например, проблемы, с которыми сталкивается 15% аудитории, на пяти людях будут обнаружены уже с вероятностью 50%. Увеличение размера выборки повысит шансы найти менее частотные проблемы. Джеф Сауро, активно занимающийся вопросами статистической значимости в юзабилити, подробно разбирает этот вопрос в своей статье Why you only need to test with five users (explained).



Несмотря на популярность утверждения о пяти респондентах, многие исследователи предпочитают брать больше участников исследования. Джеф Сауро в 2012 году провел опрос около сотни читателей своего блога. Он попытался выяснить, сколько респондентов в реальности приглашают на исследования в различных компаниях. Опрос показал, что более 81% исследований базируются на выборках больше, чем пять человек (медиана 10) (How many users do people actually test?).



От чего зависит количество людей



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



Когда нужно больше людей.




  • Разнообразие аудитории. В пять человек не включить разнообразия по опыту, предпочтениям, паттернам взаимодействия и даже демографии аудитории. А часто именно это дает нам больше знаний. Чтобы понять, сколько людей вам требуется, нужно сначала расписать все ваши требования к аудитории, а потом взять в каждой группе хотя бы по три человека. Самый простой пример: если мы хотим протестировать мобильное приложение, то нам нужны две группы по разным платформам (iOS и Android), а также две группы по опыту (новички и пользователи аналогичных приложений). Это уже дает нам 12 человек.

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

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

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



Не переборщите. Приведя много аргументов в пользу увеличения выборки, хочу предостеречь от того, чтобы вы не ударились в обратную крайность. Помните, что мы говорим о качественном лабораторном исследовании. Редко для подобных проектов реально требуется больше 24 человек. В среднем 10–12 людей бывает достаточно, чтобы покрыть основные группы аудитории и найти большую часть проблем. Например, параметры демографии редко когда служат поводом сильно увеличить выборку.



Мифы и страхи



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



«А если ваш респондент — дурак?» Когда пользователь с трудом справляется с какой-то задачей или показывает неграмотность в каком-то аспекте, у команды, наблюдающей за тестом, часто возникает вопрос: «А может, это именно он такой идиот, а остальные нормальные?» Ответ прост: все моменты спорного поведения нужно проверять на других людях. Когда оказывается, что «тупит» не один, а много людей, сомнения исчезают. Так, на одном из тестов для команды сервиса постинга ссылок в соцсети стало шоком, что многие пользователи не умеют копировать ссылки из браузера. Чтобы поделиться статьей в соцсети, участники теста пытались копировать полный текст статьи, делились скриншотами или просто копировали название, говоря: «Ну, друг потом сам в интернете найдет». Первый подобный человек еще вызвал сомнения: возможно, такая неопытность характерна именно для него. Но после пятого пользователя все сомнения пропали.



Часть 3. Как?



Способы поиска



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



Специальные рекрутинговые агентства



Этот способ удобнее всего для самих исследователей, так как снимает с них массу головной боли. Однако и тут есть свои подводные камни. Во-первых, на него придется выбивать довольно большой бюджет, ведь работу агентства надо оплачивать. Кроме того, вы точно столкнетесь с проблемой «ходоков». Рынок маркетинговых исследований существует давно. И в этой отрасли сформировался целый пласт людей, которые пытаются зарабатывать на жизнь хождением на опросы, фокус-группы и т. д. Для этих людей самое главное — это получить вознаграждение. Часто они врут о своем опыте, чтобы подстроиться под квоты. А на самом тесте пытаются вести себя так, чтобы понравиться вам (и тогда вы позовете их еще раз). В результате они могут начать усиленно хвалить или усиленно ругать ваш продукт, ведь целей исследования они не понимают. Не так уж важно, каким образом они пытаются подстроить свое поведение. Главное, что оно становится неестественным. Способам бороться с этими людьми можно посвятить отдельную статью. Вот несколько советов:




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

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

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

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

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



Панели



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



Самостоятельный рекрутинг



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




  • Друзья и коллеги. Кинуть клич в Facebook или на корпоративном портале кажется одним из самых простых вариантов. Но мы уже обсуждали опасности тестирования на знакомых людях. Во-первых, в вашем окружении, скорее всего, окажется достаточно продвинутая аудитория. Во-вторых, им будет сложно открыто высказывать вам свое мнение. Тем не менее это всегда лучше, чем ничего.

  • Группа в соцсети / форум проекта. Это лояльная аудитория, заинтересованная в улучшении продукта. Их часто легче пригласить, чем других ваших пользователей, и они даже могут быть готовы поучаствовать в исследовании бесплатно. Но надо понимать, что это будут достаточно продвинутые пользователи вашего продукта. Скорее всего, они наиболее требовательны из всех и могут просить вас о функционале, который не нужен большинству. Кроме того, здесь легче всего поймать «фриков». Целесообразность рекрутинга через форум/группу зависит еще и от проекта. Например, для игр форум — хорошее место для рекрутинга активных лояльных игроков. А вот в проекте Дети Mail.Ru мы столкнулись с тем, что пользователи форума мало проводят времени на основном сайте и могут нам помочь только в тестировании самого форума.

  • Почтовая рассылка. Вы можете отправить своим пользователям письмо — приглашение на участие в исследовании. Этот вариант хорош тем, что рассылку можно таргетировать по определенным критериям (активность в проекте, география и прочее). Постарайтесь сделать текст письма достаточно личным и неформальным, это увеличит количество откликов. Обычно мы в письме даем ссылку на онлайн-опрос, проверяющий, подходит ли человек по критериям, а в конце опроса предлагаем оставить контактные данные. Но будьте готовы к тому, что отклик будет небольшой (процент зависит от лояльности аудитории, но больше, чем на 2–3%, я бы не рассчитывала). Кроме того, даже оставившие телефон люди могут в итоге не согласиться участвовать. А согласившись, испугаться и не прийти на интервью. В первый раз мы сильно удивились, когда явка при такой форме рекрутинга составила порядка 50% из назначенных интервью.

  • Баннер/форма на сайте. Также хороший вариант для рекрутинга. Баннер, как и ссылка в письме, должен вести на онлайн-опросник, где вы проверяете критерии подбора и собираете контактную информацию. Здорово, если вы сможете также показывать баннер только нужной для исследования аудитории: например, в интересующем вас разделе сайта или после определенных действий пользователя.

  • Группы по интересам. В случае, когда у вас еще нет своего продукта или вам интересны пользователи конкурентов, вы можете пробовать рекрутировать респондентов в тематических сообществах и группах (с согласия их администрации). Например, для тестирования некоторых игр мы публиковали объявления на новостном проекте Игры@Mail.Ru или в группе C-c-combo Breaker ВКонтакте.

  • «Снежный ком». Этим методом ищут респондентов полевые рекрутеры агентств. Они спрашивают у людей, которых уже приглашали на исследования, нет ли у них знакомых, которые согласились бы также поучаствовать в подобном мероприятии. Для того чтобы этот способ работал как основной метод поиска, нужно иметь достаточно большую базу контактов и потратить очень много времени. Однако никто не мешает вам спрашивать людей, которых вы уже нашли, нет ли у них подходящих знакомых, и рекрутировать так дополнительных респондентов. Главное, удостоверьтесь, что они не будут друг другу рассказывать о том, что происходило во время исследования, чтобы не испортить вам результаты. Также знакомых людей плохо звать на одно исследование, если вы не просто тестируете продукт, а собираете данные о разных паттернах поведения. Например, учащиеся одной студенческой группы, скорее всего, расскажут вам примерно одно и то же о том, как они пользуются электронной почтой по учебе.

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



Полевой рекрутинг



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



Организационные моменты



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




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

  • Дополнительные проверки. Как уже говорилось в блоке про рекрутинг при помощи внешнего агентства, данные респондентов лучше проверять. Эта рекомендация применима при любом виде рекрутинга. Старайтесь максимально проверить, правду ли говорит этот человек о своем опыте, до теста. Любые проверки, которые вы можете сделать заранее (дата регистрации, активность), лучше сделать. Ведь, как мы знаем, «everybody lies».

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

  • «Осторожно, дети!» Если участники вашего теста младше 18 лет, вам необходимо письменное согласие их родителей на участие в тестировании. Согласовывать детали участия детей в исследовании всегда надо именно с родителями. Мы сталкивались с ситуациями, когда, придя на этнографическое интервью домой к подростку, обнаруживали, что родители не в курсе и против.

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

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



Заключение



Поиск респондентов для исследования — это всегда чуть ли не самая хлопотная часть всего мероприятия. Но это та часть, где точно нельзя «халтурить», и тот самый случай, где лучше меньше, да лучше. Совершенно нормально, когда исследователь стремится скинуть с себя заботы о договоренностях по времени и напоминания респондентам на секретаря или агентство. Но никогда не пренебрегайте этапом планирования того, кто вам нужен, и проверкой респондентов. И тогда ваши исследования принесут команде проекта новые знания.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/304720/

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

[recovery mode] Разработка этапы, ошибки и преимущества

Суббота, 02 Июля 2016 г. 19:04 (ссылка)

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







Постановка задачи



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



Составление технического задания.



Техническое задание это документ в котором описаны все возможности программного обеспечения, утрированный пример:



Создание интернет магазина



Написать интернет магазин с возможностью добавлять категории, добавлять товар по категории с картинкой и описанием.



Участники системы:

1) Администратор

2) Покупатель



Возможности пользователей



Возможности администратора:

1) Добавлять удалять и редактировать категории

2) Добавлять удалять и редактировать товары

3) Добавлять удалять и редактировать заявки на покупку товара



Возможности пользователя/покупателя

1) Добавлять товар в корзину

2) Оформлять покупку



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



Давайте рассмотрим подробнее и разобьем на этапы:

1) Рисование и верстка дизайна.

2) Проектирование базы данных.

3) Проектировние архитектуры.

4) Написание программного кода.

5) Написание базы данных.а

6) Покупка хостинга и домена.

7) Продвижение сайта.



А если мы захотим, добавить еще 2 возможности:

1) Регистрация пользователя

2) Пользователь может добавлять товары



Вроде бы отличие в двух строчках, но это уже не интернет магазин, а задача может перерости в сервис на подобии avito, alibaba, а сроки и сложность возрасти в разы (таблиц станет не 5-10, а 100).



Ошибки в проектировании примеры:

Часто сроки сложность и стоимость разработки может увеличиваться из за ошибок в архитектуре и постановке задачи, примеры:



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



2) Была неправильно смоделирована база данных, необходимо добавить несколько полей и изменить программный код.



3) Неправильно составлено техническое задание: необходимо полное переписывание.



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



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



Правильный выбор инструментов для разработки

1) IDE — во многих современных средах разработки предусмотрен: автокоплит (автоматическое дополнение кода), интеграция с системой контроля версий, сестемами сборки версий, подсказки об ошибках, интерграция с системами тестирования, интеграция с системами дебага.

2) Система контроля версий: снижает риски потерять программный код, дает возможность командной разработки, дает возможность разделять код на ветки, дате возможность восстанавливать старые версии кода.

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

4) Фреймворк: позволяет ускорить разработку, позволяет разделить логику, может иметь специфический набор возможностей для ваших задач.

5) Выбор языка и базы данных тут рассматриваться не будет — лично мое мнени их нужно выбирать от задачи.



Итеративная и командная разработка и ошибки

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

1) Первый решил поменять модель, так что бы появилась возможность выводить и отслеживать дату создания.

2) Второй решил исправить регистрацию.

3) Третий менял дизайн.

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



Внедрение тестирования

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



Выгоды рефакторинга

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



Правильная постановка сроков



За сколько вы создадите типовой интернет магазин? У вас все настроенное, вы давно работаете, в совершенстве владеете языками и системами управления контента и работаете командой. 5 дней может быть неделя (качественного отказоустойччивого приложения вы за этот срок неполучите)? Смело умножайте на 2, для того что бы учесть форсмажоры и избежать конфликтов.



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

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

https://habrahabr.ru/post/304598/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
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)КомментироватьВ цитатник или сообщество

Следующие 30  »

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

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

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