Поскольку я вижу уже несколько записей на стене друзей, то большой привет Клубу тестировщиков, проверяйте свои посты :) Сделать это можно через “View As” на странице профайла (клик на свое имя).

В этот раз “вредоносная” ссылка маскируется под видео с названием “This girl has a Spider living under her
skin!! She’s probably the Spider-Man’s daugther.”

При клике пользователя перекидывает на apps.facebook.com/ctelestatus/spider/ откуда идет редирект на checkthevideo.info/spider/, который активно прикидывается Фейсбуком (подгружаются стили и комментарии к видео), но самого видео естественно нет.

Так же из кода подгружается файл whos.amung.us/widget/7h7swqytuump.pnh (допускаю, что имя может меняться), который редиректит на widgets.amung.us/classic/21/2145.png.

В завершение грузится скрипт checkthevideo.info/spider/cglfb.js?x=1314951387, который и реализует кликджекинг, в результате которого в Newsfeed попадает лайк на страничку с этим же самым скриптом и становится виден всем друзьям (ну на самом деле не всем, но это детали).

Насколько я могу судить ничего особенного пока не происходит. Хотя меня смущает загрузка скрипта checkthevideo.info/spider/js/swfobject.js, которого нет на сервере и файла 2145.png (который, как я вижу просто PNG). Не понятно зачем он нужен. Для статистики как-то глупо, а по поиску ничего особенного не находится, RFC 2145 ни о чем, и еще есть  диссертация на тему ”The United States Military Occupation Of Okinawa”, но это как то совсем далеко.

На SWRUS 2011 поехать не получилось, Григ улетел на MacWorld в Китай, а я к моменту старта конференции только только вернулся из Испании. Впереди поездка в Хьюстон, но тело противится двенадцатичасовому перелету.

Очень близко познакомился с Amazon EC и использованием их виртуалок для нагрузочного тестирования. Мне нужно было поднять и настроить тестовое окружение (все компоненты тестируемой системы) и генераторы нагрузки на 4000+ инстансах. Осложнялась задача не только некоторыми проблемами с возможностями Amazon, но и динамическим окружением, из-за которого пришлось рализовать легкое подобие Bonjour. Заметку еще не закончил, приходится довольно аккуратно описывыть работу не нарушая NDA. Вместе с тем обнаружился относительно простой способ эмулировать до 64К хостов всего лишь с помощью 2х серверов.

Прошлые выпуски: 3, 2, 1

Не так давно, по весне, после очередного стартап побоища, на которые стоит ходить за атмосферой и волшебным толчком в область мотивации, мы с Гришей отправились посидеть в уютной жжшечке кафешечке и обговорить несколько идей, которые подбросила наша креативная группа, отказавшаяся тратить время на «сомнительные сборища». Наши товарищи разрабатывали идею простенькой игрушки, эдакого первого блина, просто посмотреть на что мы способны в геймдеве. Хотя в арсенале ALSEDI есть несколько игр, в том числе сделанная по лицензии Warlords Classic, но это всё-таки не совсем то, что мы хотели попробовать.

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

Поискав наткнулись вот на таких товарищей и еще батальон прочих зайцев.

Не сильно нам подходили для проекта, но в памяти засели. Прошло несколько недель после этого и Григ показал новый продукт, который он назвал Rabbit Clock, а все картинки для него (как не сложно догадаться) предоставил автор этих самых зайцев. Опять-таки началось все с простого письма Грига. Сейчас Rabbit Clock существует в двух версиях, с разным набором этих самых зайцев. Проект получился не очень успешным, но на этом история не закончилась. Во время поиска, кроме зайцев, у этого автора попадались вариации вот такой вот птички.

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

То, что мы были поражены, это еще слабо сказано. Как оказалось Григ заручился поддержкой Саймона Оксли (Simon Oxley), хорошо известного дизайнера, работы которого не ограничиваются птичкой. Часть его графических работ мелькала в сериале Lost, а часть печатается на бамперах для iOS устройств. Саймон оказался человеком весьма контактным и интересным, последние его работы поражают меня постоянно. Меж тем вышел еще один проект совместно с ним – Simon Day. Бесплатное приложение для iOS, каждый день дающее доступ к одной новой работе Саймона.

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

На этот раз, в апдейт вошли очень интересные дополнения:

1. Изменена работа с тест кейсами.

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

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

3. Произошло очень интересное изменение правил компенсации. Раньше оплата была условно фиксированной по типам багов. Условно, потому что рейт мог в любой момент поменяться на меньший, либо при нахождении чего-то значимого кастомер мог поощрить тестировщика и выписать бонус. Наибольшим рейтом чаще всего обладали технические баги. Из-за достаточно расплывчатой классификации и рейта множество ошибок заносились как технические. Спекуляция? О, да. Однако, только в вопиющих случаях тип бага менялся на правильный. Так же большинство такого рода багов были не слишком интересны кастомеру. Эта проблема более менее решалась стандартными стредствами. Если баг существовал, но был не слишком интересен, но при этом всё-таки в контексте тестирования, то его переводили в статус фидбека ($2-$3 рейт, против $6-$10 за технических). Теперь все рейты уравнены. К этому рейту кастомер (я так понимаю, что и менеджер проекта) сможет добавить $4, если баг окажется интересным, и $8, если кастомер от счастья заплачет. В целом оценка будет более чем субъективная, но, на мой взгляд, идея правильная и больше всё-таки ударит по Gold/Silver/Bronze тестировщикам.  Так как базовый рейт будет снижен, то процентный плюс “за рейтинг” будет также ниже.

Специальные Бонусы, MVT, оплата за тест кейсы остаётся без изменений.

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

9 и 10 июля пройдет международное соревнование по програмированию DjangoDash 2011. К нам обратились представители компании е-Легион, которые выставляют команду для участия в этом соревновании. И при этом они не просто собираются участвовать, но и сделать из этого реалити-шоу. А ещё им очень не помешает помощь тестировщиков, поэтому мы обращаемся ко всем:

Поддержите коллег по цеху, помогите им сделать более качественное и удобное приложение!

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

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

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

В целом, создается впечатление, что на uTest есть серьезный недостаток новых активных тестировщиков. За последние два месяца в тридцати различных тестовых циклах я увидел максимум дюжину новых людей, в основном пашут Gold/Silver тестеры. Получается, что построив хороший бизнес по тестированию и собрав костяк, который обеспечивает некоторые потребности uTest немного ушел от модели краудсорсинга и теперь пытается воостановить баланс. В том числе, на мой взгляд, из-за этого появилась новая позиция в проектах Test Team Leader и обновился состав модераторов на форуме, об этом не так давно писал Роман. Кстати, я считаю большим успехом то, что он стал одним из новых модераторов. По каким то причинам uTest не сильно заинтересован в Российских тестировщиках и не активно продвигается на нашем рынке, а количество доступных тестовых циклов сильно меньше, чем для индусов (и уж тем более для американцев). Вернее не хватает циклов с высокими рейтами (рейт $10 за баг не высокий), а так же с гарантированной оплатой, как ни крути, а в условиях uTest это лучше всего мотивирует к активной работе.

“У меня есть фееерические рассказать о том, где сейчас вкусно и по отношению к специалистам. Где можно вырасти, Где дают участвовать в постановке процессов. cпрашивайте!”

HR крупной компании

Тестировать нужно будет из консоли и из браузера, задействована БД и Linux, поэтому знание SQL на уровне SELECT * FROM A WHERE, JOIN необходимы. В консоле придется ползать по множеству серверов, обеспечивающих инфраструктуру и много копаться в логах и без знания и умения использовать cat, less, grep/egrep, sed и в целом bash не обойтись. Знание работы распределенных систем и HTTP будет плюсом. Опуская подробности организационной структуры работать придется со мной. Из забавных технологий IPv6, довольно элегантное решение для клиентского оборудования (ага – не всё SaaS находится в одном месте), виртуализация в полный рост.

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

Компенсация, плюшки и бонусы обсуждаются на собеседование. Резюме можно присылать прямо мне rook.uinc@gmail.com, можно добавиться в LinkedIn: http://ru.linkedin.com/in/alexsergeev

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

Порядок в списке, не означает приоритет.

1. Бизнес- или девелоперская документация по продукту или проекту. Самый простой (когда есть) и распространённый способ, наровне со вторым – по готовому коду. Все знают – берём юзер мануал, RTO, ТЗ, продумываем сценарий, описываем шаги и реакции. Не самый эффективный вариант, если не практикуется TDD, потому что очень часто код меняется, что то добавляется, что то уходит и тест кейсы написанные ранее перестают быть актуальными. Даже поставленный процесс не гарантирует сохранения актуальности, а лишь уменьшает риск. Поэтому в таких тесткейсах чем меньше деталей, тем лучше – основной упор можно сделать на путь, который необходимо пройти и бизнес-критичных результатах.

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

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

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

5. Гайдлайны. Те, которые предоставляют Microsoft, Apple, Google и прочие производители средств разработки и исполнения приложений. Перекликается с четвёртым пунктом, но легче, – не требует глубокого знания области (понимания требует, но знание не существенно), тесткейсы на их основе легче аргументируются и лояльно воспринимаются разработчиками, дизайнерами и прочими любителями сделать фишечку в интерфейсе графическом или программном от которой пользователи впадают в ступор. Минус в том, что покрытие приличное ими не гарантируешь и проверяется соответствие каким то внешним условиям, а не соответствие продукта его основному предназначению. Так же гайдлайны часто очень детальные и трудно адаптируемые к ручному тестированию из-за своей точности, а вот для автоматизированного в самый раз.

6. Best practices. Адаптация чужого знания и опыта к какой-либо части разрабатываемого продукта. Заменяет гайдлайны, когда их нет. Плюсы – минусы теже.

7. С потолка. Иногда и так. Особенно в стартапах, когда не всегда и не все известно как должно работать. Например, как оценить новый геймплей? Функционально да, можно, а вот саму идеереализацию геймплея? Юзабилити тут ни при чем.  В итоге появляется договорённость о том, что мы считаем правильным. Это по сути источник для регрессионных тестов и тестов, которые позволяют оценить вектор изменения будущих версий относительно предыдущих (а это уже в юзабилити в том числе).

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