В прошлом посте я уже упоминал о своих теплых чувствах к коллегам-программистам и их творчеству. Сегодня бы хотелось поразмышлять об отношении к другим коллегам. Тестировщикам. Я всеми руками за концепцию тестирования перед выдачей чего бы то ни было в промышленную эксплуатацию. Я не буду затрагивать методологии тестирования, так как это не моя специальность и тут я доверяю специалистам. В первую очередь я говорю о двух понятиях: тестирование задач (баги и фичи, разумеется, сюда включаются) группы и заведение багов и доработок. Вот об этих моментах хочется поразмышлять.
Разумеется, сразу хочется решить все проблемы фразой «нужно общаться внутри команды». Да, действительно нужно и это решает многие проблемы. Или нет? Я считаю, что проблемы создает отсутствие общения, но вот перебор с общением создаст проблем ничуть не меньше. Если мы каждый баг будем обсуждать между программистов и тестировщиков – мы ничего не сделаем. Никогда и никак. А вот где золотая середина – я попробую нащупать, но надежд на ее нахождение примерно никаких.
Начну размышления с тестирования задач. Процесс тестирования состоит из процесса сборки проекта, деплой на тестовый контур и собственно само тестирование. Парадокс, но я очень не редко встречаю тестировщиков, которые не понимают что такое сборка проекта. На текущем месте работы мы используем концепцию continuous integration (Непрерывная_интеграция) вообще и конкретно - Teamcity. Данный инструмент имеет богатейшую визуализацию проблем, однако с завидным постоянством вновь приходящие тестировщики смотрят на результаты сборки и деплоя как бараны на новые ворота. Что же хочется пояснить? Деплой состоит, в принципе, всего из 4 шагов. Сборка зависимостей, сборка проекта, прогон unit-тестов и копирование получившихся файлов на тестовый контур. Тестовый контур – собственность тестировщика. Когда тестировщик приходит ко мне с фразой «Там не задеплоилось» - лично мне хочется взять что-нибудь потяжелее и начать воспитательные работы. Не задеплоиться могло сразу по целой пачке причин, и как ни странно, некоторые из них можно исправить без привлечения программиста.
Основные причины «не задеплоилось»:
1) Сломана сборка зависимостей. Фактически сломалась сборка проекта, которым вы, скорее всего, даже не занимаетесь. Данная поломка должна исправляться программистом, так как тут достаточно много сценариев проблем, но есть одно важное замечание. В 99% случаев данная проблема не требует переоткрытия задачи на доработку. Возможно, необходимо вливание изменений из мастер-веток, trunk или как вы это называете в своей компании.
2) Проект не скомпилировался. А вот тут уже с вероятностью 99% задачу нужно переоткрывать. Оставшийся процент остается, на случай если в ветке работает много народу и сломать мог кто-то другой. При достаточной визуализации, каким коммитом сломана компиляция – можно однозначно определить в рамках, какой задачи она была сломана, а, следовательно – переоткрывать. Если в команде осуществляется ревью задач – без переоткрытия вы рискуете получить изменения, не прошедшие ревью.
3) Не прошли тесты. Лично я считаю что задачи, аналогично предыдущему пункту должны быть переоткрыты, и не взяты в тестирование, однако есть нюансы. В идеале нужно посмотреть, что именно прошло не так. Теоретически возможна ошибка настроек окружения и перед переоткрытием я бы рекомендовал попробовать повторный прогон тестов. Если ошибка не исключится – переоткрывать.
4) Проект собрался, тесты зеленые, но не прошло дальнейшее копирование файлов на тестовый контур. А вот тут уже без доказательств, что это прошло по вине программиста - лучше даже не подходить к программисту. В подавляющем числе случаев проблема решается руками тестировщика. Напомню, что программист отвечает за корректность кода в ветке. Тестировщик – за контур. В данном случае кодовая база в норме и вы просто хотите переложить свою работу на плечи программиста.
Как мы видим – всего 4 пункта. Если я что-то забыл – напомните. Знание всего 4 пунктов упрощает жизнь программиста и обогащает навыки тестировщика. Можно конечно сказать, что я просто хочу упростить свою работу, однако мы работаем в команде. И если один из членов команды считает что его работа – это тыкать палкой во что-то родное и знакомое не вникая в процесс возникновения оного, то я бы не хотел видеть этого человека в команде.
Второй важный момент, над которым хочется поразмышлять – заведение задач (багов). В нашей компании задачу или баг может завести кто угодно. Плохо ли это? Возможно, но для заведения задачи, как правило, собирать консилиум не нужно, а, следовательно, с этим может справиться один человек. Брать или не брать созданное в работу – вопрос отдельной дискуссии на более высоком уровне управления. В чем же могут быть проблемы?
Моя любимая проблема – заведения багов не на проблему, а на следствие. Предположим, какая-то добрая душа чуть-чуть изменила структуру БД и из нее перестали корректно читаться настройки (в качестве примера). Или возникает NullReference. Банальное чтение логов ошибки покажет, где что падает. Однако на доске после этого можно увидеть десяток багов из разряда «не работает это», «не работает то». Когда проект не имеет корректных логов это еще хоть как-то объяснимо, но кто запрещает исправить логи? Программист не телепат – если вам нужны логи тех или иных событий, то попросите их логировать. А вот если логи есть и в них пишется одно и тоже и подобные логи приложены к 10 разным багам – следовательно, автор бага даже не пытался эти логи читать. Коллеги, это очень плохо. Я не прошу вас изучать архитектуру проекта, я прошу прочитать, то, что вы хотите, чтобы прочёл я.
Вторая любимая проблема - различие ожидаемого и фактического поведения. Под этим можно понимать и баги и задачи на доработку, но есть одна общая проблема. Ожидаемое поведение, оно кем ожидается? Тестировщиком? Аналитиком? Программистом? Или клиентом? Очень часто встречается ситуация, когда ожидаемое поведение отличается у разных тестировщиков. Коллеги – на мой взгляд, это путь в ад. Мало того что такое поведение может быть реализовано осознано, так еще и не факт что ожидаемое поведение тестировщиком, ожидается клиентом. Покажите этот баг хоть кому-то перед заведением. Больше чем в половине случаев вам объяснят, почему так работает. Скажете, что такие вещи должны описываться в документации или постановке задач аналитиком? А у вас на проекте это все есть? Если да – я вам завидую. В моем случае мне приходится сначала прочитать баг, затем разобраться с тем как это работает и должно ли вообще исправляться и только затем начинать работу (если надо).
Мысли уже заканчиваются, и хочется закругляться. Как мне кажется – небольшие и достаточно простые соглашения и знания могут очень сильно упростить работу в команде. Большинство моих коллег по группе знает всё, что я тут пишу. Однако люди меняются в команде, и есть другие команды. С завидной регулярностью мне приходится повторять вышеописанное людям, которые называют себя специалистами с опытом работы. У меня в такие моменты возникает только желание узнать, где был этот опыт получен и не пьет ли шампанское предыдущий работодатель, празднуя уход такого вот персонажа. Ну а мне остается только продолжить нести свой крест, объяснять прописные истины и надеяться, что где-то в этом мире есть компания, которой я нужен и внутри которой мне не придется встречать то, о чем я пишу сейчас. Наверное, где-то такое есть, но что-то мне не везет.