20140227

Там или тут?

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

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

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

А как считаете вы?

20140220

Рубрика "Хозяйке на заметку".


Если у вас намечен или уже идёт митинг, обсуждение каких-то вещей - сделайте в переговорке приятный полумрак.
Я не знаю что происходит и как это работает, но атмосфера становится более дружелюбной.
Люди начинают говорить тише и более конструктивно.
Градус накала реально снижается. Народ начинает давать реальный конструктив.
Креатив прет, да.
Приятное открытие. Может и велосипед, но я прочувствовал.

20140219

Холиварчик.

"Личный героизм сотрудников и менеджеров — всегда следствие недоработки в планировании и управлении" (с)

А вы согласны с этим утверждением?

20140210

Back to basics.

По следам поста Оли Киселевой
В принципе, базовая вещь, которую должен знать каждый тестер.
Оля всё правильно пишет. Красиво и с примерами.
Вот моя выжимка:

1. Тестирование на позитивных значениях.
Обычно используются пользовательские сценарии с корректными значениями.
Проверяем работоспособность заявленного функционала.

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

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

В принципе, две последних парадигмы некоторые объединяют в одну, но я бы не стал этого делать. 

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

Иногда полезно вспомнить основы.

20140207

Из разговора с сотрудником, который не понимал зачем нужно внедрение процессов и флоу и грустил по этому поводу:

Музыкальный холл.
Оркестр. Играет под палочку дирижера.
Зрители слышат чудесную музыку. Ни одной фальшивой ноты.
А перед тем как все начали хорошо играть по нотам их долго рассаживали по секциям с учетом акустики и инструментов. Вот секция скрипки - тут скрипачки сидят, рядом флейты. Тарелки - в жопе, чтобы никого не глушили.
Они сыгрывались и подбирали вместе с дирижером мелодию на слух. Записывали. Фиксировали.
Потом как-то раз тапёр пришел на репетицию в спортивных штанах и пьяный.
Так появились правила.
И вот они ВИА! Они сыгрались, у них есть четкие инструкции когда какую нотку сыграть, где затянуть, какой фрак одеть и во сколько приходить на репетицию и на концерт, в какой тональности настраивать инструмент.
Публика рада.
И тут один виолончелист вскакивает и говорит "Ну вашу мать! Ну сколько можно! По нотам играем же! Не интересно же! У меня мозг не работает! Никакого, блин, развития!"

20140206

Ищу тестера со знанием польского.

Коллеги, а есть у кого тестеры? Можно даже довольно таки джуниоры.
Ключевое условие - сносное знание польского языка.
Мы его не обидим )
Кстати, русским владеть не обязательно. Главное знать английский и польский.

20140204

4 заповеди аналитика.

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

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

Вторая заповедь аналитика.
Сначала - варианты использования. Потом - постановки задач.

Третья заповедь аналитика
Проверки требований (How to demo) пишутся одновременно с требованиями.


(с) Наталья Желнова