понедельник, 31 марта 2014 г.

Lesson Learned in Software Testing


Получила я ее так :)

Мои выдержки из книги:
Особенно порадовала часть 7 - Interaction with Programmers. Нет, я серьезно! Со многими вещами согласна, многое хотелось запостить полностью или хотя бы затвитить!

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

Книга сильно отличается от тех, которые советуют читать новичкам - которые берешь и читаешь запоем. Тут так нельзя. Надо по чуть-чуть, по 1-2 совета в день, как советуют сами авторы.

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

В общем, я честно старалась следовать советам авторов, поэтому читала книгу больше года Smile :)

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

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

PS - Добавила книгу в общий список прочитанных мною книг.

четверг, 27 марта 2014 г.

Как тестируют в Google? Джеймс Уиттакер и компания

Ссылка на OZON.

Ну вот и моя очередь поделиться впечатлениями об этой книжке Smile :)

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

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

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

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

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

Наверное, потому, что в моей команде тоже все думают о качестве и эта мысль меня не удивила. За 2 года в этой компании я уже привыкла считать это нормальным, принимать как данность Smile :)

А вот активная нехватка народа появилась не так давно! Хотя, может, это и к лучшему? Уиттакер рассказывает о том, что, когда к ним приходят тест-менеджеры, они хватаются за голову "нам не хватает людей!". А остальные смотрят и посмеиваются. Они то знают, что это - нормально!

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

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

Также в книжке расписывается, как проводятся собеседования на разные роли. Понравилось разделение качеств "вы подойдете на роль разработчика в тестировании, если... А на должность инженера по качеству, если..." Очень любопытные списки ))) Но я таки - тестировщик! Однозначно!

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

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

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

А еще я начиталась там рекламы об инструментах гугла, которые они или уже отдали в открытый доступ, или собираются отдать. Ух какие инструменты! Полезнейшая вещь при тестировании web-приложений. Это и роботы, которые вместо вас гоняют унылую кроссбраузерность. И помощник в оформлении багов, который за тебя аттачит всю инфу о браузере и системе + js-скрипт, которым можно воспроизвести ошибку.

В общем, если вам любопытно, "а как оно устроено у других", а денег на конференцию нет, то читайте книги! Ведь если учиться, то только у лучших! Smile :)

PS - Добавила книгу в общий список прочитанных мною книг.

вторник, 25 марта 2014 г.

Rocket Science или etl средствами bash (Видео!)

Во время нашей конференции Education Day Максим Боков, наш гуру линукса, рассказывал о средствах bash, полезных для построения ETL (Extract, Transform, Load) процесса.



Продолжительность записи - 21 минута.

Если вы плохо разбираетесь в линуксе, обязательно посмотрите это видео, хотя бы для общего развития Smile :)

Здесь вы услышите про:
  • Потоки.
  • Стандартные переменные.
  • Циклы.
  • Регэкспы
  • И многое, многое другое!
А для тех, кто уже видел видео, отдельно выложенная презенташечка - эдакая шпаргалка!
Наслаждайтесь Smile :)


воскресенье, 23 марта 2014 г.

Люксор, бронь билетов. Usability-кейс, как НЕ надо делать

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

Итак, открываем сайт - http://www.luxorfilm.ru/cinema/center/
Выбираем любой сеанс и щелкаем на него (снизу услужливо подсвечиваются цены). Тут все хорошо, красиво и вполне usability-пригодно!


Далее мы:
  1. Выбираем места, на которых хотим сидеть.
  2. Подтверждаем условия соглашения.
  3. Нажимаем Бронировать


И вот тут начинается самое интересное!

Раньше было как:

Нажал "Бронировать" и тут же вылезло всплывающее окошко, куда надо было ввести Фамилию и телефон. На этот телефон после сохранения приходила смс с номером брони. Приезжаешь в кинотеатр, называешь номер брони (который всегда с собой - в смске) и фамилию.

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

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

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

Но форму брони переделали. Теперь, после выполнения трех шагов, описанных выше, просто появляется сообщение с номером вашей брони.


Казалось бы, все стало проще, без регистрации как с ней - все в один клик! Классно? Нет, не очень...

А все почему? Потому что продумали только то, как сделать проще. А пройти пользовательский сценарий не прошли.

Я действую даже не как тестировщик, а как простой пользователь сайта. Я знаю, чего мне ожидать (того самого окошка, ага), нажимаю "Бронировать" и тут внимание! Ничего не меняется. Точнее, сверху на названии вкладки хром начинает отрисовывать загрузку контента, но я как пользователь туда не смотрю. Я нажала на кнопку, мышка не перешла из указателя в часики ожидания. Кнопка брони не заблокирована, ничего не происходит. Что я думаю? Правильно, что кнопка не нажалась. И-и-и-и... Кликаю на нее еще раз! И вдруг УПС


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

И теперь этот номер брони я не узнаю никак. Потому что, если нажать "назад", это не поможет. Что это с точки зрения пользователя? Самый очевидный БАГ! Просто простой пользователь не знает, что это так называется. А я знаю!

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

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

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

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

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

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

А ведь проблема решается элементарно - после нажатия на кнопку "Бронировать" ее надо блокировать. Тогда пользователь хоть 10 раз в нее яростно потыкает, ожидая, когда страница прогрузится. Он все равно увидит свой номер брони, а не эту нелепую ошибку. Вот и все! Почему же разработчики это никак не сделают? Sad :(

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

Хорошо, когда команда разработки сама пользуется тем, что она создает. Это правда помогает! Вот попробовали бы пару раз забронировать билеты и сразу нашли бы проблему. И пофиксили. А так - страдайте, люди, мы пришли к выводу, что вам так удобнее Sad :(

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

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

PS — добавила пост в общую копилку багов.

среда, 19 марта 2014 г.

ВИДЕО! Тест-дизайн на примере треугольника, типы границ

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


Смотреть на youtube.

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

понедельник, 17 марта 2014 г.

HFLabs Education Day: даешь внутрикомпанейский обмен знаниями!

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

Ведь вы работаете бок о бок, многие над одним и тем же проектом, так что ситуация "ну это все круто, а как применять?" практически исключена! Если рассказывать только о практике работы в компании Smile :)

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


Программа

Вот, посмотрите, какая программа у нас в итоге получилась!
(Некоторые названия вскоре станут гиперссылками на видео)
  • Проектирование интерфейсов: кому, зачем и как.
  • Матчасть киберпанка (public key infrastructure).
  • Практическое применение различных инструментов в работе с большими и очень большими данными.
  • Настройка гетерогенных сервисов между Oracle и mssql/excel/dbf.
  • InfoSphere Master Data Management глазами разработчика: возможности и настройка.
  • Разновидности облачных и околооблачных сервисов.
  • Анализ данных (логов) с помощью grep, awk, R.
  • Про rspec и Cucumber.
  • Rocket Science или etl средствами bash.
  • Тест-дизайн на примере треугольнике.
  • Админ спит — служба идёт, или «Прикольная автоматизация» (Graylog, Rundeck, Xen).
  • Про Hadoop.
  • Галопом по Табло (основы работы с Tableau Software).
  • Аутсорсинг и аутстаффинг на практике.
  • Риски, которые превратились в грабли.
Формат

Конференция длится целый день. Посещение докладов — по желанию, не обязательное. НО!
Участвуют только те, кто делают доклады. Этот пункт подстегнул выступить даже тех коллег, которые не очень любят общаться публично ))

Участники выкладывают в confluence (наша корпоративная википедия) список тем, на которые они готовы выступить. Остальные участники (только те, кто тоже будет выступать, что важно!) голосуют за доклады. Какой набрал больше всего голосов - на ту тему и готовится выступление.

Доклад должен быть коротким - 15 минут рассказ, 5 минут отводится на вопросы.

После каждых трех докладов идет перерыв на 15 минут.
В середине устраивается обед.
Дело происходит в офисе HFLabs.

Все доклады записываются на видео и потом выкладываются на корпоративную вики для потомков. Некоторые, с согласия авторов, будут опубликованы официально, ждите Smile :)

понедельник, 10 марта 2014 г.

Выступление в стиле TED. Джереми Донован


Ссылка на OZON.

Еще одна книга про то, как делать презентации, которые захватывают дух.

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

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

Книга небольшая, шрифт крупный, читается быстро и легко. Разделена на 2 важные части - Содержание, структура и формат и Подача материала.

2 части, 14 глав. Каждая глава раскрывает один из вопросов подготовки к докладу, например, "как начинать выступление". В конце каждой главы - краткое резюме.

Главная фишечка книги - это подготовка именно к TED, все примеры рассматриваются из этой конференции, что очень увлекательно!

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

Читаешь каждую главу и прикидываешь на свой доклад - ага, а вот это я сделал? А это? А это? А это мне нужно? Тогда такая книжка будет мега-полезной и мега-эффективной! Иначе никак)

PS - Добавила книгу в общий список прочитанных мною книг.

вторник, 4 марта 2014 г.

Всегда ли нужна ручная регрессия? Жизнь_боль как двигатель прогресса

Всегда ли нужна ручная регрессия?

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

Автоматизация - это круто. Но даже если все тесты проходят, это не дает 100% гарантии, что и вручную все будет работать. Поэтому и нужна такая проверка. Представляем себя пользователем и идем проверять его сценарии. Вручную!


Но в каком объеме проводить ручную регрессию?

Я сейчас читаю Как тестируют в google и там сквозь всю книжку проходит мысль - Нас мало и это здорово! Нам постоянно не хватает людей. Но зато в условиях нехватки времени отсеивается все лишнее, инженеры сосредатачиваются только на том, что действительно важно и не тратят время на ненужные тесты. Дефицит порождает оптимизацию!

А нам сейчас тоже вечно не хватает людей. А может, оно и к лучшему? Smile :)

Хочу поведать о нашей оптимизации времени, которое тратится на регрессию. Которая возникла как раз из-за нехватки ресурсов!

Немного предисловия - мы разрабатываем продукт, кастомизируемый под каждого Заказчика. То есть есть main часть проекта и есть проекты Заказчиков. Когда разработчик или тестировщик хочет собрать билд, он собирает сначала main билд, потом уже какой-то конкретный.

У нас много автоматизированных тестов на уровне API, которые покрывают (или стараются покрывать) всю основную функциональность продукта. Про наши тесты я рассказывала на SQA Days 14, там можно посмотреть подробнее.

Однако наличие автотестов не освобождает от ручной регрессии. И вот почему:
  • Автотеста на баг может не быть - когда тестировщик проверяет вручную, он исследует продукт. У нас есть на это время как раз за счет автотестов, нам не надо каждый раз выполнять одни и те же нудные операции с разными комбинациями входных данных. Все это уже покрыто в тестах. Так что достаточно пройтись по основным позитивным сценариям, а дальше искать там, куда приведет вдохновение. Бывает, что находятся ошибки, а проверка кода показывает - такого теста еще нет.
  • Автотест есть, он даже проходит. А вручную падает! Тесты на уровне API - это хорошо и практично, но они проверяют работу сервера, а сломаться может клиент.
  • Проверка GUI - вытекает из прошлого пункта. На отображение GUI автотестов как раз нет (дорого и пока того не стоит). Баги там находятся очень редко, поэтому проще прокликать 1 раз в 3 недели, чем пытаться заавтоматизировать.
Таким образом, что нам дает автоматизация - вместо того, чтобы 2 полноценных дня тестировщик сидел и начинал тихо ненавидеть повторяющиеся из раза в раз обязательные сценарии, он занимается более интересными делами. Рутину на себя берет робот, а тестировщик тратит на нее пару часов, а дальше начинает исследовать. Что, конечно, гораздо интереснее!

Подход себя полностью оправдывал... До определенного момента. Что же случилось?

Итак, у нас есть около 3 Заказчиков и примерно столько же тестировщиков. Подходит время выпуска релиза, тестировщики делят регрессию и погнали! День потестили и начались поставки. С учетом всяких рисков - 2 дня, ок.

Вроде бы нормально. Однако время не стоит на месте и количество Заказчиков только растет. А тестировщиков, увы, уменьшается. Кто-то переходит в разработку. Кто-то во внедрение... И вот мы уже тратим по 3-4 дня на ручную (!) регрессию. При этом "мы" - это два замыленных тестировщика, которые пытаются все-все-все успеть и очень сожалеют, что им не хватает времени.

Так пришел дефицит. Мучились мы, мучились. Как-то надоело. Посмотрели внимательнее на наши проекты - а ведь во многом они похожи! Конечно, везде своя специфика, но общие части есть! Ага, хорошо.

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

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

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

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

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

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

Конечно, воплощение идеи в реальность заняло какое-то время. Тогда еще это было примерно как "в первый раз в первый класс" и создание нового Заказчика занимало много времени. Ведь это делается не так часто. А тратить драгоценное время коллег, которые и так очень сильно загружены?

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

А теперь Заказчиков стало еще больше и мы уже слабо представляем себе, как бы мы жили и дальше без нашего волшебного Демо-Заказчика!

Так что, как оказалось, дефицит и правда пошел нам на пользу. Хотя вначале всегда кажется наоборот, именно ситуации в стиле жизнь_боль двигают нас в правильном направлении Smile :)

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

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

Потому что если что-то делаешь один раз, можно смириться. Но если из раза в раз ты повторяешь одно и то же, возникает желание это что-то заавтоматизировать. Или упростить. Ну хоть что-то с этим сделать! И делаем. А потом наслаждаемся результатами. Результатами оптимизации из-за дефицита!

Лень - двигатель прогреса, что ни говори!
А если вы сейчас очень страдает от дефицита тестировщиков, то задумайтесь, может, оно и к лучшему, а? Wink ;)