четверг, 31 июля 2014 г.

Дневник охотника за ошибками. Тобиас Клейн.


Ссылка на OZON.

Любопытная книжка!

В ней описывается биография 7 настоящих уязвимостей. обнаруженных автором за последний несколько лет.

Как он сам пишет, для кого эта книга:

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

Рекомендуемые автором книги:
  • The Art of Software Security Assesment: Identifying and Preventing Software Vulnerabilities (Amazon).
  • Fuzzing. Исследование уязвимостей методом грубой силы (Ozon)
А фаззинг у меня, кстати, есть! Надо уже добраться до него, поизучать, интересно жеж! Smile :)

Так вот, возвращаясь к охоте за багами. Автор описывает ошибки, найденные в самых разных местах:

  1. Проигрыватель VLC.
  2. Ядро операционной системы Sun Solaris.
  3. Мультимедийная библиотека FFmpeg.
  4. Элемент управления ActiveX.
  5. Антивирус avast!
  6. Ядро XNU в Apple MacBook.
  7. Аудиобиблиотеки iPhone. 
Каждая запись начинается с задела Обнаружение уязвимости, где прямо по шагам рассказывается "сначала буду делать то, потом то и вот я уже захватываю контроль над EIP!". Далее каждый шаг расписывается подробно. А потом автор показывает график "уязвимость обнаружения - уязвимость исправлена". Эти результаты, кстати, удивляют, кто-то исправляет очень шустро, а кто-то, наоборот, чуть ли не год и то только после публикации другим охотником за багами.

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

Все, что не имеет прямого отношения к записи в дневничке, вынесено в одно из приложений в конце книги. Автор заботливо разбил их на 3 части:
  1. Подсказки для охотника (что такое "переполнение буфера на стеке", "разименование нулевого указателя" и т.д.).
  2. Отладка (описание отладчиков для разных ОС и их основных команд).
  3. Методы защиты (приемы защиты, RELRO, Solaris Zones).
Я, судя по описанию в начале книги, тот самый ламер, который не получит от книги максимальной пользы, но зато узнает много нового. Так и есть! Было очень интересно прочитать о том, как Клейн искал уязвимости. А еще было очень приятно понимать, что я уже предугадываю шаги, какие нужны для обнаружения уязвимости!

Не понимаю, "как", но понимаю, "что"! Прикольно Smile :)

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

PS - книга добавлена в общий список книг.

воскресенье, 27 июля 2014 г.

Быстрое решение проблем при помощи стикеров. Дэвид Стрейкер


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

В принципе, книга неплохая. Это действительно пошаговое руководство. Захотел решить проблему? Открываешь нужную главу и действуешь по ней.

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

В описании методики тоже идет разделение - когда применять? Как? Что делать потом?
Все разжевано, все по шагам!

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

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

Есть нисходящее и восходящее дерево, что сразу напоминает Голдратта.

Я даже попробовала применить методику Smile :)


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

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

PS - книга добавлена в общий список книг.

вторник, 22 июля 2014 г.

Закон малинового варенья. Джеральд Вайнберг


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

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

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

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

Вот, например, рассказ о Руди и брюкве я помню и сейчас, хотя прочитала его пару недель назад в начале книжки. Историю о фермере помню и об упорном огурце в банке и кардинальной смене имиджа магазина... Много интересного! Smile :)

Непосредственно сам закон малинового варенья: 

Чем шире намазываешь, тем тоньше получается слой.

Или, перефразируя:

Влияние или богатство - делайте свой выбор.

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

Правило Руди о брюкве:

Как только вы устраняете проблему номер 1, проблема номер 2 занимает ее место.

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

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

Это интересно с точки зрения закрепления материала у студентов (для тренера), такой хороший урок "на подумать", как сделать свои тренинги еще лучше, чтобы студенты легче усваивали материал. Причем забавно, что подумала я об этом только сейчас. когда открыла свою закладку в книге и решила что-то умное написать в отзыве. Задала себе вопрос "чем это может быть полезно?" и вот какой интересный ответ нашла! Я обязательно над этим подумаю и что-то изменю Smile :)

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

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

А все почему? Нет запоминающегося триггера!

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

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

Чтобы не забыть, у меня есть "триггер" - картинка с условием выставления счета.


Это как mind-map, изображение закрепляется у меня в голове как триггер "помни про счет". А так как я его вижу всегда, приходя на работу, у меня может щелкнуть в голове "о, и правда, уже пора".

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

Так что этот урок я и без Вайнберга знала, но теперь осознала Smile :)
А еще поняла, где можно в тренерстве применить - уже есть профит от книжки!

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

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

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

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

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

Потому что те, кто держится за старые идеи, долго не протянет. Можно судиться, можно самому цепляться за свои же идеи и использовать их снова и снова. Но преимущество всегда будет у того консультанта / тренера, который постоянно движется вперед, генерирует новые идеи. Это заставляет задуматься и порадоваться за то, что на портале http://software-testing.ru/ постоянно придумывают что-то новенькое, то летняя школа, то выездной пансионат, то просто улучшат свои курсы. Это классно! Мы двигаемся в правильном направлении, Вайнберг подтверждает Wink ;)

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

Хотите узнать секреты консультирования? Тогда вам сюда!

PS - книга добавлена в общий список книг.

Идеальный консультант по Вайнбергу

Выдержка из книги Джеральда Вайнберга "Закон малинового варенья", попробуйте сами подумать, как эти правила можно применить в тестировании Smile :)
  • Ваша задача - влиять на людей, но только по их запросу.
  • Вы стремитель сделать людей менее зависимыми от вас, а не наоборот.
  • Вы стараетесь следовать закону Встряски: чем меньше вы фактически вмешиваетесь, тем большее удовлетворение вы получаете от работы.
  • Если вашим клиентам необходима помощь в решении проблем, вы можете сказать "нет".
  • Если вы говорите "да", но при этом терпите неудачу, вы можете это пережить. В случае успеха наименее удовлетворительной будет та ситуация, когда вы решаете проблемы клиентов вместо них самих.
  • Более приемлимый подход - помочь им решить проблему таким образом, чтобы они смогли решить следующую уже без вашей помощи.
  • Лучший из подходов - помочь им научиться предупреждать проблемы.
  • Вы можете быть удовлетворены своими успехами, даже если клиент вам не признателен.
  • Идеальная форма влияния на клиентов - это помочь им увидеть мир более ясно и затем позволить им самим решить, что делать дальше.
  • Ваши клиенты могут всегда ознакомиться с вашими методами и обсудить их.
  • Ваш главный инструмент - просто быть тем, кем вы являетесь. Так что самый действенный способ оказать помощь другим людям - это всегда помогать себе.
В принципе Вайнберг прав в том, что все мы так или иначе бываем в роли консультантов, кто-то чаще, кто-то реже. Когда рекомендуем подруге начинку для пирога или когда напутствуем программиста, как надо писать автотесты - это все консультации.

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

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

Например, появилась у нас утилита диагностики. И вот значит мне жалуется Заказчик "у меня тут сломалось". А информации мало. Я могу сама пойти и взять все, что мне нужно (иногда есть VPN, иногда для этого надо ехать в офис). А могу научить его пользоваться утилитой.

Также в проблемами, которые, увы, периодически возникают. У нас, как у разработчика софта, появляется иногда желание все-все-все поправить, везде все разжевать. Но иногда лучше научить работать так, чтобы и без нас можно было разобраться. Да, такие ситуации наталкивают на мысли по улучшению документации, кода и т.д. Но все равно, обучение Заказчика никогда не бывает лишним и всегда окупается! Smile :)

понедельник, 14 июля 2014 г.

Изучаем Java. Кэти Сьерра и Берт Бейтс


Ссылка на OZON.

Мои выдержки из книги:
Ну вот я ее и дочитала! Читала года 1.5, если не 2! Но при этом нисколечко не жалею Smile :)

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

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

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

В ней в игровой форме преподается серьезный материал. Авторы в самом начале сами говорят, что так эффективнее - там постоянно можно встретить картинки и мысли "героев", вот как в конце книги перед Приложением Б.


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

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

Я считаю, что для начинающих - самое то! Конечно, если не применять это все в реальности, то забывается. Хотя уже одно то, что я набирала код из книги, уже немного помогло. Отложилось что-то в голове... Ну, я надеюсь Smile :)

Так что если вы хотите изучить что-то "сложное и техническое", но страшно или скучно - попробуйте серию мировых бестселлеров от Head First, они действительно того стоят!

четверг, 10 июля 2014 г.

Москвичи, заберите книжки - 2!

Ученье - свет!
А бесплатные книжки - вообще чума! Smile :)

Условия те же, что и в прошлый раз - пишите мне на почту, бронируя книжку, а потом приезжаете и забираете самовывозом.

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

1. Стивен Кови. 7 навыков высокоэффективных людей(отдано)

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


2. Марк Гоулстон. Я слышу вас насквозь (забронировано)

Интересно, познавательно. Примеры тут сложные, автор вел переговоры с террористами, отсюда и примеры)


3. Джин Желязны. Бизнес презентация (забронировано)

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


4. Джереми Донован, Выступление в стиле TED(забронировано)

Интересная, короткая, все по делу!


5. Андре Кукла. Ментальные ловушки. (отдам после 14.07.2014, забронировано)

Отрезвляющая книжка о тех глупостях, которые мешают нам жить.


6. Хенссоны, основатели 37signals. Remote. Офис не обязателен(забронировано)

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


7. Дэниел Пинк. Драйв! Что на самом деле нас мотивирует (отдам после 14.07.2014, забронировано)

Вопросы мотивации в ярких примерах. Наталья Руколь на своих тренингах по тест-менеджменту часто на нее ссылается!


8. Дэн роэм. Бла бла бла (отдам после 21.07.2014, забронировано)

Книга интересная, но не прямо must read. Рассказывает о визуализации, правом и левом полушарии, представляя их в виде лисички и колибри. Кстати, забавные примеры, до сих пор думаю в о полушариях как о колибри и лисе Smile :)



Забрать книжки можно будет в офисе HFLabs - совсем рядом с метро Парк Культуры, напротив бассейна "Чайка".

Забронировать книжку можно комментом в блоге, а потом написав мне на почту ok.molechka@gmail.com.

понедельник, 7 июля 2014 г.

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

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

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



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

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

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

У нас есть система, в которой все хорошо Smile :)

"Доска жалоб" присутствует давно в виде JIRA, в ней всегда можно проконтролировать, на каком из подпроектов больше всего задач с разными типами. Где наиболее активные пользователи, которые задают много вопросов? На что они жалуются чаще всего? Что неудобно? В каком компоненте системы больше всего ошибок? И т.д. и т.п., я думаю, с системой баг-трекенга все знакомы и вы ждете от меня чего-то еще... И мне есть что сказать! Wink ;)

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

Тем не менее, регрессия находит очень мало ошибок. Волшебный мир, где пони, радуга и все такое Smile :)

Хотя для некоторых это не пони с радугой, а просто светлое будущее!


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


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

Вначале все было хорошо. Конечно, не спорю, иногда находятся баги в PROD, но, к счастью, очень редко + оперативно хотфиксятся. Но само состояние системы (а в нашем случае - базы) не поддается сомнению. Ведь в базе созданы всяко-разные уникальные индексы, чтобы предотвратить неконсистентности, которые система не сможет обработать.

Именно эта уверенность нас и подвела.

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

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

В итоге в ходе ретроспективного анализа мы пришли к выводу, что "баги есть всегда" и пора бы с этим смириться. Но зачем заставлять Заказчика каждый раз страдать? Да и ответственный за Заказчика QA каждый раз тратит много времени на диагностику проблемы.

Так появилась утилита диагностики. Собственно говоря, как раз сейчас на сайте http://software-testing.ru/ идет активное обсуждение, зачем тестировщики вообще программируют и пока лидирует ответ "по мелочеве, чтобы облегчить себе жизнь".

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

ЖИТЬ СТАЛО ГОРАЗДО ПРОЩЕ!

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

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

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

Вау, все хорошо? Как бы не так...

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

И вот опять ошибка. С помощью утилиты диагностики определить причину было очень легко, но вот поверить в нее намного сложнее. Ведь она шла в разрез с установкой "ну уж ТАМ то проблем быть не может". Решение "пофиксить баг" тут не пройдет, надо копать глубже, искать его корни, а главное - поразмыслить, если это выстрелило у одного Заказчика, не случится ли это снова у  другого?

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

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

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

Подведем небольшие итоги:

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

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

И не потому, что вы все проверили на своих тестовых стендах, а потому, что вы все проверили на реальных стендах. Вы искали и ничего не нашли. А если вдруг у Заказчика возникнет хотя бы намек на проблему, вы узнаете об этом первым, все найдете, устраните и снова будете спать спокойно Smile :)

Таким образом, нет предела совершенству! В том числе и в обеспечении качества! Это мне напоминает уже другую книгу, Экстремальный тайм-менеджмент. Там молодой человек оценил свои навыки как n % от 100, допустим, он сейчас на уровне в 20% от идеала. Далее он поставил себе цели, как достичь идеала и расписал, что нужно делать для достижения этих целей.

Достигнув цели, однако, он не сказал "ну все, я совершенен". нет (ну, может, он бы и сказал, но верный друг направил его по пути истины). Он сказал "ок, то, что было 100% 3 месяца назад, теперь лишь 15-20% от идеала. Так что вперед, разрабатываем новый план по достижению следующей ступеньки!".

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

воскресенье, 6 июля 2014 г.

А что конкретно ждет от тестирования Заказчик?

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


Я сейчас как раз рассталась с дизайнером именно из-за несоответствия наших мышлений из серии "это же очевидно!".

Одна знакомая нанимала дизайнеров и была очень ими довольна. Ей не пришлось познавать все многообразие цветов, плиток итд итп. Достаточно было сказать "мне нравится минимализм" и накидать картинок, которые ей нравились.

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

Я задала своему вопрос "Вот Вы нарисовали "тут шкафчик, там кровать таких-то размеров", а дальше что? По магазинам я буду кататься и искать эти вещи? А обои, ламинат - этого в картинках не будет, надо будет "по образу" подбирать?"

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

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

Это абсолютно не то, что мне было нужно, поэтому наши отношения завершились. После чего выяснилось, что она просто привыкла работать с Заказчиками, которые строят себе мраморные дворцы и хотят все контролировать, в том числе и подбор материалов. Все непременно увидеть-пощупать итд. Поэтому так она работает со всеми. И для нее было очевидным, что я сама должна ездить по магазинам, строить 3D картинки кухни, подбирать ламинат итд.

Эта история + прочитанное в книжке заставило меня задуматься о том, что и в тестировании все также. Если не оговорить "на берегу", а что конкретно Заказчик ждет от вашей программы или от вашей деятельности как тестировщика, то потом могут возникнуть казусы.

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

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

А Заказчик опять недоволен. Потому что вы не прислали ему подробный отчет о проделанном, а значит, ничего и не делали. Или прислали отчет, но краткий "протестирован модуль **, критичные ошибки исправлены, заведены доработки такие-то", а ему нужен 5-страничная официальная бумажка. Или он видит в баг-трекере всего 3 задачи и считает, что вы ничего не делали. И плевать, что еще 25 ошибок было исправлено без заведения.

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

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

Но не вам в таком случае решать, как правильно, ведь Заказчик всегда прав! Просто можно было заранее выяснить, а чего, собственно говоря, от вас ждут? Также сразу уточнить, нужна ли дополнительная бюрократия или можно обойтись без нее? В общем, обсудить все заранее или потом не жаловаться Smile :)

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