Сегодня я бы хотел затронуть тему процесса разработки программного обеспечения. Если точнее, эта статья о том «Как не превратить офис в поле битвы тестировщиков и разработчиков».
Полгода назад я погрузился в тестирование ПО, мне было интересно и я понял, что это действительно моё. Часами залипал на форумах тестировщиков, читал литературу и изучал процесс разработки ПО. На форумах, в группах и беседах я частенько замечал приколы про взаимодействие тестировщиков и разработчиков, но я не понимал этих шуток и не обращал на это внимание. По крайней мере, пока не попал на стажировку в одну компанию по разработке ПО.
Через пару месяцев я начал догонять смысл этих приколов и активных обсуждений «Tester vs Developer». Так как я был первым тестировщиком в этой компании, освоиться было сложно. Задачам с пустым описанием, но с названиями «протестируй и отпишись», «проверь сайт», «не работает приложение» не было конца, а разработчики и проджект менеджер вообще не знали понятие QA. Всем знакома эта фраза «Без ТЗ – результат ХЗ», так вот там было то же самое. Плюс ко всему этому, никого не волновало то, что продукт мягко говоря «кривоват». В большинство случаев было так: ты получаешь задание «протестируй» — тестируешь, делаешь отчет о найденных дефектах и передаешь их разработчику, ну а у разработчика эта задача могла висеть месяцами. В итоге шеф посчитал, что тестировщик в штате лишний и для меня этот кошмар закончился, ну а продукт так и остался «кривым».
Бывают разные споры, разногласия, но мне кажется, что уже давно пора придумать какой-нибудь простой подход, чтобы избежать подобных случаев.
Скриншот из беседы «QA Alliance»:
Найти дефект — задокументировать — передать разработчику для исправления. Но опять-таки, вроде бы всё просто, если бы не реакция разработчика на свои ошибки. Наверное он просто забыл о том, что задача тестировщика это поиск ошибок и сбоев в функционировании объекта. В итоге мы как дружное сообщество начали давать разные советы бедной даме. Многие предлагали решать вопрос через тимлида, а некоторые даже предлагали набить лицо за такое отношение. Ну а я предложил свой вариант, но многим он показался странным.
Через некоторое время я попал на один интересный проект, в котором проджект менеджер был мостом между тестировщиком и разработчиками. Я не знаю, насколько эта концепция эффективна, но мы за всё время ни разу не поругались. Как баг трекинговую систему мы использовали Trello. Эта система удобна тем, что она вся построена на основе доски и все, что в ней есть, находится на одном экране: и задачи, и история изменений, и любые комментарии. Но это же и главный минус программы. Она слишком простая и не предназначена для больших команд.
От проджект менеджера прилетала задача, во время тестирования каждый баг оформлялся в отдельную карточку и прикреплялся в блок «Баги» с меткой «Недочёт» и с подробным описанием. Затем проджект менеджер задавал приоритет карточке и закидывал одному из разработчиков. Иногда такое бывает, что сроки горят и до встречи с заказчиком нужно проверить самые важные моменты. В таком случае проджект менеджер задавал высокий приоритет багам связанных с бизнес логикой, а баги связанные с UI откладывались на потом. У многих возникнет вопрос " Кто тогда будет отвечать за упущенные баги в прод? ", к сожалению мы сам не в курсе.
Самое важное в таком процессе, это то, что тестировщик не взаимодействует с командой разработчиков, следовательно, нет криков, ссор и споров:
— Да это же баг!
— Нет, это фича!
Если в вашей команде адекватный project manager или product owner, попробуйте протестировать такой подход. Я думаю, что многим понравится.
Конечно же, есть компании, в которых отношение разработчиков и тестировщиков идеальное. Например, в которых за упущенные баги в продакшн и жалобы пользователей отвечает разработчик. В таком случае разработчик сам будет заинтересован в хороших отношениях с тестировщиком. Но опять-таки возникает вопрос " А сколько компании работают по по такому принципу? "
Всем спасибо за внимание.
Автор: Ayzatqa
