FunConfetQA. Осень 2013. День третий

И вот он, последний день FunConfetQA в этом году. Очень порадовал кучей полезных и прикольных докладов!

Но пойдем по порядку 

1. Алексей Лупан / Мелочь пузатая, или Объем тест-кейса против содержательности

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

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

Поэтому холивар весь почитаю на форуме 
Но то, что я слышала, мне однозначно понравилось!

2. Николай Москаленко / Юзабилити анализ интерфейса с карандашом в руке

Блеск! Лучший доклад конференции!

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

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

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

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

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

В общем, действительно классный доклад. Теория, практика и еще раз практика. Супер!

3. Ирина Винокурова / Мы не Баги! Или как научить программистов тестированию, чтобы не было мучительно больно

Прекрасное завершение конференции.

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

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

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

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

Пишем отчет, панель задач тестировщика

Включила сегодня confetqa послушать, последний день...

А параллельно открыла приложение, которое тут же и повисло. Запустила JVisualVM, чтобы посмотреть на мониторы и внезапно осознала, что моя панелька задач какая-то... Большая 

А главное - все такое нужное!! Так ничего и не закрыла...

Фишка в чем - вчера провела нагрузочное тестирование, результаты оформить не успела. Поэтому jmeter-ы даже закрывать не стала, они мне будут нужны сразу после конференции, дописать таки отчет.

Нагрузочное тестирование проводилось на linux-сервере. После него то, собственно говоря, приложение и подвисло.

Итак, смотрим:

• Папочки винды - must have всегда. Думаю, пояснять не надо, там постоянно открыты 3-4 папочки, ну, мне так удобнее смотреть всяко-разное, чем в FAR, что поделать.
• Outlook - must have всегда. Думаю, пояснять не надо, вся почтовая переписка находится там. Внимание, конечно, ему уделяется не всегда, но пусть будет запущен.
• Google Chrome - must have всегда. Тоже пояснять не стоит, наверное. JIRA, Confluence, Mercurial, TeamCity надо где-то смотреть...
• cmd - must have всегда. Постоянно открыты 4 консольки. Первая - мне любимой, для сборки проектов, прогона тестов итд. Вторая - под SQL Developer (надо бы ее убрать, кстати, закрепив в панели программу). Ну и еще две - постоянно подняты локально 2 сервера, для ручной проверки фич. Сейчас, кстати, их там 7, к постоянным четырем добавились 2 jmeter и jvvm.
• FAR - must have всегда. Вот для быстрого копипаста проекта в JBoss мне удобно использовать именно его.
• IntelliJ IDEA - must have всегда. Писать автотесты, смотреть исходный код и т.д. и т.п. Собственно, самая часто используемая программа.
• SQL Developer - must have всегда. Вместе с IDEA является самой часто используемой программой. 
• Skype - must have всегда. Там и коллеги, и Заказчики. Там что онлайн. Правда, стоит всегда в режиме "не отвлекай", так удобнее.
• ISQ - must have всегда. Там есть пара Заказчиков, которых нету в скайпе. 90% времени нафиг не сдалась, но пущай работает.
• SQL Workbench - иногда эта программа удобнее, чем SQL Developer. Когда нужна, тогда и запускаю.
• Cygwin Terminal - нагрузочный тест я запускала через sh скрипт. В батник было лень перекладывать, поэтому просто запустила через Cygwin.
• Notepad++ - must have всегда. Всякие полезности там обычно открыты.
• SoapUI - открыт не всегда, но часто. Через SOAP запросы часто приходится кидать для тестирования.
• JMeter - там открыты результаты "ступеньки" (на разном числе тредов по минуте), когда я искала, какая нагрузка будет ок. Еще не перенесено в вики, поэтому пока висит.
• Putty - через него снимала vmstat на сервере. Можно было через второй Cygwin, не спорю.
• WinSCP - опять же, подключен к серверу. Опять же, ну удобнее мне всякие логи смотреть не через tailf, а в Notepad.
• JMeter - там открыты результаты второго теста (на определенном числе тредов нагружаем час). Опять же, ждет документирования.
• Картинка - картинка ступеньки нагрузочного теста, вставляла в доку, решила пока оставить, пригодится для документации.
• Приложение - запустила посмотреть, как ведет себя после нагрузки.
• JVisualVM - запустила, так как приложение стало подвисать, а разработчик в скайпе меня игнорил, пришлось самой мониторы включать 
• GoToWebinar - 2 часа отдыха вместе с ConfetQA!

И да-да, я знаю, сейчас прибежит коллега и обзовет меня извращенкой. Так что я ему сразу отвечу - на свой firefox посмотри!! 

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

FunConfetQA. Осень 2013. День второй

Еще один конфетко-день прошел 
Пройдемся по горячим следам!

1. Алексей Петров / Вестники тестирования. Цели и польза

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

2. Рина Ужевко / Гадкий я. Или как не попасть в “ловушки” на пути к успеху

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

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

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

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

3. Наталья Руколь / Управляемое исследовательское тестирование

Наталья Руколь, как всегда, радует нас интересными и красиво оформленными докладами.
Хотите сделать все правильно? Вперед! Но учтите, что это такая скукоти-и-ища (если писать подробные тест-кейсы).

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

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

Я могу поставить идею (IDEA) !!!

Хочется поделиться небольшой тестерской радостью, пусть и не совсем своей

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

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

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

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

- Ну как там тесты, поправила?
- Да какое там, 15 минут (потрясает кулаками) ждала, пока машина отвиснет.
- Ого, как же так.
- Да в ней же всего 4 Гб оперативки...
- Так попроси админа дать тебе нормальную станцию, поставь задачку в JIRA!
- Ну-у-у-у, я с ним разговаривала уже (скромно потупив глазки).
- И что?
- Он сказал, что когда Вася (другой коллега) пересядет на ноутбук, мне отдадут его компьютер. Только (тяжкий вздох) уже пара месяцев, как он пересаживается...
- И что, тебе ждать теперь чтоли? Это же необходимость, а не прихоть! Ставь задачку!
- Ну-у-у-у... Я даже не знаю, наверное, попробую с ним еще поговорить, а может, пока вообще не стоит (опять же по некоторым своим причинам).

Ладно. Проходит еще минут 15-20, мне надоедает работать, да и время уже 11 часов, собираюсь домой. Иду мимо Яны, а она раздраженно машет рукой на свою железяку и говорит "А, ладно, я с тобой. Лучше завтра все сделаю, а то надоело ждать, пока все отлагает".

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

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

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

- Видел задачку?
- Ага. У меня как раз свободная станция завалялась...
- о_О Где ж ты раньше то был?!
- А ко мне последнее время никто с просьбами не обращался!

Потом были еще танцы с бубнами вокруг установки машины. Но вот, наконец, у Яны стоит нормальный комп!

Сегодня ухожу с работы, прохожу мимо нее. А она сидит и таким счастливым голосом говорит:

- Я теперь могу поставить идею!!!
(IntelliJ IDEA - среда разработки для Java-приложений)

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

А я даже где-то горжусь. Тем, что ускорила процесс получения этой радости

Fun ConfetQA. Осень 2013. День первый

И вот началась новая серия конфеток, на этот раз - от Тани Зинченко!

Давайте посмотрим, что принес нам первый день

1. Евгений Ефимов / Как посчитать время на тестирование так, чтобы все поверили

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

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

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

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

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

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

Раз, исправили ошибку тут же - и локализовывать не надо. Два - исправили. И вот ты привык оформлять баги в "быстром" темпе, зная, что их тут же исправят. Но упс... Аврал / больничный / отпуск, мало ли что. И вот до баги руки дошли пару месяцев спустя. И уже ничего не понятно, что тут происходит? В чем ошибка?

В общем, спорный пункт.

3. Алексей Баранцев / Баг не воспроизводится… Что делать?!

О, Алексей, как всегда, просто прекрасен!!

Вот иногда считают, что если человек сделал себе имя, то фи всем, кто приходит его послушать. Подумаешь, фанаты. Это просто бренд, ничего больше. А вот "чего"! Алексея всегда слушаешь с открытым ртом.

Потому что - интересная тема, интересный рассказ и клевые слайды!!!

А еще (гордится) Алексей в своем выступлении процитировал Таню Зинченко и меня! Рассказал об одном случае, который я описывала в блоге... Вот случай помню, а блог-пост хоть убей, найти не могу!! Алексей, а точно в блоге? Не в чатике? О, точно, и правда в блоге - вот ссылка.

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

Отличное начало конференции. я считаю! Клевые доклады, позитифф и прочие прелести жизни. Ждем продолжения!

API-тесты, комиксы

Коллеги, всем привет!

9 ноября в 12.45 я выступаю на конференции SQA Days 14 с докладом Автотесты на уровне API для Java-приложений.

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

В общем, приходите, будет интересно!

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

Итак, плюшки API-тестов!

Тестовых инструментов на самом деле больше, чем ты думаешь

Продолжу практику выписывания интересных советов из книжки Lesson Learned in Software Testing (№ 141), в вольном переводе:

You may have more test tools than you realize.

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

A test tool does not have to be labeled "Test tool". Testers have dozens of other tools useful.

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

• Disk imaging tools - Позволяет быстро восстановить систему к определенному состоянию.
• Dependency walkers - Отображает dynamic libraries (боюсь, по русски это прозвучит менее понятно ), которые использует приложение.
• File scanners - Ищет и записывает, какие системные файлы были изменены.
• Memory monitors - Следит за утечками памяти.
• Macro tools - Делает простым повторение рутинных задач.
• "Little languages" such as Sed, Awk, Grep and Diff - Этот инструмент дает возможность очень просто автоматически редактировать файлы, извлекать данные, искать какую-то информацию или просматривать diff (разница между двумя файлами). Первоначально разрабатывался под Unix, но сейчас такой инструмент есть практически на всех платформах.

----------------------------------------------------------------------------------------------

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

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

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

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

Важным опытом является, пожалуй, именно знание того самого "Little languages". Ну просто потому, что это чаще всего пригождается в работе. Хотя, кому как. Ищите то, что будет именно Вам в тему!

TEST IT. Теперь 2 раза в месяц!

Коллеги, добрый день! Как вы, наверное знаете, скоро состоится крупнейшая конференция тестировщиков - SQA Days 14. И все наши писатели будут там, в большинстве своем даже выступать

А это подготовка, подготовка и еще раз подготовка.

Ну а потом вся эта предновогодняя суета, сдачи проектов, закрытие релизов, поиск подарков, и прочее...

Поэтому с сожалением хочу сообщить, что до конца этого года (как минимум) наш проект TEST IT переходит в режим 2 раза в месяц, увы!

Но мы все еще ждем ваших писем - пишите на sprosi.testera@gmail.com, задавайте вопросы, рассказывайте истории, грустные и не очень, делитесь опытом - мы рады всем!

ШТМ. Школа тест-менеджеров Натальи Руколь

Хочу поделиться впечатлением от прохождения онлайн-курса по ШТМ!

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

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

Chief ConfetQA. Осень 2013. День 3

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

1. Татьяна Зинченко / Раскачаем этот мир: изменяем процесс без изменения методологии

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

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

2. Сергей Мартыненко / Ключевые параметры тестирования

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

Расписаны и метрики, которые можно собирать. Одна мне очень неприятна "Количество багов в год на инженера". Очень нехорошая метрика. Причем как для тестировщика, так и для разработчика. Это все настолько... Зависимо от различных параметров, что делать выводы на основании простого количества как-то странно.

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

3. Наталья Руколь / ПБО: ПротивоБаговая Оборона

Наталья - как всегда! Симпатичненькие слайды, живая речь - заставляет прислушаться и завороженно смотреть доклад. Не ворча "фу, это же КО", а думая "ВАУ, да она права!"

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

Замечательный доклад, потрясающая подача!

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

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

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

Chief ConfetQA. Осень 2013. День 2

Итак, второй день осенней Chief ConfetQA!

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

1. Игорь Лукашов / Тестирование в Scrum и Kanban

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

Вот например, Игорь применял scrum, не очень понравилось, перешли на kanban. Его, конечно, даже тролили, мол, надо проблемы решать, а не менять стратегию. Но почему? Они ведь идут методом проб и ошибок. Первое не понравилось, давайте попробуем другое - вдруг лучше получится? И если нет, будем пытаться брать лучшее от обеих практик. Так что, я считаю, доклад интересен именно таким опытом, не все же нам success-story слушать.

2. Анна Удалова / Тестировщик на мушке

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

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

Очень рекомендую начинающим руководителям, которые набирают свою первую команду.

3. Андрей Дзыня / Стратегия тестирования на основании эвристической модели Баха

Андрей рассказывал про HTSM — Heuristic Test Session Management.

В докладе звучали как простые, но важные истины - "Стратегия - ЧТО? План - КАК?"
Так и новые мысли, новые идеи.

Доклад был очень серьезным и, боюсь, даже кратко пересказать его я не возьмусь. Его надо именно смотреть, вдумчиво смотреть и пытаться придумать, как эти знания применить у себя. И, конечно, доклад не совсем для новичков. Но на то она и chief confetqa, что сюда приходят уже опытные люди. И это здорово, что есть подходящие для них доклады!

4. Андрей Ладутько / Организация времени в тестировании: от слов к делу

Доклад по Тайм-менеджменту — это же так интересно!
Я в последнее время N-ное количество книжек по нему прочитала и даже что-то применяю. Иногда... Кхм, ну ладно.

Доклад интересный, например. про хронометраж по Майклу Болтону я услышала впервые! Он весьма интересный, но и пугающий... Действительно, сколько времени вы тратите не на само тестирование? Эх...

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

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

Так что, даже если вы много читали про ТМ, доклад все равно будет полезен!

Вот так вот конструктивненько и прошел второй день #confetqa

Chief ConfetQA. Осень 2013. День 1

Ну вот и начались конфеточные дни, или вечера, у кого как

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

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

1. Алексей Петров / С чего начинается тестирование? С людей!

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

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

Там же, на форуме, мы и подискутируем дальше. Или просто поговорим. Зависит от того, насколько похожи наши мнения!

2. Андрей Мясников / Модернизация и инновации в тестировании

У Андрея, как у истинного тестировщика, вначале случились непорядки с интернетом. Ну и ладно, разобрались, перезапустились и погнали!

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

Ох, как вспомню этот TestLink, так вздрогну! В общем, не всегда все новое - это хорошо. И иногда стоит 10 раз подумать прежде чем сделать. Задумайтесь над этим.

Кстати, не обошлось и без ехидства на тему того, что у Андрея в презентации были милые котики! Например, в твиттере одна девушка написала "Котики! Фу! Как пошло!". Странно, казалось бы, что пошлого в котятах? Хотя еще страннее это слышать от того, у кого в ЖЖ на аватарке... Угадайте кто?

3. Владимир Кривенко / Эмоциональный интеллект: теория и практика

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

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

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

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

4. Елена Саламаха / Impact Mapping – карта и компас в проектном лесу

Елена работает в Luxoft (сейчас стыдно будет ошибиться, но слово на слайдах точно мелькало такое!!) и стаж у нее крайне внушительный.

Рассказывать и показывать она ой как умеет! Слайды все нарисованы от руки, это так странно и так здорово одновременно! Ну и рассказ вполне понятный, четкий и по делу.

Действительно, достаточно уже первых 2 минут доклада, чтобы сделать самые важные выводы и нарисовать себе пометочки, как минимум. Казалось бы, КО, нам нужно помнить о цели. Ан нет, на простых и понятных примерах Елена рассказала, что мы не всегда это делаем. А надо бы!

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

Не забывайте о главном! Цели - наше все

Такой вот плодотворный первый день... Посмотрим, что будет завтра!

Драйв! Что на самом деле нас мотивирует. Дэниел Пинк

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

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

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

Точнее, работает в некоторых отдельных случаях, при выполнении рутины. И это тоже здорово! В книге нет такого. что "этот подход не работает вообще, используйте мой". А показана грань - где работает, где нет. Объяснено, почему. И даже доказано - экспериментально. Что только добавляет нам веры в то. что написано. Потому что иначе очень сомнительно смотрятся данные, если старая теория отвергает вообще, от слова совсем.

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

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

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

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

Эти и другие важные аспекты очень хорошо освещены в книжке, рекомендую

Usability - несут ли программы ответственность?

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

Программы не несут ответственности.

Диалоги подтверждения - один из наиболее распространенных примеров некачественного проектирования; они спрашивают, "уверены ли мы", что хотим выполнить то или иное действие. На заре компьютеризации рабочих мест программы выполняли необратимые действия в ту же секунду, когда пользователь вводил команду. Команда "erase all" (стереть все) делала именно это, причем немедленно и необратимо. Как только первый пользователь непреднамеренно стер все содержимое жесткого диска, он, несомненно, пожаловался программисту, и программист добавил адекватный, с его точки зрения, уровень защиты. Пользователь набирает команду "erase all", и теперь, прежде чем компьютер ее выполнит, программа просит пользователя подтвердить команду на удаление.

Все очень логично и совершенно неправильно.

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

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

Да, конечно, я согласна, что вездесущее окошко "уверены ли мы?" уже всем порядком надоело и обычно подтверждается не глядя, просто по привычке.

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

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

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

Но мне не нравится подход к команде "erase all". Имхо, стереть все - это избавиться, и избавиться навсегда. Без возможности восстановления. О какой ответственности за отмену тут может идти речь?

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

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

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

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

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

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

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

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

А вот окошки да, их число можно и уменьшить

В требованиях должна быть проблема, цель, задача! Решение вторично

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

А, казалось бы, что еще надо то?
У Алана Купера в "Психбольнице" есть замечательный пример на тему того, почему это неправильно.

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

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

1. Двигатель внутреннего сгорания.
2. Четыре колеса с резиновыми покрышками.
3. Трансмиссия, связывающая двигатель с ведущими колесами.
4. Трансмиссия и двигатель смонтированы на ходовой части.
5. Рулевое колесо.

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

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

6. Быстро и легко срезает траву.
7. На этом удобно сидеть.

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

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

Ну что, тестировщики, кто правильно угадал продукт по одним только функциям?


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

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

Да даже если мы тестируем свою, техническую, документацию. Все равно. Остановитесь и задумайтесь - а кто наш пользователь? А как он будет с этим работать? А что ему вообще нужно, какие проблемы он будет решать при помощи нашего ПО? Есть в доке хоть слово об этом? Уже хорошо!

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

Не додумывайте автомобиль, читая требования к газонокосилке!