Иногда мы сами удивляемся, когда сотрудники «Лаборатории Качества», в очередной раз, проявляют свою инициативу на проектах. Вам сколько угодно могут рассказывать о «проактивной позиции компании», но стоит сравнить сотрудников мотивированных на результат и имитаторов бурной деятельности и вы почувствуете разницу на собственном кошельке. Проактивные специалисты не ждут пока кто-то принесет им решение на блюдечке, они уже заказали партию блюдечек и готовы предлагать свои решения. Так каким должен быть этот незаменимый проактивный сотрудник? Приведём 8 отличных примеров на своих проектах.
Пример № 1. Наглядность – признак качественной работы
Руководители одного из крупных телеком-операторов России используют для своих митапов специальное приложение. В нем можно делать записи, рисовать схемы, писать короткие записи и делиться этим друг с другом. Однозначно полезная штука, в том числе, с точки зрения безопасности коммерчески важной информации. Это приложение нам и нужно было протестировать на баги.
Что можно было сделать?
Обычный отчет о багах выглядит следующим образом: указано количество багов, определен их приоритет, все баги заведены в Jira ─ где уже можно посмотреть их описание.
Что сделали мы?
Мы подумали о том, что руководство компании, которое заказало проверку, вряд ли привыкло работать в Jira и оценивать баги по «критовости». Поэтому свели все результаты работы в единый очень наглядный отчет:
- Понятное короткое описание бага.
- Приоритет.
- Номер карточки в Jira.
- Комментарий со скриншотом.
Что получили в результате?
Удовлетворённость заказчика нашей работой. Потому что в одном файле можно понять какой найден баг, увидеть как он выглядит, понять насколько он критичен и если нужно, то удобно перейти к его подробному описанию уже в Jira. То есть в результате заказчик получил наглядную и читабельную картинку всех багов в приложении. Чем и остался очень доволен.
Пример №2. Обмен достижениями экономит время всем
В предыдущем проекте был и еще один нюанс – по результатам работы нас попросили составить подробный и максимально наглядный тест-план. То есть пошаговое руководство с описанием того, что и как мы тестируем. Почему мы о нем вспомнили? Потому что буквально через месяц этот план очень нам пригодился в другом проекте!
Один из наших заказчиков решил навести порядок в своем Confluence. От нас нужно было предоставить тест-план того, что и как мы тестируем. Внутренняя коммуникация — одна из сильных сторон «Лаборатории Качества». Поэтому тест-план, созданный месяцем ранее и получивший положительные отзывы клиента, уже был доступен другим удаленным командам нашей компании. Этим мы и воспользовались.
Что можно было сделать?
Положить отличный тест-план в папку проекта и забыть о нем, не поделившись с коллегами. На другом проекте заново создавать тест-план и тратить не только своё время, но и время заказчика.
Что сделали мы?
Мы взяли шаблон отличного плана, своевременно превратили его в рабочий инструмент и поделились им со всеми командами. В итоге ребята в этом проекте воспользовались опытом своих коллег, чем существенно сэкономили время и себе и заказчику.
Что получили в результате?
Интересно, что кроме экономии ресурсов и выполнения требования заказчика, появилась и другая неожиданная выгода. Если раньше тестирование для проджект-менеджеров был неким «черным ящиком», и они видели только конечный результат тестирования, то теперь ситуация поменялась. Изучив тест-план, они смогли дать эффективный фидбек с точки зрения бизнеса, подсказав какие кейсы можно заменить и каких не хватает. В результате некоторые кейсы были изменены и заказчик получил более качественные результаты тестирования.
Пример №3. Грамотное планирование = качественный релиз
Об отношениях между разработчиками и тестировщиками можно писать целые романы, причём нередко военные. Но по факту большинство вопросов решается нормальной коммуникацией. Это один из таких примеров.
На проекте по разработке ПО участвовала штатная команда разработчиков и мы, удаленные тестировщики. Для координации работы использовался SCRUM с двухнедельными спринтами. Но в случае с QA всё складывалось не по людски. Задания на тестирование отдавались в пятницу после обеда, а в понедельник с утра уже нужно было выпускать релиз.
Что можно было сделать с нашей стороны?
Возмущаться, обижаться, конфликтовать, уйти с проекта.
Что сделали мы?
В каждом спринте, исходя из его задач, мы четко прописали сколько часов необходимо на тестирование. Этот лимит мы отстояли и утвердили у заказчика. В итоге, разработчики начали четко понимать когда им нужно закончить свою часть, чтобы в понедельник вся команда могла похвастаться успешным релизом без багов.
Что получили в результате?
Мы устранили перекос с планированием времени на проекте, благодаря чему наладился баланс процесса разработки и тестирования. Планируемые сроки на проекте стали более реалистичными взамен авральным. В итоге конечный потребитель стал получать более качественный финальный продукт с меньшим количеством багов.
P.S. Грамотное планирование крайне затруднительно без понимания обстановки на проекте и причин, по которым возникают проблемы. О том как пошагово провести аудит IT проекта, собрать информацию и установить причинно-следственные связи, можно подсмотреть в презентации CTO “Лаборатории Качества” — Олега Грабко.
Пример №4. Четкая постановка задач приводит к нужному результату
Представьте себе ситуацию, когда ваша команда разрабатывает какой-то продукт. Вы трудитесь вместе уже давно и понимаете друг друга с полуслова. Если вам нужно попросить коллегу что-то сделать, то хватит одного предложения, чтобы он вас понял. А если в этой ситуации вдруг возникает новичок, который «шарит», но которому нужно поставить эту же задачу? Одним предложением уже не отделаешься, правильно?
Такая же ситуация возникла у нас на одном из проектов по разработке онлайн-платформы. Описания задач для тестирования были понятны только посвященным. В итоге нужно было ждать пока специалист освободится, и дополнительно общаться чтобы понять сакральный смысл задания.
Что можно было сделать?
Проигнорировать проблему и получить ситуацию, в которой задачи бы выполнялись «так, как это понял я» или по принципу «сделаю вот так, если не так – сам дурак». Недостаток коммуникации неминуемо привёл бы к обидам и отсутствию ожидаемого результата.
Что сделали мы?
Обучили новичка-тестировщика постановке и фиксации задач по принципу SMART. Убедились, что его руководство также ставит задачи по SMART. Выявили узкие термины и сленг на проекте и подготовили краткий глоссарий/словарик.
Как итог: новичку стали поступать понятные и эффективные формулировки для выполнения задач.
Что получили в результате? Наладили коммуникацию на проекте. Снизили затраты времени на обсуждение задач. Повысили качество тестирования.
Пример №5. Экономим время и себе, и заказчикам
Мы работали над программным продуктом для организации торговых мероприятий. В него была внесена доработка – в карточке каждой заявки появилась информация с количеством мест на каждом мероприятии. Но когда задачу нужно было проверить полностью, то понадобились данные о всех торгах. Такого документа у нас не было.
Была база данных, в котором были доступны все названия торгов, и был .json файл в котором были ID торгов, с местами, разбитыми по специализациям. То есть, чтобы узнать точное количество мест, необходимо было складывать все места по разным специализациям. А данные о том, какому торговому мероприятию принадлежит какой ID, вообще были в третьем документе.
Что можно было сделать?
Провести тестирование, исходя из имеющихся данных. Помучиться, вероятно недотестировать продукт, но формально выполнить поставленную задачу.
Что сделали мы?
Наши сотрудники составили единый документ, в котором собрали все данные о том, к какому торговому мероприятию принадлежит конкретный ID и какое количество мест есть на этом торге.
Что получили в результате?
Мы не просто смогли протестировать задачу полностью. Да, мы потратили около 5-6 часов на сведение всех данных в единый файл, но в итоге мы сократили время тестирования до полутора часов.
Если бы не было этого документа, то наверняка мы бы не смогли проверить эту задачу полноценно. Когда данные разбросаны в разных файлах, вероятность срабатывания «человеческого фактора» возрастает в разы. А значит страдает корректность тестирования. В итоге файл помог нам полноценно проверить задачу. Раз затратив время, мы планируем и дальше использовать полученный файл на проекте, экономя время и заказчика, и наших тестировщиков.
Пример №6. Удалённый формат не помеха test-driven development
В рамках одного из проектов по созданию полностью обновленного банковского продукта, нас привлекли к тестированию ещё на стадии разработки. Мы и сами всегда за Test-driven development – оно, как мы знаем, и количество ошибок/переделок минимизирует, да и бюджет экономит.
Только есть один нюанс – новые макеты, новый дизайн, новая логика и новые функции продукта проговаривались, прорисовывались и обсуждались исключительно в офисе: на флипчартах, экранах и так далее. А мы работаем на удалёнке… Разглядывать по скайпу о чем идет речь – удовольствие сомнительное, без этого же теряется львиная доля проектной информации.
Что можно было сделать?
Можно было оставить все как есть. То, что не заметили, не увидели и не услышали – объяснить спецификой удаленной работы и связью по скайпу, оправдываться так каждый раз перед заказчиком.
Что сделали мы?
Наш «удаленный» тестировщик на неделю переехала работать в офис заказчика и полноценно участвовала в процессе корректировки требований, базируясь на будущих проверках. Она активно вносила уточнения и изменения в процесс, исходя из логики последующего тестирования.
Что получили в результате?
Экономию времени на переделку продукта, макетов, ТЗ и других параметров. Потому что без участия тестировщика в команде на стадии обсуждения нового продукта, разработка логически не может предусмотреть все нюансы. В итоге мы получили довольного заказчика и грамотно выстроенный процесс разработки и тестирования.
Пример №7. Излишняя вежливость вредит делу
На проекте тестирования алгоритма распределения заявок, мы столкнулись с очень сложным случаем, в котором долго пришлось искать причину возникновения проблемы. Существовал некий эталонный результат распределения на стороне подрядчика, который мы с самого начала сравнивали со своим. Кредит доверия и сила привычки были настолько сильны, что сама мысль об ошибке в “эталоне” отвергалась заказчиком, как ересь. Нас просили искать где угодно, но не на стороне “эталонного” подрядчика.
Что можно было сделать?
Постесняться спросить, побояться настоять на своём, не поверить что возможна проблема на стороне “эталона”.
Что сделали мы?
Перепроверили наиболее допустимые варианты, а потом настояли на своём и обратились к подрядчику с просьбой проверить ситуацию на их стороне.
Что получили в результате?
Подрядчик подтвердил, что ошибка связана с ними. Проблема была локализована, тестирование завершено в заявленные сроки и с отличными результатами. Подрядчик остался доволен нашей инициативой и что мы не стали занимать пассивную позицию. Переход в наступление позволил избежать процесс фантомного тестирования, который тянулся бы еще очень долго.
Пример №8. Быстрое усиление команд проектов
Иногда наше сотрудничество с заказчиками начинается с небольших проектов, а по мере того, как мы себя проявляем, нам доверяют всё больший объем работ, допускают к новым проектам и дают более сложные задачи. И возникает несоответствие – команда вроде бы усиливается большим количеством специалистов, а процессы тормозятся, потому что новоприбывших нужно погрузить в процессы.
Что можно было сделать?
Объяснить ситуацию заказчику, аргументируя замедление рабочих процессов необходимостью адаптации новых членов команды и неизбежным ростом коммуникаций на проекте.
Что сделали мы?
Использовали свои наработки из других проектов и создали развёрнутые инструкции по погружению новичков, а также регламенты по организационной части.
Что получили в результате?
Мы уменьшили количество коммуникаций на проекте, повысив среднюю эффективность тестирования, которая теперь не падает в зависимости от размера команды. Это помогает в любых ситуациях с перестановками персонала – расширением команды, заменой сотрудников, уходом в отпуск или на больничный. В итоге получаем заказчика, довольного эффективностью работы удаленной команды тестировщиков.
Итоги
Зачем мы собрали эти примеры?
Чтобы напомнить, что проактивность не заложена в ценники, её не требуют от тестировщиков и не задумываются об этом при выборе партнеров. Но если её нет, то вы получите исполнителя, который побоится вам что-то сказать, не решится проверить данные, не пойдет вопреки инструкции, лишний раз не подумает и не сделает важный шаг. А без таких людей проект будет стагнировать, терпеть убытки и выбиваться из сроков. Пассивность — грех, поэтому действуйте, а мы поможем вам получить нужный результат
Хотите записаться на наши тренинги по управлению тест-командой или узнать о нашей услуге удалённого аутсорсингового тестирования?
