Кое-что о джуниорах

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

За сентябрь у меня произошёл один большой вывод - я разучилась работать с джуниорами-программистами.

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

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

Просто, чтобы не забыть:

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

2. Джуниоры - на то и маленькие программисты. За ними нужен глаз да глаз.

3. При этом, не пугать их, общаться с ними нежно, без криков. Они делают это от незнания. А от тебя зависит, как они дальше будут воспринимать других тестировщиков.

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

Бонус:
5. Слаженность работы в команде не отменяет того, что надо вести хоть какую-то документацию. Как минимум, новым людям будет проще разобраться в проекте. И программистам, и тестировщикам, и аналитикам.

Были ли у вас вот такие ситуации? Когда надо заново привыкать к работе по простейшим проверкам?

Цейтнот как стиль жизни

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

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

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

И вместе с этим я набрала кучу проектов.

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

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

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

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

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

Чтобы не провести осень также чудесно, как лето, пока вижу такие варианты:
1. Помощник. И он ко мне придёт через 2 недели, как рассчитается на рабочем месте.
2. На день брать не больше 4 небольших задач. Или 2 больших.
3. Отчитываться каждый день в проектных чатиках о том, что сделано, что буду делать (и когда), а также какие проблемы были.
4. Вспомнить правило 15ти минут: вполне себе можно на вопрос не отвечать. Люди сами смогут найти решения.
5. В борьбе с прокастинацией, которая вылезла из усталости снова завести плагинчик Pomodoro
6. В нерабочих чатах отключить уведомлялки.
7. Гулять. Выходить из дома на спорт или ещё куда, чтобы проветривать голову.
8. Вспомнить, что не все деньги можно заработать :)

И ещё несколько пунктов, которые находятся в эдаком "тестировании"

У вас есть, что добавить? Как боретесь с нехваткой времени из-за большого количества работы?

Точное следование требованиям. Или кэповские напоминалки.

-Зачем ты это завела?

-Потому что это баг.

-А разве в требованиях указано это?

За последние 4 рабочих дня я услышала несколько раз: "Мы не будем это править, потому что поведение, описанное в баге, не указано в требованиях".

К поведению относилось:

1. Поехавшая кодировка, если нет данных

2. Английские названия столбцов в формируемых таблицах данных

3. Возможность создать два одинаковых элемента

4. Невозможность ввести дробные числа в поле

Знаете, для меня это очень хороший показатель - с кодером я работаю или с программистом. 

Поясню:

1. Кодер делает всё, как в требованиях. Шаг вправо - шаг влево: расстрел на месте. С ним невозможно договориться практически ни о чём, не гаркнув или не подняв проблему на уровень выше.

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

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

Требования никогда не бывают полными. В них никогда нет пошагово расписанного функционала, потому что многие вещи опускаются под эгидой: "ведь это же очевидно" если бы ещё важные вещи так не опускали... Это хорошо, если есть какое-то подобие ТЗ. А если это будет листик А4 с карандашной блок-схемой, нарисованной на коленке? Реальный случай в моей работе, кстати.

Тестировщик всегда должен ставить себя на место пользователя и отключаться от того, что продукт выстраданный в течение 8 месяцев. И говорить о неудобстве или о том, что это очевидный баг.

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

Какими вы способами решаете проблемы с кодерами?

В помощь маленьким

Когда я только уходила на фриланс одним из самых больших кайфов в начале работе было то, что ТЕПЕРЬ Я ОТВЕЧАЮ ТОЛЬКО ЗА СЕБЯ. Видимо, слишком рано мне дали создавать отдел и руководить людьми. Не была я к этому готова тогда.

Но время идёт и меняется. И сейчас у меня снова появился джуниор, которого я учу плохому потихоньку воспитываю. Конечно, на данный момент это всё происходит совсем не так, как это было 2,5 года назад, когда мне подсунули первого человека, не знающего ничего о тестировании. И это - о, Боги! - мне начинает нравиться. Хотя до этого я плевалась.

Так о чём это я? Ах, да.

Все мы знаем, что над любым элементом можно производить 4 действия:

1. Создание
2. Просмотр
3. Редактирование
4. Удаление

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

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

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

Раздражения псто

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

Ну так вот. Одного дев. лида практически не видно. Он появляется в разговоре, только когда какая-то нехорошая вещь творится. При этом, он решает трудности с заказчиком.

Второй же дев. лид каждые два-три часа вещает в чат, что проект очень важен, что надо напрячься, что в конце нас ждёт бонус и прочие бла-бла-блашки.

Как вы думаете, на чьём проекте я работаю охотней?

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

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

Про нас, бедных :)

Тут у Тани Зинченко идёт третий курс по обучению ребят тестированию. Я там, кстати, помогаю (чему я очень сильно удивлена).

Вообще, Таня хорошее дело делает. Если бы мне эти курсы попались, когда я только начинала тестировать (пять лет назад, ага), то насколько бы мне было проще. Кучу ошибок просто не сделала бы...

Ну да ладно. Я это всё к чему веду. В одном из домашних заданий студентка прислала вот такое вот сообщение:

"Одна мысль: тестировщиков вообще кто-нибудь любит? Программисты отгребают от них, аналитики тоже отгребают…пока прошлась по всем видам тестирования, поняла, что от взгляда хорошего тестировщика ни один член команды не укроется – даже дизайнер отгребет, если интерфейс будет непонятным или некрасивым. Как вы еще все живы и здоровы? "

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

А нас любят. Без нас скучают. Без нас страдают. Мы, по ходу, и тут нашли какой-то баг в отношении. Нестандартное оно :)

ТЗ? Не, не слышала...

Я не умею работать с техническим заданием.
Ну, как не умею.
Если я его вижу (а вижу я его редко), то я его читаю и получаю общее представление о том, что же за систему мы будем писать.

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

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

Так к чему это я?, А, да.  У тестировщиков есть одна активность, вроде как:, под названием "тестирование требований". И тут вопрос: а как это делается правильно?

Выписываются функции из тз?
Просто проверяется, чтобы вот таких фраз не было?
Ещё что-то делается, чего я пока что не знаю?

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

Что делаете вы, когда получаете ТЗ?
И видели ли вы идеальное ТЗ, в котором всё расписано по пунктам и прям сразу понятно, что да как?

И чтобы два раза не вставать: не переоценивают ли ТЗ? Может, реально проще общаться с аналитиком, чем читать? Он как человек, больше поможет-то, чем бумажки...

О недостатке силы убеждения

Хорошо, Ира, - я не умнее пятиклассника (с)

Признание программистом своего промаха

Завязка:

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

Кульминация:

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

Развязка:

Позвонили, в общем, с предприятия. В помещения с большими планами пошли в первую очередь.

Вывод № 1:

Слушать надо, что говорит тестировщик, когда он смотрит на приложение с точки зрения пользователя.

Вывод № 2:

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

Эпилог:

у меня теперь проспоренная шоколадка и безоговорочный авторитет в глазах программиста. Неплохо. Это скрашивает нагоняй лида.

А у вас были такие случаи, когда не могли доказать что-то программисту, а потом оказывались правы?

Конфетная учеба. Третий (последний) день.

Как меня достала #confetQA 

(цитата друга  не-тестировщика из  твиттера)

Вот и закончилась наша конфетная учеба для автоматизаторов. Мои друзья снова вздохнули свободно, ожидая в твиттере только сообщения о каких-то других событиях, не связанных с тестированием :)

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

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

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

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

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

Что я имею сказать по поводу всей этой конференции. Чем больше я слушаю про автоматизацию, тем больше я убеждаюсь в двух вещах: 

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

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