С новым годом! 2015 на носу

С наступающим на пятки новым годом, дорогие коллеги! 

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

Подведу итоги 2014 года в разных проф сферах.

Работа

Заказчики довольны, на поддержку времени ушло меньше, чем в прошлый год. А хочется еще меньше! Будем совершенствоваться :)

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

Тренер

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

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

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

Testbase — сайт для начинающих

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

Идея сделать сайт именно для новичков была давно. Еще 1,5 года назад мы говорили "да да, классная идея, давайте сделаем!". И... не делали. Находились другие, более важные дела.

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

Это оказалось нелегко, статью про тест-кейсы я писала недели две. Сначала писала, потом отдала коллеге на редактирование, начали исправлять, убирать лишнее... Это вам не "пришел вечером домой, решил написать статью и к утру готово"! Но мы сдвинулись с мертвой точки!

Ближе к концу года мы решили запускать сайт "как есть", постепенно его наполняя. План-минимум стал:

• Статья "Как стать тестировщиком, с чего начать"
• Минимально расписать главные навыки тестировщика.

И мы сделали это!

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

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

А главное — этот сайт вдохновляет 

Вдохновляет продолжать писать, писать в информационном стиле. Я еще буду им гордиться, вот увидите 

И не только я, ведь у нас есть еще замечательный разработчик и Алексей Баранцев, создатель самого популярного сайта среди тестировщиков http://software-testing.ru/, который взял на себя всю орг работу по testbase. Будем вместе им гордиться! :)

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

Обучение

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

В этом году я посетила тренинг по инфостилю и замечательную конференцию SQA Days 16. Правда, только в роли слушателя. Теперь в планах опять выступать! Надо, надо хоть раз в годик...

Так что пометочка стоит, конференции посещать, в роли докладчика побывать, книжки продолжать читать!

Кстати, про книжки. Я, конечно, не Наталья Руколь с ее челенджем, но тоже много всего прочитала! Горжусь тем, что вернулась к практике "домашних книг" — обычно я читаю в метро, но есть книги неудобного формата (А4 или квадратные такие, тоже большие), есть книги на английском, которые хочется читать дома, в тишине и в переводчиком под боком.

Я дочитала "Изучаем Java"! Толстая книжка-тренинг, которую я читала, выполняя все ДЗ, набивая весь код, который видела. Читала долго и вот — дочитала. Нашла время, решила хотя бы по 10 страничек дома читать. Так и дочитала. А потом еще и еще, так моя коллеция прочитанного и увеличилась. А всего то и надо, открывать книгу минимум для десяти страничек...

Я дочитала Виттакера, "Exploratory testing"! Правда, пока рецензию не дописала... Зато, пока читала, поняла, что "Вау, это же круто! Вот ответ на вечный вопрос начинающих тестировщиков — как искать баги? Вот ответ, как делать это систематизированно, а не по манки-кликингу". 

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

Найти Джеймса оказалось не так то просто, в твиттере короткие сообщения, его email сходу не прогуглился. Зарегистрировалась в Linked In, но там нельзя добавлять просто знакомого, "докажи, что ты его знаешь, укажи его email". И там нельзя отправить письмо на почту! А в фб Виттакера нет. А в твиттере можно писать только тому, кто тебя читает... 

В итоге плюнула и написала ряд постов в твиттере. И ведь помогло! 

Джеймс мне ответил (ВАУ, Я РАЗГОВАРИВАЛА С САМИМ ВИТТАКЕРОМ!!!). И не просто ответил, а дал добро на перевод. Так что снова возвращаемся к пункту "я — писака", ждите новых статей! 

Столько всего сделано с этом году. А сколько всего еще хочется сделать!!! 
Буду снова читать, писать и обучаться. Чего и вам желаю))))

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

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

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

— Наталье Баранцевой за замечательное и ненапряжное сотрудничество, площадку для роста и развития, и вкусные суши 

— Алексею Баранцеву и Наталье Руколь за то, что всегда есть на кого равняться! ))

— Владиславу и Татьяне Орликовым за их замечательную конференцию, Рине Ужевко за рост качества докладов, так держать!

— Своим студентам, которые, учась у меня, меня же и учат

— И многим многим другим замечательным людям!

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

Нейл Фьоре. Легкий способ перестать откладывать дела на потом

Ссылка на OZON.

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

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

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

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

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

Основной посыл антирасписания:

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

Когда я только начинала читать книги про ТМ, я пропускала тезисы "вы должны отдыхать" — да да, это то понятно, но ты мне покажи, как в остальное время плодотворно работать! Некоторые приемы поняла и приняла, даже внедрила (самая любимая — помидорка). Сейчас, когда я читаю такие книжки, я пропускаю все эти методики "обязательно сегодня же вечером возьми ручку бумаги и ручку, отметь свои достижения, распланируй завтрашний день — и делай так митнимум 2 недели для формирования привычки" и вижу в книгах пользу отдыха.

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

Это здорово! Это показывает, что, даже если вы уже читали книгу, перечитав ее или нечто похожее спустя год вы все равно найдете в ней что-то новое, актуальное здесь и сейчас. Для меня сейчас актуально перестать после дня ничего-не-делания нервничать "Ой, я сегодня хотела блог-пост написать, уже 15 черновиков, надо разгребать! А еще лекцию про баг-трекинг надо переписать уже наконец! А еще я хотела... Блин, ну зачем отдыхала весь день, могла бы хоть что-нибудь сделать!"

Еще из книги мне понравилось, как автор учит работать с прокрастинаторами. Учит хвалить их. Перемешивать похвалу и "места, которые нужно доработать". Ругать прокрастинатора (да и не только его) — вообще не очень хорошая идея. Так что лучше пряничком, пряничком:

Похвала — Мне действительно понравилось, как вы поработали с документом...

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

В общем, если хотите начать изучать тест-менеджмент и уже прочитали книги из списка "Вау, must read" в моем сборном блог-посте, то эта книга вполне подходит! Читается довольно легко, полезные советы содержит. Удачи! 

Книгу в общий список добавила.

Информационный стиль и редактура текста. Курс Максима Ильяхова

Что такое информационные стиль

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

Автор и описание курса

Максим Ильяхов — создатель Главреда, сервиса по очистке текста от мусора.

Описание курса.

Зачем курс тестировщику

Чтобы ставить баги. Донесите до команды смысл проблемы и тогда ее исправят.

Чтобы тестировать документацию:

— Техническое задание на новый модуль. 

— Release Notes для пользователей. 

— Презентацию продукта от маркетологов.

Чтобы писать документацию, когда больше некому.

Почему я туда пошла

Наш технический директор проходила прошлый курс по инфостилю и осталась в восторге. 

Я люблю писать и хочу писать интересно. 

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

На работе мы полностью переписали Release Notes к релизу XYZ. Получилось круто! И интересно. Но этому надо учиться.

Впечатления

Первый день — редактура

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

Если из текста можно выкинуть слово, и смысл не изменится, —выкидывайте.

Во время лекции Максим показывал магию — вот было, вот стало. После теории студенты редактировали текст сами. При проверке ДЗ чувствовала себя идиотом — из моего абзаца выкинули все, кроме одного предложения.

Второй день — написание

Утром и днем магия в теории, вечером пишем текст сами. Времени меньше двух часов на написание статьи с нуля. За это время много не напишешь. Я набросала структуру статьи об оформлении багов и начала наполнять. 

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

Третий день — реклама

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

Помню слова Максима:

Никогда не бойся, что текст получится длинным. Бойся, что он будет неинтересным

Эта фраза запомнилась мне больше всего. Хочу быть интересной! 

Коллега писал рекламу с нуля о продукте нашей компании. Я ее протестировала и нашла несколько мест для улучшения благодаря знаниям с курса.

Общее

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

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

Я прошла тренинг — это правда.
Этот текст я редактировала сама три раза, а потом прогнала в Главреде и исправила 11 мест. Крутой сервис, крутой курс!

Путь камикадзе. Эдвард Йордон

Ссылка на OZON.

На книжке надпись — Самый продаваемый автор издательства "New York Times". Это и подкупило. Известный человек, продаваемый автор, пишет об ИТ, надо прочитать!

Честно говоря, книга не впечатлила. От "самого продаваемого автора" ожидала чего-то большего.

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

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

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

Какие бывают типы людей и сколько их должно быть на проекте. Йордон взял типизацию Роба Томсета, которая выделяет 8 ключевых ролей в прокте:

1. Председатель — выбирает путь движения к общим целям, помогает команде реализовать максимум потенциала.
2. Оформитель — придает законченную форму действиям команды, направляет внимание и пытаемся придать рамки обсуждениям.
3. Генератор идей —  выдвигает новые идеи и стратегии.
4. Критик — анализирует проблемы с прагматической точки зрения (никого не напоминает? )
5. Рабочая пчелка — превращает планы и концепции в практические рабочие процедуры, систематически и эффективно выполняет принятые обязательства.
6. Опора команды —поддерживает силу духа в участниках проекта.
7. Добытчик — обнаруживает новые идеи, ресурсы и разработки за пределами рабочей группы.
8. Завершающий — поддерживает в команде настойчивость в достижении цели.

Понравилось также и то, что автор показывает нам —нет наилучшени или наихудшей практики разработки. Используйте то, что считаете нужным, во что команда верит. Потому что новая технология может упростить жизнь, да. Но, если ее еще никто не использовал, легче не будет. Экспериментировать лучше в нормальных проектах, а не безнадежных. Тут и так хватает переработок.

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

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

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

Семь ступеней мастерства в разработке ПО

В книжке Эдварда Йордона "Путь камикадзе" наткнулась на интересную тему.

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

В своей книжке Йордон ссылается на статью Мейлир Пейдж-Джонс The Seven Stages of Expertise in Software Engineering и я хочу привести тут его перевод этих ступеней:

1. Наивный новичок — никогда не слышал о технологии Х (очевидно, для этого не требуется никакого времени).
2. Осведомленный разработчик — прочел статью о технологии Х (в большинстве случаев разработчику ПО достаточно одного часа, чтобы разобраться в общих чертах и высказать свое мнение о преимуществах и недостатках средства, даже если он никогда его не видел или не использовал.
3. Начинающий разработчик — посетил пятидневный семинар. Неделя, возможно, сжатая до двух дней ввиду того прессинга, под которым находится проект. Следует отметить, что при этом разработчик, скорее всего, успел всего лишь поработать с компьютерными руководствами, предоставленными поставщиком, или пробежаться по небольшим примерам, иллюстрирующим возможности средства. Ему не пришлось столкнуться с какими-либо проблемами и недостатками средства, у него не было возможности масштабировать средство (если это вообще возможно) для больших и сложных проектов; он не пытался интегрировать средство с большинством остальных средств в данной среде.
4. Практикующий разработчик — готов использовать технологию Х в реальном проекте. По-видимому, достаточно месяца, чтобы в основном постичь все нюансы использования средства и быть вполне готовым к его применению в "реальном" проекте.
5. Квалифицированный разработчик — постоянно использует технологию Х в своей работе и очень недоволен. если по какой-то причине лишается этой возможности. Для достижения такого уровня обычно требуется 6-12 месяцев, и если средство действительно подобно "серебрянной пуле", то разработчик превращается в проповедника и пытается всеми способами убедить каждого, что это средство — самое замечательное в мире.
6. Мастер — усвоил все детали технологии Х; знает, как обходить ее правила. На это требуется 2 или 3 года. Это также означает, что разработчик прошел две или три новые реализации продукта, познакомился со всеми пользовательскими сообществами в интернете, знает все отсутствующие в справочниках номера телефонов специалистов по технической поддержке в организации поставщика.
7. Эксперт — пишет книги, выступает с докладами на конференциях, ищет способ распространить технологию Х на другие галактики (Пейдж-Джонс в своей статье говорит о методологиях, поэтому это не совсем применимо по отношению к средствам и технологии).

Статья написана давно, но до сих пор актуальна! Еще раз дам на нее ссылочку. чтобы не пришлось скролить вверх.

Я думаю, это применимо не только к разработчикам, но и к тестировщикам  Инструменты автоматизации точно проходят эти ступени. JMeter, Soap Ui, всему надо учиться.

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

Учитесь задавать вопросы!

— Бери лопату и копай!
— Есть, капитан!

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

8 кандидатов из 10 начинают писать тесты и даже отмахиваются от моих ненавязчивых подсказок:
— А я Заказчик, можете задавать мне вопросы.
— Да зачем? Все понятно же! Сейчас напишу...

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

Придумать десяток тестов — легко.
Придумать десяток правильных тестов — намного сложнее.

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

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

Думаете, мы просто издеваемся над кандидатами, а в реальной жизни такого не бывает? Как раз наоборот!

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

Отличный пример был в летней школе тестировщиков в виде ролевой игры.

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

• отпусках (письмо за неделю до отпуска и в первый день);
• днях рождения;
• юбилеях (юбилей сотрудника + стаж его работы в компании).

Заказчику не придет в голову говорить "У меня уже есть форма создания, редактирования, просмотра и прочее, мне нужны просто письма", — он об этом знает и считает, что все знают.

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

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

Задача тестировщика — выяснить, что действительно нужно Заказчику.

Как выяснять?

Задавайте вопросы. Тестировщик должен понимать:

• Какие данные есть на входе?
• Какие данные должны быть на выходе?
• Как эта штука должна работать? 

Пример

Задача простейшая – проверить загрузку файла. Принимаемые форматы — Excel, csv. Нажимаем на кнопку “Выбрать файл”, загружаем файл, и по его данным сервер строит отчет. Данные представляют собой табличку: первая колонка — ФИО поставщика, потом телефон.

Уже можно бросаться писать чек-лист? НЕТ!

Сначала надо выяснить, что от нас требуется проверить, и какие данные есть на входе.
Обратимся к Заказчику:

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

Ага, есть некая база с поставщиками, отлично! Это наводит на новые мысли и появляются новые вопросы:

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

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

Ок, на выходе у нас ровно то, что и на входе, без дополнительных проверок, удаления мусора и прочего. А что у нас на входе? Достаточно ли данных?

— ФИО лежит в одной ячейке или в разных?
— В одной, всегда в первой.
— Телефон может быть только один?
— Нет, сколько угодно, вторая и последующие ячейки записываются как телефоны.
— Ограничение на их количество есть?
— Планируется, что их будет 1-2 в основном, но ограничения нет.
— Значит, первая ячейка в таблице - это ФИО, потом идут телефоны?
— Да, все верно
— Получается, что в файле нет "шапки" с комментарием, что в какой колонке хранится?
— Хм, да... Точно! Надо сделать так, чтобы первая строка вообще игнорировалась, пусть там будет комментарий
-—Данные могут быть только на одном листе excel файла или на разных?
-—Только на одном.

Уточним еще и ограничения на формат файла:

— Какие форматы excel-файлов должны поддерживаться?
— Все xls и xlsx.
— А в csv-файлах какие будут разделители?
— Любые — запятые, точки с запятой, "бомбочки" (ALT+0164 = ¤)...
— Хорошо, спасибо!

Вот теперь можно начинать тестировать 

См также:

Как правильно задавать вопросы, если ты начинающий айтишник

How to ask good questions

How To Ask Questions The Smart Way

Я слышу, что вы думаете на самом деле. Светлана Иванова

Ссылка на книгу (Издательство "Альпина Паблишер").

Отличная книжка! Всем тест-менеджерам настоятельно рекомендую!! Я начала читать Иванову с книги "Мотивация на 100%" после курса Натальи Руколь для тест-менеджеров. Уже тогда понравился стиль Светланы, поэтому заказала и другие ее книжки.

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

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

Жизнь на полной мощности. Джим Лоэр и Тони Шварц

Ссылка на OZON.

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

Мне понравилось то, что в книге сочетается несочетаемое.

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

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

Энергия бывает разных типов. Физическая энергия — наш фундамент. Ее очень важно поддерживать. И очень полезно заниматься спортом, чтобы приводить себя в порядок. Исследования, кстати, показали, что, когда в компаниях вводили корпоративный фитнесс. в компании DuPont прогулы сократились почти на 50%! И количество больничных тоже уменьшилось!

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

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

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

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

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

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

Главная идея книги — все типы энергии важны, во всех надо развиваться. Но резвитие не возможно без выхода из зоны комфорта. Поэтому напрягаем тело / мозг так, чтобы устать, а потом отдыхаем. И таким образом увеличиваем собтвенный потенциал!

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

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

SQA Days 16. День второй

После полуночного обсуждения тестирования к первым докладам я, увы, не осилила встать. Хотя слышала от одной из участниц, что на докладе Станислава Бахорева "Грязная автоматизация" был полный зал народа. Вот она, сила тяги к знаниям! Респект 

А я зато успела немного поболтать в кулуарах и рассказать заинтересованным о том, как мы автоматизируем. И о своем докладе на SQA Days 14 "Автотесты на уровне API для Java-приложений", в котором не просто рассказываю, как мы это делаем, но и даю пощупать тестовый проектик. Скачал, запустил, впечатлился! 

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

JIRA. Обратный отсчет — до релиза осталось...

Мы попробовали у себя на работе подключить JIRA Agile, но как-то не пошла идея... Из всех возможностей мы использовали в итоге только календарик Greenhopper Days Remaining.

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

Но без календарика грустно! 

Поэтому мы создали свой 

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

Подключение календарика

1. Создать портлет типа Text

2. В поле "Заголовок" написать "До релиза осталось".

3. В поле HTML вставить

<html>

<style>

h1 { background-color: #e0f0ff;

     color: forestgreen;

     text-align: center; 

     font-size: 15em;

     font-weight: normal;

}

</style>

<body>

<h1 id="toRelease" />

<script language="javascript" type="text/javascript">

var minDate = new Date("2099-01-01");

var today = new Date();

var xhr = new XMLHttpRequest();

xhr.open("GET", "http://jira.hflabs.ru/rest/api/2/project/YourName/versions/", false);

xhr.send();

var versions = JSON.parse(xhr.responseText);

for (i = 0; i < versions.length; ++i) {

    if (new Date(versions[i].releaseDate) < minDate && versions[i].released === false ) {

      minDate = new Date(versions[i].releaseDate);

    }

}

diff = Math.ceil((minDate - today) / (24 * 60 * 60 * 1000));

if (diff < 0) {    

    for (i = diff; i < 0; ++i) {

        date = new Date();

        date.setDate(today.getDate() + i);

        if (date.getDay() === 0 || date.getDay() === 6) {

            diff = diff + 1;

        }

    }     

    diff = diff.toString().fontcolor("firebrick");

}

else {

    for (i = 0; i < diff; ++i) {

        date = new Date();

        date.setDate(today.getDate() + i);

        if (date.getDay() === 0 || date.getDay() === 6) {

            diff = diff - 1;

        }

    }

}

document.getElementById("toRelease").innerHTML = diff;

</script>

</body>

</html>

4. Заменить во фразе "project/YourName/versions/" YourName на название своего проекта.

5. Сохранить и наслаждаться! 

PS - календарик писался на коленке во внерабочее время. Так что код не идеален, но работает же! =)

Классы эквивалентности для редактирования сообщения

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

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

Давайте возьмем для примера сайт http://ru.qahelp.net/.
Там можно создавать вопросы и отвечать на них. К каждому вопросу и ответу можно добавлять комментарии.

Я задала своим выпускникам онлайн-интенсива простой вопрос, как мы будем тестировать возможность редактирования ответа на вопрос?

Результаты порадовали (варианты очень интересные):

1. Что я могу редактировать свой ответ.
2. Что я могу открыть для редактирования и передумать, нажать отмену. Должно сохраниться прежнее состояние.
3. Если пишется дата создания ответа, то:
   3.1: Действительно ли такое время и дата. Может быть другой GMT
   3.2: Какая дата после редактирования и сохранения изменений: старая или новая.
4. Не внести изменения и сохранить. Должно остаться прежним. Со временем - как в 3.2
5. Если были комментарии к ответу, то что с ними происходило после 1-4. Должны сохраняться.
6. Проверить что все инструменты для редактирования работают.
7. Ответ может быть "простой" и кем-то откомментированный (тобой же или другим человеком).
8. Открыть для редактирования сразу в 2 вкладках и отредактировать. Проверить синхронность.
9. Открыть одновременно в двух вкладках для редактирования. В первой вкладке выйти из режима редактирования и удалить. Во второй вкладке сохранить редактируемое. Обновить вкладку во втором браузере. Вопрос: останется во второй вкладке или исчезнет?..

Хороший чек-лист, грамотное выделение классов эквивалентности 

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

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

Но давайте пока временно отбросим эту проверку, отнеся ее к негативным тестам. У нас должна быть возможность редактировать ответ. Отлично! А какой ответ бывает?

• Свой.
• Чужой.

Другие варианты разделения на классы эквивалентности?

• "Простой".
• Откомментированный.

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

********************************************

Шаги для воспроизведения:
1.       Даем ответ на чей-нибудь вопрос.
2.       Просим коллегу его прокомментировать
3.       Нажимаем «редактировать»

Результат
Ничего не происходит 
См пример тут - http://ru.qahelp.net/question/skolko-tratite-na-samoobrazovanie/

Я не могу исправить очепятку в своем посте, потому что его уже откомментили (если еще не комментировали, то редактирование работает, проверила тут - http://ru.qahelp.net/question/vash-top-5-dokladov-s-sqa-days-vseh-vremen/).

Ожидаемый результат
Открывается форма редактирования.

********************************************

Собственно говоря, нашла эту ошибку я чисто случайно. Заметила у себя опечатку, попробовал отредактировать, а фиг.

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

Не просто "аааа, фсе пропало, РЕДАКТИРОВАНИЕ НЕ РАБОТАЕТ НИГДЕ!!!", а грамотно, с локализацией ошибки. На то мы и тестировщики 

Напоследок хочу сказать, что всегда пробуйте посмотреть на задачу с разных сторон. Сначала с точки зрения пользователя "Что я могу делать? Ага, а какие состояния могут быть у этого элемента, которые могут мне помешать (такие, как комментарий в нашем примере)?".

А потом не вредно посмотреть и с точки зрения тестировщика — "Крушить, ломать! ПО побеждать". Удачи в поисках интересных классов эквивалентности 

Джеф Раскин. Интерфейс

Ссылка на книгу.

Книга обязательна к прочтению для всех разработчиков, тестировщиков и аналитиков. Она показывает, насколько важно хадумываться о usability и чем плохи некоторые "гениальные" решения, такие как постоянные окошки "А вы уверены в том, что хотите это сделать?".

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

Пользователи не задумываются над тем, как устроена машина, пока она справляется со своими задачами. [При этом все внутренности значения не имеют]. Для пользователей важнее всего удобство и результаты. Но все, что они видят, — это интерфейс. Другими словами, с точки зрения пользователя именно интерфейс является конечным продуктом.

Потом Джеф переходит к когнитивной психологии и объясняет многие ожидания пользователя через нее.

Возьмем, к пример, то самое окошко "А вы уверены?". Исходная задумка — пользователь, увидев подтверждающее окошко, задумается, а действительно ли он хочет это удалить? Да, действительно, задумывается. Один раз. Или два. А потом у него входит в привычку всегда нажимать "да", даже не глядя на само сообщение.

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

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

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

Пользователю нужно около 10 секунд, чтобы вспомнить, что он делал в прошлый раз и что нужно сделать сейчас. А компьютеру нужно 7 секунд, чтобы чтобы считать с диска остальную рабочую часть информации. Итог — пользователь счастлив, он думает, что компьютер откликается мгновенно. А лояльность пользователя очень важна для разработчиков "масштабного" ПО!

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

А знаете ли вы, что текст порою лучше пиктограмм? Раньше были стены текста и добавление туда картинок значительно упрощало восприятие. Но пиктограмм должно быть мало! Сейчас разработчики ушли в другую крайность, убрали почти весь текст, заменив его непонятными картинками.

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

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

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

А уж тестировщикам так вообще must-read! Не все usability-баги будут править, но теперь, по крайней мере, вы сможете доказать важность отдельных ошибок!

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

SQA Days 16. День первый

Отгремела 16 конференция по тестированию. И ВАУ, это было круто!

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

Конференция проводилась в Санкт-Петербурге, в отеле "Park Inn by Radisson Прибалтийская". Там проводится уже вторая конференция и сервис отеля всегда на высоте. На втором этаже есть 3 больших зала и куча места для "поговорить за чашкой чая". Из развлечений - большой телевизор с игрушками, пуфики и конкурсы от Badoo и Wargaming.

А еще первый день вокруг участников бегал мим 

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

Доклады

1. Игорь Бондаренко. Слепые SQL инъекции. Достаточно ли хороши ваши тесты?

Игорь рассказывал о разных типах слепых инъекций:

1. Классическая.
2. Error based.
3. Абсолютно слепая.

Стив Джобс о бизнесе. Под редакцией Алана Кена Томаса

Ссылка на книгу (издательство "Альпина Паблишер")

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

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

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

Особо понравившиеся цитаты: