суббота, 24 мая 2014 г.

Отчет о конференции AnalystDays-3

24 мая в Москве прошла очередная конференция аналитиков, на которой мне удалось побывать в новой "шкуре" - волонтера. Работа это отдельная история, но писать я смогу только из зала А, в котором находилась весь день.

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

Теперь о самих докладах.

Григорий Печенкин
Горе от системного ума

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

Константин Быченков
Аналитик- первый  помощник "большого босса"
Очень крутой доклад Кости. Я даже не буду особо спойлерить, просто посмотрите. 

Наталия Желнова
Оценка эффективности работы аналитика

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

Игорь Архипов
Как стать СВАР: советы и рекомендации

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

Сергей Рассамакин
Интеллект-карты

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

Дмитрий Безуглов
Переосмысление роли аналитика

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

Юлия Ерина
Клинический случай в коммуникациях с заказчиком

Юля сделала очень бодрый доклад, частично перекликающийся с нашим докладом на SQADays#15. Юля категорически против скайпа, хотя есть исключения. Что и требовалось доказать - любое общение с заказчиком должно быть задокументировано.

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

Елизавета Батурина
Классические ошибки при разработке

Снова о государственных проектах тонкою строкой толстого троллинга. У меня уже складывается ощущение, что гос.службы с своими ГОСТ-ами просто присосались к бедной и измученной крови айтишников. Сколько ж можно издеваться то... ох.. Тысячи подписей, кучи документов.. И все это.. ад. И точка. Хотя Елизавета и говорит, что ничего нового в докладе не открыла и не предложила, думаю, что новичкам будет весьма полезно его послушать. 

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

Вобщем, большая часть докладов в моем зале мне понравилась. И, даже доклад Безуглого Димы, хотя сам формат проведения МК мне не понравился. Ну и к опозданиям докладчиков я отношусь весьма категорично.

А фото, видео и прочие штучки будут позже) Докидаю сюда ссылочки потом.

ИТОГ: конференция прошла на отлично!

UPDATE: Лучшие докладчики конференции по итогам анкет участников:

Юлия Ерина
Артем Митропольский
Татьяна Васильева

среда, 21 мая 2014 г.

Кроссбраузерность вручную:Тысячи тестов за несколько часов.


Еще одна моя статья из журнала Tester's Life  (выпуска Август" 2013)
Немного предыстории 
Не так давно в нашей компании было принято решение интегрировать имеющийся проект в разные социальные сети и вопрос о кросс-платформенности и кросс-браузерности появился в виде огромной горы на моем пути, а я оказалась перед ней без экипировки альпиниста.
Ниже я расскажу, какие были проблемы, как они решались, какие применялись инструменты, методы и подходы, как велся подсчет количества тестов, как нам удалось сократить их с почти 6000 до менее 450, и на что вам стоит обращать внимание при проведении такого тестирования.

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

Быстрое разочарование...

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

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

проблема 2. 

Всем, наверное, знакомо приложение IE Tester, вот и я решила попробовать его использовать, к тому же необходимо было проверить корректность запуска проекта Империя в Facebook в браузере Internet Explorer 6.
Запустила IE Tester, выбрала версию IE 6, в которой нужно было открыть наше приложение в Facebook. Но в итоге я получила квадрат а-ля Малевич, только белого цвета с непонятными циферками. Не только нашегоприложения не увидела, а и сам Facebook не открылся.
 Через несколько недель после этого появились статьи о том, что Facebook отказывается от поддержки браузера IE 6. Я решила не отчаиваться, и пошла на поиски других бесплатных приложений.

LunASCAPE 6
Этот инструмент нельзя назвать традиционным средством для кросс-браузерного тестирования, он больше полезен для программистов и дизайнеров, да и весьма сложен в применении.
Вердикт
для необходимого нам тестане подходит.
SAuCELABS
В принципе абы как подходит для тестирования. Абы как потому что работает он ооооочень медленно.
Вердикт
времени нет на долгую обработку одного запроса.
SuPER PREVIEW
Можно проверить работу приложения в интерактивном режиме просмотра страницы. Неплохой инструмент в целом, но немного виснет периодически.
Вердикт
подх одит частично

просвещение

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

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

Начинаем рисковать
В данной ситуации без рисков не обойтись. Первый риск, который я на себя взялаотбросила малоизвестные браузеры, которые в приличном количестве выдал поиск
Google, и наименее используемые операционные системы.
Теперь уже можно было подсчитать количество тестов:
Берем известные браузеры и все их версии.
Также берем все наиболее используемые операционные системы и все их подвиды: Windows 7 (Basic,Home и пр.), Windows Vista (все ее разновидности), Windows XP (Home, Professional и т.д.), Linux, Mac OS.
Учитываем три социальные сети, в которых нам надо проводить проверки.
Все это перемножаем между собой и на количество необходимых проверок по тест-кейсу.
Например: Браузер Mozilla Firefox – 19 версий, перемножаем на все виды ОС Windows перемножаем еще на 2 (32 и 64 бит). Затем делаем тоже самое с Windows Vista. Все полученные цифры складываем.
По итогу у нас получилось около 6 тысяч тест-кейсов, которые необходимо пройти.
Было понятно, что такое тестирование растянется на месяцы. А их у меня не было. Был от силы 1 день. А если честно смотреть на поставленные сроки 4-6 часов максимум.
Следующий шаг заключался в сборе и анализе статистики использования браузеров и ОС нашими пользователями (по внутренним данным проекта). По результатам был составлен топ-5 браузеров и топ-3 операционных систем 

Операционные системы:
·         Windows7 
·         Windows XP
·         Mac OS

Браузеры
o    Mozilla Firefox.
o    Google Chrome.
o    Internet Explorer.
o    Opera.
o     Safari.

Количество тестов уменьшилось в 2 раза и сос тавило около 3 тысяч тестов. Но даже если 1 тест = 1 минута, то 3 000 минут≈ 6 дней. А 6 дней на тестирование у нас нет
Совет:
для отбора приоритетных версий используйте:
различную статистику в интернете
данные из статистики блогов (например,в Blogger–е).
если у вас нет личного блога,обратитесь к друзьям
показатели из вашего внутреннего баг-трекера от пользователей, и так далее


уменьшаем в 20 раз!

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


 операционные системы:
Операционная система Windows 7 Basic от Windows 7 Home вряд ли имеет какие-либо технические различия, которые позволят выявить какой-то баг, еще сомнительней, что это будет критичный баг. Поэтому для тестирования берем только 1 версию (лучше наиболее полную) операционной системы Windows 7.
По аналогии поступаем и с остальными ОС

версии браузеров:

• Самая популярная версия.
• Самая последняя версия.
• Версия, на которой тестировали в предыдущий раз
(если тестировали).

Например:
Mozilla Firefox версии 10 / 19 / 3,6

версии FLASH

•Версия, на которой тестировали прошлый раз (на случай, если пользователь не обновился).
•Версия, которая является последней на момент необходимости тестирования.
•Промежуточная версия (если была). Данная версия берется на случай если пользователь обновил следующую версию, которую мы не проверяли, но не
обновился еще до последней.Обычно получается 2 версии, т.к. промежуточная
версия Flash для тестирования берется редко

алгоритм тестирования

посмотрим на примере нашего приложения.
После определения тестового окружения мы получили следующий набор:
• Социальные сети: Вконтакте, Одноклассники, Facebook.
• Операционные системы: Windows 7, Windows XP, Mac OS.
По 3 версии каждого браузера: Mozilla Firefoх, Google Chrome, Internet Explorer, Opera, Safari.
• 2 версии клиента Adobe Flash.

подход к тестированию:

Берем операционную систему Windows 7 (как самую популярную) + Flash последний (так как его вы еще не проверяли) и ставим минимальные версии всех браузеров (это для дальнейшего удобства).

1. Заходим с каждого браузера в каждую социальную сеть. Ставим наше приложение себе на аккаунт и пытаемся в него зайти (по необходимости можно проверить самые критичные части функционала).
2. Далее обновляем каждый браузер до следующей нужной версии и повторяем первый шаг.
3. И так до тех пор, пока не выполним все проверки

подведем итоги

Если вы перемножите все варианты тестов из описанного примера подхода к тестированию, то получите вместо 3 тысяч тестов– около 450 для тестирования
кросс-браузерности/кросс-платформенности, это количество, которое реально проверить за несколько часов.

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

совет

•не брезгуйте никакой статистикой.

отслеживайте, собирайте, используйте.

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

•не делайте лишних тестов.

•тестируйте свое приложение, а не окружающую среду.