Заметка. Повышение квалификации сотрудника.

            Обязать раз в 3-4 месяца каждого сотрундника команды к чтению доклада на какую-нибудь тему. Например, в данный момент мы изучаем нагрузочное тестирование. Пусть, А расскажет нам о WinRunner, Б - о SilkPerformer и т.д.
             Мне кажется никто так не делает и это плохо.

Шахматные игры или просто про руководителей и подчинённых

Бывает несколько типов руководителей:

· слоны (контролёры)

· короли (рабовладельцы)

· ферзи (командиры)

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

Рабовладельцы – вот истинные разрушители жизни в коллективе, настоящие политики демотивации. Им не свойственна человечность и понимание. У них присутствует либо неугомонное желание царствования, либо неиссякаемая жажда денег, либо и то и другое вместе. Их роль как руководителей сводится к отдаче приказов, за невыполнение которых – публичное битьё палкой. Я лично считаю, что ни к чему хорошему такой руководитель свою компанию привести не сможет, кроме как к потери у своего подчинённого собственной значимости в частном, и, следовательно, кровавого убийства фирмы/отдела в целом.

Ферзи. Вот истинные управленцы.. жёны королей. Правые руки. Шеи мужей. Вот кому будет принадлежать мир, стоит только этого захотеть и грамотно всё спланировать. Внимание, понимание, своевременная реакция вознесут их в руки подчинённых. Дисциплинированность, предприимчивость, умение четко формулировать свои мысли, желание добиться истинности выложат им красную дорожку в совет директоров.

Бывает несколько типов подчинённых:

· пешки (исполнители)

· кони (инициаторы, патриоты)

· ладьи (фашисты)

С пешками всё просто. У них нет собственной мысли или желания воздвигнуть нечто великое. Они способны исполнять только приказы, они не запоминают, не думают, не решают, не предлагают, не мешают. У них всё с «не». Без «не» только.. они выполняют. Они рабы, в которых нуждаются рабовладельцы. Эти два фланга не могут друг без друга.

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

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

Хотела нарисовать это всё в диаграмму.. да не успеваю..

Максим Дорофеев: "Обезьянки против роботов"

TestLabs09 Part I

View more presentations from Cartmendum.

TestLabs Part II

View more presentations from Cartmendum.

Test Labs09 Dorofeev M Part III

View more presentations from Cartmendum.

Зачем тест кейсу одна идея?

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

У него нет опыта тестирования.

Нет никакого компьютерного образования.

Есть некоторое примитивное знание английского языка.

Я не знаю, что из этого получится. Но я решила попробовать.

В виду отсутствия свободного времени решила для начала дать ему прочитать книгу Романа Савина «Тестирование dot com» Книга до гениальности проста, как мне казалось. Позиционируется по большей части для новичков.. Ан нет.. Даже в ней есть вопросы.  Почти каждую часть необходимо пояснять своим собственным языком. Своим примером.

Начинаем..

- Зачем тест кейсу одна идея? (идеей автор книги назвал summary, title.. у кого как.. Я называю это просто заголовком.. или кратким описанием того, что тестируем)

- За тем же, зачем и один ожидаемый результат.

- Так ведь он же жирными буквами выделяет даже, что это нормально, когда ожидаемых результатов много.

- Да. Это нормально на практике. Но в идеале…  ты таким описанием  ожидаемых результатов можешь  не протестировать как работающий, так и неработающий функционал..

Пример.. нужно проверить некую expired password policy :

1.              Минимальная длина пароля 7 символов

2.              В пароле должны быть  как цифры, так и буквы

3.              Новый пароль не должен быть таким же, как предыдущий.

В, наверное, 90% случаях человек, начинающий тестировать данную функциональность создаст следующий тест:

Тест 1. Изменение пароля.

Шаг	Действие	Ожидаемый результат
1	Начать редактировать пользователя.
2	Установить пароль меньше 7 символов. Сохранить.	Появляется соответствующая ошибка о не сохранении пароля.
3	Установить пароль состоящий только из цифр. (больше 7 символов) и сохранить.	Появляется соответствующая ошибка о не сохранении пароля.
4	Установить пароль состоящий только из букв. (больше 7 символов) и сохранить	Появляется соответствующая ошибка о не сохранении пароля.
5	Установить старый пароль и сохранить.	Появляется соответствующая ошибка о не сохранении пароля.
6	Установить новый пароль состоящий как из цифр так и из букв длиною больше 7 символов	В течение 3х секунд на странице отображается сообщение о сохранении пароля. Вместо страницы редактирования открывается страница со списком всех пользователей.

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

А сейчас по делу.. Всё кажется хорошо: один тест и сразу всё проверили. И не нужно описывать пре-степы, где мы создаём пользователя , не нужно повторять шаг 1, где мы идем на страницу редактирования.. кажется, меньше текста – больше дела. Но.. а если уже на шаге 2м наш тест фейлится:  пароль длиною меньше 7 символов сохраняется, страница закрывается и нет больше перед глазами тех полей, что нужно редактировать.

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

А другой, скорее всего уже неопытный, решит что найденный баг блокирует тестирование оставшегося функционала и остановится.

Следствие 1: баг найден, баг записан, кто нашёл - доволен.

Следствие 2: не протестирован функционал, который мог бы быть протестирован. О нём забыли до момента фикса найденного бага.

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

Следствие 3: если тест больше нашего, то этот цикл может продолжаться ещё очень долго.

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

Вывод: не нужно лениться, надеяться на «авось»  и думать, что кто-то догадается протестировать оставшиеся после неожиданного фейла шаги. Нужно просто с самого начала создать несколько тестов. :) У каждого из которых своя идея и один ожидаемый результат:

Тест  1. Ошибка при сохранении пароля, длина которого меньше 7 символов

Шаг	Действие	Ожидаемый результат
1	Начать редактировать пользователя.
2	Установить пароль меньше 7 символов. Сохранить.	Появляется соответствующая ошибка о не сохранении пароля.

Тест  2. Ошибка при сохранении пароля, состоящего только из цифр

Шаг	Действие	Ожидаемый результат
1	Начать редактировать пользователя.
2	Установить пароль состоящий только из цифр. (Больше 7 символов)	Появляется соответствующая ошибка о не сохранении пароля.

Тест 3. Ошибка при сохранении пароля, состоящего только из букв

Шаг	Действие	Ожидаемый результат
1	Начать редактировать пользователя.
2	Установить пароль состоящий только из букв. (Больше 7 символов)	Появляется соответствующая ошибка о не сохранении пароля.

И т.д.

- А когда можно совмещать несколько результатов?

- Когда вследствие одних и тех же действий ты можешь проверить несколько точек функционала. Банальный пример:

Шаг	Действие	Ожидаемый результат
1	Открыть страницу редактирования пользователя	Поле «Имя» должно присутствовать на странице
		Поле «Фамилия» должно присутствовать на странице
2	Изменить имя и сохранить.	Сообщение «Имя отредактировано»  должно появится на странице
		Поле «Имя» должно стать не редактируемым.

Т.е. ожидаемым следствием шага 1 являются 2 результата:  «Поле «Имя» должно присутствовать на странице» и «Поле «Фамилия» должно присутствовать на странице»

Важно понимать, что в данном случае мы не теряем последовательности действий, нам не нужно переделывать какие-то шаги дабы «доделать» тест в случае неожиданной неудачи:  мы можем просто двигаться, отмечая полученный результат как  PASS или FAIL.

Важно всегда помнить об оформлении теста: неправильное оформление ведёт к неправильному восприятию, а это – лишние ошибки.