Продолжаем разговор.
В своем недавнем посте я привел несколько примеров, как тестировщик порой сам может упустить дефект, который был у него практически в руках. По недомыслию, неопытности, наивности, от усталости, в спешке – неважно. Сам. Программист и общая культура разработки могут, конечно, помочь – мол, не баг это, но все же, в описанных случаях их роль вспомогательная.
mtikhon в своей статье «Легкий способ пройти тестирование» прекрасно дополнил тот список «внешними» проблемами, влияющими на результат тестирования. Внешними – в том смысле, что они зарождаются не в отделе тестирования, а в прочих подразделениях, а еще чаще – где-то на стыках подразделений, при взаимодействии отделов. (Я понимаю, что не всегда под тестирование формально выделен специальный отдел. Но это косметическая разница, сути не меняет: тут речь скорее о разделении ролей)
mtikhon’у слегка попеняли в комментариях, что список проблем изложен, а легкий способ их обойти – нет. Он, в свою очередь, уже справедливо отметил, что «способы как правило разнятся очень сильно». Вот на этой мысли я и хочу потоптаться чуть подробней.
Пожалуй, пойду прямо по тем же пунктам.
1. Тестировщик должен быть в курсе изменений в продукте
Собственно, решение тут изложено в самом заголовке: найдите способ вовремя оповещать сотрудников о важных изменениях, и жизнь проекта станет проще. Я бы даже дополнил: не только тестировщик, но и программист, и аналитик, и все остальные – они тоже должны быть в курсе, да. Особенно если речь идет о распределенном проекте, в котором работа одной команды заметно влияет на работу другой.
Первая проблема в том, чтоб найти работающий способ для подобных оповещений.
С одной стороны вся информация и так уже есть – в таск-трекере все записано. Кроме того еще и система контроля версий шлет сообщения об изменениях – самые что ни на есть точные и подробные. С другой стороны – понятно, в общем, что через таск-трекер проходит куча мусорных сообщений, и никто никогда не читает то, что не относится к его работе. А сообщения от системы контроля версий – ну все же слишком подробные и атомарные, да еще на не совсем человеческом языке. Наконец, одному интересному для всех изменению могут соответствовать несколько связанных задач и коммитов.
Ладно, допустим договорились когда и о каких изменениях (в бизнес-логике, в архитектуре и т.д.) извещать, и даже как-то решили, насколько подробно эти изменения описывать в самой нотификации (кому интересны детали – уточнит).
Вторая проблема – как эти нотификации доставлять.
Можно встать и громко сказать. Можно написать всем письмо. Можно выложить на вики или еще какой внутренний ресурс. Можно еще что-то экзотическое придумать. Идеально, конечно, было бы складывать сразу в нужный отдел участникам процесса, но пока невозможно. В общем, стоит пару минут подумать, как быть. Долго думать незачем, лучше начать хоть как-то; потом можно и скорректировать. Тем более, что есть еще и третья проблема.
Как говорится, мы можем привести осла к реке, но даже Аллах не заставит его пить воду. То есть, как бы мне ни сообщали об изменениях, всегда есть возможность не знать о них: выйти из комнаты, не читать этот спам, особенно прилетевший из другого города и т.п.
То есть надо как-то показать получателям выгоду от чтения этих сообщений. И отправителям, кстати, тоже, иначе будут забывать сообщать.
В общем, есть масса возможностей недовнедрить подобную практику. Хотя если получится – польза огромная, вплоть до отказа от безумных изменений на ранних стадиях.
2. Чужие баги
Политика такая политика. Честно сказать, не сталкивался с таким, чтоб человека наказывали за то, что в «его» куске работы кто-то обнаружил дополнительные проблемы; но видимо случается и такое.
Пожалуй, я в исходной статье невнятно выразился. Речь в любом случае не идет о том, чтоб вдруг брать на себя чужую работу или лезть в чужой монастырь. Просто если я работаю над своей задачей, и вижу проблему в области, за которую отвечает другой город, — я обычно поинтересуюсь, известно ли уже о ней. Тем более, если я знаю, что мы используем разные тестовые конфигурации. Тем более, если я вдруг знаю, что тестирование этой фичи уже завершено. Тем более, если проблема не лучшим образом влияет на мою собственную работу.
Не обязательно сразу заводить баг – для начала можно просто спросить: а вот это тут вот так – специально? И послушать ответ, и объяснить свою точку зрения, если что. А баг пусть та сторона заводит, если это вдруг важно, мне не жалко. Заодно и горизонтальные связи упрочатся.
Кстати, важный момент, подчеркнутый Rascko в комментариях: Человек должен знать, «чье это», если это не его. Это здорово помогает: можно обратиться к человеку напрямую, а не писать на общую рассылку или обращаться через иерархию руководителей.
3. Мелкие баги и баги/импрувменты интерфейса летящие в реджект
Неприятно, очень, знаю на своем опыте. С одной стороны – наше дело доложить о проблеме, с другой и правда работа впустую получается.
Тут такой вопрос: кто реджектит и почему? Если программист – это одно дело, если менеджер проекта – то другое (а то и несколько других дел, у менеджера может быть куча соображений, почему данный дефект сейчас некритичен; на эту тему была недавно ремарка в статье «Тестирование: из грязи в князи»).
И решения могут быть различные. Можно договориться, чтоб решение, фиксить или нет, по всем дефектам принимал менеджер проекта, или, к примеру, аналитик ответственный за фичу. Можно просто заэскалировать проблему и сделать внушение конкретному программисту. Можно и добиться явной отмашки, что вот такого конкретного рода дефекты (на юзабилити, на производительность, на локализацию) мы пока не заводим, ибо фикситься они все равно не будут, — и это не обязательно беда; возможно это лучшее решение на данный момент, позволяющее сфокусировать усилия. Надо только определить до какого момента подобное соглашение действует и явно отмахнуть обратно, когда срок истечет.
Что выбрать? Зависит от конкретной ситуации. Тут-то и начинается самое сложное – обозначить проблему и выяснить, что же у нас за ситуация.
4. Лаборатория
Тестовое окружение – это важно, тут снова поспорить не с чем. И решение, в целом, верное: искать золотую середину между идеалом и грубой реальностью.
Хочу только подчеркнуть, что о недостатках тестового окружения и способах их исправления должны говорить в первую очередь сами тестировщики. Потому что остальные ничего об этом окружении не знают, особенно начальство. Пока не пришли и не сказали, что есть проблема с железом, — проблемы нет, и никто ее решать никак не будет.
Пришли один раз и успокоились – забудут или проигнорируют с высокой степенью вероятности.
Только регулярные напоминания лишат руководство покоя и заставят поверить, что проблема не надумана, и к тому же имеет решение. Ну и еще внятные примеры и цифры в руках.
Передавать часть тестирования наружу заказчикам/пользователям (альфа, бета) – вариант, но там подводных граблей на отдельную статью хватит. Но можно попробовать.
5. Сроки и отчетность
Вечно актуальная проблема – как оценить работу тестировщиков, да еще и работающих в сжатые сроки. И программистов, кстати, тоже.
То ли смотреть на число багов, то ли на критичность, то ли на отзывы пользователей, то ли просто на глазок прикинуть. Вариантов в литературе и жизни приведено немало.
Если говорить о результате/сроках работы над продуктом – оценивайте работу программистов и тестировщиков, да и всей остальной команды тоже, вместе. Работали над продуктом все вместе, результат тоже общий.
Если же речь об оценке конкретного тестировщика, то тут все несложно звучит. Мы же ему какие-то задачи даем на выполнение. Вот и договариваемся на берегу, что от тебя, мол, ожидается то-то и то-то. Критерии выполнения – такие вот. Сроки… Ну сколько тебе надо? Ок, давай так. О проблемах сообщай, ага? А потом – смотрим, что у него получилось и оцениваем.
На практике это все много сложнее получается, особенно с непривычки. Ну так о том и речь, что – нелегко эти проблемы решаются.
Возвращаясь к срокам: видите, что сроки нереалистичные? Говорите об этом. Чтобы протестировать все, что нужно – нам надо вот столько времени. За то время, что есть, можем протестировать вот столько. Давайте расставим приоритеты, чтоб успеть протестировать более важное.
6. Что происходит с багами вида: not reproducible, observed and etc?
Тут, в общем, все примерно то же, что в пункте 3. Или я что-то упускаю?
7. Автоматизация vs ручное тестирование
Отлично описаны проблемы. В данном случае решение настолько сильно завязано на конкретный проект/продукт, что общие какие-то рекомендации дать трудно.
Разве что одну: автоматизация И ручное тестирование. Эти понятия не должны воевать; скорее наоборот –дополнять и помогать друг другу. Тем более, что автоматизация – она же не обязательно про непосредственное тестирование продукта. Мы можем автоматизировать какие-то действия/подготовку для ручных тестов и выполнить последние лучше и эффективней. Но вручную.
8. Положение тестировщика в общей структуре компании
А вот тут уж все опять в руках тестировщика.
Если тестировщиков в компании ценят высоко, а они занимаются ерундой, то очень скоро они окажутся на уровне уборщицы.
Если же тестировщики приносят реальную пользу проекту и его участникам – авторитет будет расти.
Конечно, движение вверх – дольше и труднее падения с трона, но это везде так.
Что же до набора команд из «отбросов» программистов – показывайте, что такие люди не годятся для сложных задач, стоящих перед отделом тестирования. Докажите, что эти задачи сложны и требуют высокой квалификации. Объясните, что теряет проект, отказываясь от хороших кадров.
Сложно.
Автор: SWTester
