Одиночка с интернетом

Зашла вчера речь о профессиональном развитии.
Возможно ли развиваться в компании, где осуществляется постоянный жесткий мониторинг рабочего времени сотрудника?
Пришли к выводу, что все зависит от личности самого сотрудника.
А потом всплыл интересный факт. Оказывается, у больше половины сотрудников куча планов и желаний, для реализации которых понадобится несметная куча свободного от всего остального времени. И тут выяснилось, что в честной беседе наедине с собой бОльшая часть сотрудников обдумывает идею об одиночной камере с круглосуточным доступом в интернет.
Самыми продвинутыми, конечно, оказались наши Project Qwner'ы. )))
Один уже обдумал, что для изучения всего интересного ему понадобится как минимум 5 лет одиночки.
Второй "домечтался" даже до того, что если его поселят не в одиночку, то он обязательно нарушит режим, чтобы попасть в одиночку.
Вот не зря моя мама говорит, что все айтишники какие-то странные. )))

О пагинаторе, практиках тест-дизайна и развитии тестирования.

Всем начинающим тестировщикам посвящается!

Этот пост меня сподвигло написать несколько вещей.
Вещь первая. Наталья Руколь когда-то (кажется, что уже очень-очень давно) предложила развивать тестирование. Во что я с удовольствием ввязалась и ни разу не жалею. Развивать мне предстоит начинающих тестировщиков, поэтому этот пост специально для тех, кто на пути "жесткого обращения с багами"© только-только начинает осторожничать с тестированием программного обеспечения.
Вещь вторая. У Алексея Баранцева недавно закончился тренинг "Практикум по тест-дизайну", в котором одним из заданий было как раз-таки поэкспериментировать с поисковыми системами (по сути - с пагинатором). Когда я еще была самым что ни на есть начинающим тестировщиком и посещала разные тренинги и семинары, мне казалось, что тест-дизайн - это вообще непринципиальная вещь. Ведь зачем она нужна, если еще столько неизученного: тестирование безопасности, нагрузочное тестирование, автоматизация, юзабилити.... Я же и так пишу тест-кейсы, завожу баги... )))) И только после того, как появился некоторый опыт в тестировании, стало понятно, что без тест-дизайна вообще никуда.
Вещь третья. Буквально вчера на своем собственном проекте нашла при тестировании пагинатора довольно интересную ошибку. Интересную потому, что я уже тестировала на больших числах и все было хорошо. Но после мерджа ветки решила проверить еще раз. И случайно (наверное, какая-то тестерская интуиция) наткнулась на единственное число, на котором падает SQL. Но обо всем по порядку.

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

Итак.
Немного о пагинаторе: что это и с чем его едят.
На самом деле все просто. Пагинатор - это такой механизм организации постраничного вывода информации. Допустим, у нас есть ну очень большой текст (до конца его нужно очень долго скроллить). Мы используем пагинатор и получаем этот же большой текст, но уже разбитый на страницы.
Выглядеть это может примерно так:

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

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

?page=2

Вот с этим "нечтом" мы и будем работать. ))))

Сразу скажу по-секрету, что вводить вместо цифры "2" можно все, что угодно: положительные и отрицательные числа, нули, дробные и слишком большие числа, числа в шестнадцатиричной системе, строки вида "inf" или "infinity" и много еще чего.
Мое "любимое" число - это множество девяток (свыше 11) целым числом или после запятой. Но наша система это выдерживала. Как, впрочем, и ввод отрицательных чисел, и дробных значений.
Я решила модифицировать его и разбавить нулями. Получилось число 990909009090909999. И вот оно-то и принесло то, чего я добивалась: прекрасный эксепшен с ошибкой 500.

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

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

MySQL Error!
------------------------

The Error returned was:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '1.9818180181818E+19,20' at line 1

Error Number:
1064

 Почему это происходит?
Введенное число попадает в MySQL в экспоненциальной форме, что приводит к ошибке синтаксиса (SQL не понимает такие числа).

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

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


Будь внимателен к SQL, юный падаван!

"Обязательно все документируйте, хоть это и бессмысленно" (С)

Давно собиралась написать большой и красивый пост про документацию в проекте (а мне тут есть о чем написать!), а тут еще и наткнулась на "Обязательно все документируйте" vs "документацию писать бессмысленно" на Хабре. И поняла, что пора. )))

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

Я вижу здесь три варианта развития событий.
Первый: таки мотивировать чем-то программистов (скорее всего, тут сработает только метод кнута - вопрос только в его эффективности), чтобы они и в дальнейшем писали документацию. Рассказать им про всякие принципы "лягушек", которых нужно есть с утра, и успокоиться.
Второй: спихнуть написание документации на Project Owner, который непосредственно общается с заказчиком и точно знает, что тот хочет. Основной затык здесь: стоимость времени РО, а также наличие этого самого времени, которого даже в настоящий момент едва хватает на проверку уже написанной документации.
Третий (и, наверное, не последний): поручить написание документации тем, кому это реально в кайф. Я думаю, что такие люди есть, но тщательно шифруются. Затык здесь: проектов несколько, а человек может быть один. Вникать в несколько проектов сразу ему может быть затруднительно.

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

Оценка людей и идей

Иногда читаешь какие-нибудь вещи, молча соглашаешься: "Ну да, так и есть, чего обсуждать-то?" и идешь читать что-нибудь другое.
А иногда читаешь, задумываешься. Перечитываешь. Думаешь постоянно. И как-то не идет из головы. Особенно если вычитаешь какие-то умные мысли, а повлиять на их практическую реализацию почти не можешь.
У Александра Орлова и Славы Панкратова есть бесплатный курс "Инструменты работы с людьми". Там несколько коротких видеороликов на разные темы. Наткнулась я на них как-то совершенно случайно. Просмотрела, согласилась со всем. Естественно, понравилось.
Но вот один видеоурок все никак не идет из головы. Называется "Оценки людей и идей".  Речь идет о "принципе айсберга", когда принимается какое-то решение и действия осуществляются в соответствии с ним (верхушка айсберга), но совершенно не учитывается то, на что это может повлиять, как к этому отнесутся люди и кого это решение затронет (та часть, которая под водой).
И даже такие классные руководители, которые возглавляют айтишные команды, тоже частенько этим грешат. Или непроизвольно (я целыми днями "варюсь" в этой теме, как кто-то еще может не знать об этом?), или намеренно (зачем им об этом знать, это только мое решение!).
В заключительной части видеоурока сказано как менеджеру правильно задумываться о людях, на которых повлияет принятое решение. Но ничего не сказано о том, как повлиять на менеджера, чтобы он начал об этом задумываться.
Я долго думала о том, что делать тем, кто находится в правом нижнем квадрате матрицы, т.е. не имеет право голоса, но имеет заинтересованность в исходе дела. Как им повлиять на то, чтобы быть информированными?
Мне пришел в голову такой цикл:
Дать менеджерам послушать этот урок.
IF они прониклись идеей и следуют ее курсом
  THEN наслаждаться процессом и общей информированностью
  ELSE собрать небольшую инициативную группку и направиться к руководству разрушать миф о том, что "в нашей компании такого никогда быть не может". Но тут есть нюанс: в определенный момент придется сказать что-нибудь типа: "Это ты думаешь, что никакие слухи не ходят, а на самом деле Вася сказал, что закупка новых ноутбуков только для одной команды говорит о том, что программистов второй команды скоро уволят. И, между прочим, некоторые из них уже начали поиски новой работы!"
А, может, есть другой, какой-то более простой путь? Или более сложный?...
Вот такие мысли бродят в голове...

Развиваем свои таланты

1 марта прошел вебинар Натальи Руколь "Позитивная карьера", в котором я принимала участие.
Что это дало лично мне? Во-первых, мощнейший заряд позитива. Наташа вообще очень позитивный человек, где она берет столько оптимизьмы для меня до сих пор загадка. )) Сразу захотелось бежать куда-то, что-то делать, радоваться жизни )) Что, в принципе, я и делала: несколько дней подряд скакала вокруг мужа, восторженно расписывая ему все классности позитивной карьеры, а он при этом старался вовремя опускать меня на землю ))
Во-вторых, я поняла, что неосознанно сама строю свою карьеру на принципах позитива. Главный шаг был сделан несколько лет назад, когда я ушла с госслужбы, несмотря на сопротивление начальства (а кто ж работать будет?) и уговоры родителей (такая престижная работа!). И сейчас бОльшая часть всего, что происходит в моей работе - на позитиве ))
И в-третьих, все это время я обдумывала те вопросы, которые нам задали на вебинаре, и над которыми предложили подумать и ответить на них хотя бы себе. Так вот.
На вопрос: "Что вы будете делать по итогам вебинара" я, наверное, уже ответила.

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

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

 Еще до вебинара я поняла, что пустая теория - это ничто. Без практики. И я стараюсь не просто читать что-то, получая новую теоретическую информацию, но и пробовать это делать, превращая знания в конкретные действия. Так что тут главное - не ухудшить. )))
А вот главное мое достижение (уж не знаю заслуга ли это вебинара или нет, но произошло это точно после него): я по своей инициативе села и начала писать тест-кейсы. Притом, что раньше их в нашей фирме не писал никто, да и я их всем сердцем не любила. А тут вдруг: раз! И тест-кейсы. )) Фантастика!
Вопросы про развитие талантов как-то меня немного смутили сначала. Конечно, я знаю, что мне нравится делать, а что - нет. Но вот хотелось получить подтверждение этих знаний. Поэтому, вооружившись вторым вопросом от Натальи:

"2. Спрашивать у знакомых и коллег. Что, как они думают, у вас хорошо получается?"

пошла к мужу (по совместительству - девелоперу на проекте) и спросила: "А что я делаю хорошо?" Как спросила, так и получила: "Пряники у тебя вкусные. И мне с тобой хорошо" (конечно, не зря мне позавчера всю ночь снилось, что я автотесты на пряники пишу: ищу у них точки входа, граничные значение, комбинации....).
Пришлось уточнять про тестирование. Ответ: "Ты находишь всякие заковыристые места", конечно, хороший. Хотя и не совсем то, чего я ожидала )))
А лично мне нравится исследовательское тестирование. Особенно - искать всякие ошибки в логике: "А вот что будет, если тут потереть, а потом вот здесь потрогать?" Иногда так зарываюсь во все эти "уровни", что теряю ощущение времени ))))
Я люблю тестировать безопасность. Особенно люблю такие ситуации, когда кто-то пытается влезть на проект, а ты точно знаешь, что вот здесь ты тестировала и именно отсюда зло не пройдет! И оно не проходит! Это круто!
Я люблю нагружать систему и проверять ее возможности. Тут уже я люблю сам процесс: все эти графики, циферки и разговоры с умным видом: на данном этапе наша система выдерживает единовременную нагрузку в 100 человек!
Я не люблю автоматизацию... Потому что думаю, что автоматизировать на 100% все равно невозможно. А еще потому, что я не очень люблю программировать. Да, я - тестировщик, который не мечтает стать программистом. )))
И тут уже назревает ответ на еще один вопрос:

"3. В серьёх призадуматься над вопросом: а что бы вы делали, если бы у вас было 4365987 миллионов долларов, и париться деньгами не нужно было бы?"

Я бы посещала самые крутые тестерские конференции и тестировала в свое удовольствие только самые классные проекты. ))) А еще, наверное, я бы преподавала в каком-нибудь ВУЗе какое-нибудь "Тестирование программного обеспечения", не брала бы взяток и выпускала только самых квалифицированных специалистов )))
Хотя, про "самых квалифицированных", наверное, я погорячилась...

Мерси за комплиман!

Сегодня я получила второй лучший в моей жизни комплимент )))

Первый звучал так:

"Где ты это все находишь?!" (не помню кто)

Сегодняшний был таким:

"Таня, ну ты и привередливая!!" (Фишкиллер, привет!)

Считаю, что именно такие фразы - лучшее признание от девелопера тестировщику )))))
Буду ждать следующего и надеяться, что он будет не менее оригинален, чем первые два ))

Об SQA Days замолвите слово...

Наверное, только ленивый тестировщик не писал в своем блоге о грядущем SQA Days 2011. Я буду имитировать трудолюбивого тестировщика и напишу. :) Но у меня есть и своя личная причина написать об этом. :)
Мало того, что

"SQA Days является конференцией №1 на пространстве СНГ и одним из главных мероприятий в Восточной Европе, посвященных тематике тестирования и обеспечению качества программного обеспечения".

Так еще и моя скромная персона будет там выступать!

Вдобавок конференция пройдет 22-23 апреля в Казани! А я еще никогда не была в Казани - это раз. А 21 апреля у меня день рождения - это два. :)
С учетом того, что в Казань мне добираться почти трое суток, день рождения мне светит отмечать в поезде. А у меня еще ни разу не было дня рождения в поезде )))))
Это ли не прекрасно? )))

С почином меня!

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

Здесь должен быть жутко интресный первый пост блога о тестировании.