Мы начинаем завоёвывать мир. HQA.CC

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

И вот эта идея осуществилась. 

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

http://www.hqa.cc/

Наш девиз: от эскиза до релиза.

Хозяйке на заметку.

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

Ибо, как мы все хорошо знаем, ничего хорошего в пятницу после 15:00 на работе не происходит. Только чудеса.

Брограммист.

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

Методики обучения сотрудников.

Давным-давно я тут писал пост про МОПС.
Сейчас хочу поделиться наблюдениями о том,
как происходит обучение в большинстве компаний.
На самом деле.
Я выявил три основных методики и назвал их соответственно.

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

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

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

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


Вот те методики с которыми я сталкивался.
Мне кажется, что они основные и на их базе строятся остальные.

А какие встречали вы?
Расскажите как обучали вас и как обучаете вы?

Недосмарт.

Не умеем ставить задачи.
До S.M.A.R.T. далеко ещё, его внедрять надо долго и упорно.
Главная проблема - это проецирование и путаница в признаках.
Спросишь человека "что делать"? А он тебе начинает пространно объяснять "как делать".
Даже через "5 почему" выходит что человек и сам не до конца понимает зачем это нужно.
Почему? Потому что ему не объяснили.

Вот три кита, на которых зиждится постановка задачи хотя бы на раннем и примерном уровне:
ЗАЧЕМ?
ЧТО?
КАК?

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

Хроники Отдела Тестирования. Часть 4: На недельку, до второго.

Долго не писал и вообще не думал, что продолжение будет, так что не судите строго.
Первая проба пера после долгого перерыва. Ввиду того что отпуск не бывает длинным, материал получился очень сжатым и не совсем в духе предыдущих частей.

Там или тут?

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

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

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

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

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

Если у вас намечен или уже идёт митинг, обсуждение каких-то вещей - сделайте в переговорке приятный полумрак.

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

Люди начинают говорить тише и более конструктивно.

Градус накала реально снижается. Народ начинает давать реальный конструктив.

Креатив прет, да.

Приятное открытие. Может и велосипед, но я прочувствовал.

Холиварчик.

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

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

Back to basics.

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

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

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

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

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

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

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