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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поясню:

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

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

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

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

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

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

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

Очередной пост приятностей

Честно-честно, я не пропала. И про блог не забыла. Просто как-то всё руки не доходили писать. Но я буду исправляться, т.к. очень много что есть, о чём хочется записать и запомнить.

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

[22.10.2013 12:34:10] Разработчик: Ира, ты у нас  самый лучший тестер!)

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

А как часто вам ваши разработчики говорят, что вы молодцы? И говорят ли?

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

Баг в сновиденьях ей являлся,
манил, предсказывал, велел.
и весь народ за ней поднялся,
сражался, гиб, и славу пел.

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

о, боги матрицы! о, баги!
о, юзер - главный судия!
когда ж мы все исправим баги
меж циферь майи бытия?! (с)

Приятности :)

[21:02:46] Ирина Винокурова: Вот смотри.

[21:02:47] *** Ирина Винокурова отправил IMG_09012013_210247.png ***

[21:09:20] programmer: ща мы тут замышляем недоброе.. :P по 262

[21:09:38] programmer: ибо Дима посмотрел и прослезился, на какие бабки он попадает))




Вот как иногда полезно начертить майнд-карту по статусам и посмотреть, как новая функциональность в это всё вписывается :)

С первой рабочей неделей в 2013 году!

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

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

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

Завязка:

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

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

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

Развязка:

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

Вывод № 1:

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

Вывод № 2:

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

Эпилог:

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

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