Полгода назад я погрузился в тестирование ПО, мне было интересно и я понял, что это действительно моё. Часами залипал на форумах тестировщиков, читал литературу и изучал процесс разработки ПО. На форумах, в группах и беседах я частенько замечал приколы про взаимодействие тестировщиков и разработчиков, но я не понимал этих шуток и не обращал на это внимание. По крайней мере, пока не попал на стажировку в одну компанию по разработке ПО.
Через пару месяцев я начал догонять смысл этих приколов и активных обсуждений «Tester vs Developer». Так как я был первым тестировщиком в этой компании, освоиться было сложно. Задачам с пустым описанием, но с названиями «протестируй и отпишись», «проверь сайт», «не работает приложение» не было конца, а разработчики и проджект менеджер вообще не знали понятие QA. Всем знакома эта фраза «Без ТЗ – результат ХЗ», так вот там было тоже самое. Плюс ко всему этому, никого не волновало то, что продукт мягко говоря «кривоват». В большинство случаев было так: ты получаешь задание «протестируй» — тестируешь, делаешь отчет о найденных дефектах и передаешь их разработчику, ну а у разработчика эта задача могла висеть месяцами. В итоге шеф посчитал, что тестировщик в штате лишний и для меня этот кошмар закончился, ну а продукт так и остался «кривым».
Бывают разные споры, разногласия, но мне кажется, что уже давно пора придумать какой-нибудь простой подход, чтобы избежать подобных случаев.
Скриншот из беседы тестировщиков ПО:
Найти дефект — задокументировать — передать разработчику для исправления. Но опять-таки, вроде бы всё просто, если бы не реакция разработчика на свои ошибки. Наверное он просто забыл о том, что задача тестировщика это поиск ошибок и сбоев в функционировании объекта. В итоге мы как дружное сообщество начали давать разные советы бедной даме. Многие предлагали решать вопрос через тимлида, а некоторые даже предлагали набить лицо за такое отношение. Ну а я предложил свой вариант, но многим он показался странным.
Через некоторое время я попал на один интересный проект, в котором проджект менеджер был мостом между тестировщиком и разработчиками. Я не знаю, насколько эта концепция эффективна, но мы за всё время ни разу не поругались. Как баг трекинговую систему мы использовали Trello. Эта система удобна тем, что она вся построена на основе доски и все, что в ней есть, находится на одном экране: и задачи, и история изменений, и любые комментарии. Но это же и главный минус программы. Она слишком простая и не предназначена для больших команд.
От проджект менеджера прилетала задача, во время тестирования каждый баг оформлялся в отдельную карточку и прикреплялся в блок «Баги» с меткой «Недочёт» и с подробным описанием. Затем проджект менеджер задавал приоритет карточке и закидывал одному из разработчиков. Иногда такое бывает, что сроки горят и до встречи с заказчиком нужно проверить самые важные моменты. В таком случае проджект менеджер задавал высокий приоритет багам связанных с бизнес логикой, а баги связанные с UI откладывались на потом. У многих возникнет вопрос " Кто тогда будет отвечать за упущенные баги в прод? ", к сожалению мы сам не в курсе.
Самое важное в таком процессе, это то, что тестировщик не взаимодействует с командой разработчиков, следовательно, нет криков, ссор и споров:
— Да это же баг!
— Нет, это фича!
Если в вашей команде адекватный project manager или product owner, попробуйте протестировать такой подход. Я думаю, что многим понравится.
Конечно же, есть компании, в которых отношение разработчиков и тестировщиков идеальное. Например, в которых за упущенные баги в продакшн и жалобы пользователей отвечает разработчик. В таком случае разработчик сам будет заинтересован в хороших отношениях с тестировщиком. Но опять-таки возникает вопрос " А сколько компании работают по по такому принципу? "
Всем спасибо за внимание.
Комментарии (27)
Durimar123
30.09.2016 15:39+3Не знаю, не знаю им и так беднягам достается.
Лично я, как только тестеры находят баг в моем коде или даже смежном, говорю им «Биг сенкс! — без вас не прога была бы, а ....»
зы
да и опять таки — тестеры это крыша для программеров, если вдруг в релизе вылез баг, то на вопли менеджеров спокойно отсылаешь их в отдел тестирования.
Так и говорю им, культурно,- «Я же не могу исправить того чего нет на багтреке? Так что идите вы в отдел тестирования, пожалуйста.»
izzholtik
30.09.2016 15:53Есть багтрекер — нет проблем. Очевидные баги программисты исправляют без вопросов, оставшиеся спортные ситуации и вопросы о багофичах разрешит менеджер/тимлид.
fishca
30.09.2016 16:20Что разработчик, что тестировщик — обычные люди, которые могут ошибаться. Но каждый по своему. Надо это понимать и работать в команде.
ivanych
30.09.2016 18:17Между программистами и тестировщиками должен быть не менеджер, а CI. На CI орать бесполезно. Вот и весь секрет гармонии:)
Skreep
01.10.2016 00:18Мне кажется, проблема несколько надумана. Сам уже давно являюсь руководителем небольшой команды, а до того еще дольше был разработчиком, но с этой проблемой встречался всего раз, да и то в связке сисадмин/тестировщик. Сисадмина, к слову, сменили.
sentyaev
01.10.2016 02:50+2А зачем нужны тестировщики, я имею ввиду как отдельный класс? Я всегда считал, что тестировать код — ответственность программиста.
Постоянно наблюдал такую картину — есть тестировщики, нет тестов.
Часто говорят, что тесты дорого, но ведь единожды написав тест, его можно запускать сколько угодно раз.
Еще будучи молодым и неопытным я работал в компании где было всего 5 разработчиков (собственно это и была вся компания), так там было правило — нашел баг, напиши тест который доказывает, что этот баг есть и отправь его разработчику который отвечает за этот код. Это было прекрасно. Т.е. не пишешь в таске, что «там на странице №3 валидация не работает», а коммитишь тест который это доказывает.
Да и сейчас работаю в компании с десятками программистов и тоже нет тестировщиков, и баги это наша ответственность, поэтому есть тесты (не буду же я прокликивать приложение по 20 раз в день).Dolbe
01.10.2016 22:21Помимо «тестирования кода» есть же еще много разных видов тестирования. Ручное, например, или нагрузочное. Например, тестировщик, занимающийся ручным тестированием, знает много-много бизнес-логики и должен ее всю держать постоянно в голове. Если этим (с таким погружением) будут заниматься программисты, то никаким программированием они не будут успевать заниматься.
sentyaev
01.10.2016 23:05Кто по вашему занимается нагрузочным тестированием?
Например, тестировщик, занимающийся ручным тестированием, знает много-много бизнес-логики и должен ее всю держать постоянно в голове. Если этим (с таким погружением) будут заниматься программисты, то никаким программированием они не будут успевать заниматься.
Это высказывание противоречит само себе. Ведь эту бизнес логику программист должен сначала запрограммировать, причем учесть все возможные условия и ограничения. Учитывая это, он может написать тесты прокрывающие эту бизнес логику. Я трачу достаточно много времени общаясь с бизнесом, чтобы разобраться в деталях.
sentyaev
01.10.2016 23:13Да и тестирование — это не «тестирование кода», это доказательство корректности программы. Есть же unit testing — как раз то, что вы называете «тестирование кода», есть integration testing — тестирование взаимодействия различных частей системы, есть behavior testing — тестирование на уровне фич.
Я к тому, что программист он и тестировщик тоже.Dolbe
02.10.2016 10:03Давайте, для начала, вспомним, что фразу «тестирование кода» это Вы сказали, а не я. Да, я за нее зацепился.
По-моему, нагрузочным тестированием занимаются специалисты по нагрузочному тестированию. Разве нет?
В целом Вы правы, программист должен протестировать то, что он сделал. Но например, после написания какого-то модуля/функционала, переключившись на другую задачу да месяц-другой, и вернувшись к этому модулю обратно — даже если там никто ничего не поменял за это время, сложно вспомнить все нюансы и тонкости логики. Да, написанные тесты облегчают регрессионное тестирование, как Вы и сказали, но эти тесты, как я считаю, должны писать не те же программисты, которые реализуют бизнес-логику, а как раз тестировщики, которые больше по бизнес-логике и, независимо от того, какой именно программист переписывал логику, именно тестировщик должен эту логику знать.
Ведь, если программисты были бы лучшими тестировщиками, чем сами тестировщики — то получается, что и тестировщики были бы не нужны. Но они же нужны! Или Вы считаете, что тестировщики нужны там, где плохие программисты?
ИМХО, тестировщики нужны там, где система реально большая и сложная. Ведь, если программист «пришел» переписывать/дописывать какой-то функционал, он может не знать всех тонкостей реализации данного модуля и что имено надо протестировать.sentyaev
02.10.2016 18:19+1Давайте, для начала, вспомним, что фразу «тестирование кода» это Вы сказали, а не я. Да, я за нее зацепился.
Да, я тут неточно выразился. Имел ввиду тестирование, а не тестирование кода.
По-моему, нагрузочным тестированием занимаются специалисты по нагрузочному тестированию. Разве нет?
Не встречал таких, всегда сами делали.
Да, написанные тесты облегчают регрессионное тестирование, как Вы и сказали, но эти тесты, как я считаю, должны писать не те же программисты, которые реализуют бизнес-логику, а как раз тестировщики, которые больше по бизнес-логике и, независимо от того, какой именно программист переписывал логику, именно тестировщик должен эту логику знать.
Смотрите, чтобы запрограммировать нечто, мне нужно досконально разобраться в задаче, и чтобы изменить это нечто, даже если я это не писал, мне снова придется досконально разобраться в том, как оно работает. Если сразу написать тест, то проверять потом ничего не нужно.
Ведь, если программисты были бы лучшими тестировщиками, чем сами тестировщики — то получается, что и тестировщики были бы не нужны. Но они же нужны!
Ту работу тестировщиков которую я видел, можно было автоматизировать. Я считаю, если тестировщик не автоматизирует свою работу, то это плохой тестировщик.
Или Вы считаете, что тестировщики нужны там, где плохие программисты?
Да, в большинстве случаев.
Ведь, если программист «пришел» переписывать/дописывать какой-то функционал, он может не знать всех тонкостей реализации данного модуля и что имено надо протестировать.
Вот именно эту проблему решают тесты, если что-то сделал не так, тесты не пройдут.
Я считаю, что тестирование неразрывно от программирования и программист должен писать тесты.Dolbe
02.10.2016 20:15Не встречал таких, всегда сами делали.
Вот небольшая подборочка. Да, не все вакансии подходят только под нагрузочное тестирование, но все же: hh.ru
Ту работу тестировщиков которую я видел, можно было автоматизировать. Я считаю, если тестировщик не автоматизирует свою работу, то это плохой тестировщик.
На моей практике тестировщики тестируют не только конкретные реализованные фичи и баги, но и находят новые, часто даже там, где сложно предугадать всем, даже программистам. (Ах-ха, я забыл, это плохие программисты, у них же есть тестировщики).
Вот именно эту проблему решают тесты, если что-то сделал не так, тесты не пройдут.
Вы, наверное, и правда никогда не делаете ошибок, особенно в тестах, которые покрывают всё-всё. Каждый день, наверное, звонят, предлагают работу?
А если серьезно. Вы участвовали когда-нибудь в разработке по-настоящему больших систем в очень больших (ну или многочисленных) командах разработчиков?
Например, банковское ПО. Я видел ситуацию, где было около 7-8 систем, каждая из которых «тянет» данные из остальных. Каждую систему разрабатывает какая-то конкретная команда программистов. Код покрыт юнит-тестами. Обновления систем происходят одновременно около 4-х раз в год. Думаете, и тут без тестировщиков можно обойтись?sentyaev
03.10.2016 01:38Вот небольшая подборочка. Да, не все вакансии подходят только под нагрузочное тестирование, но все же: hh.ru
Наличие вакансий мало о чем говорит. Я посмотрел требования, по сути под навыками нагрузочного тестирования там понимается использование тулов типа JMeter. Этого бывает недостаточно, приходится иногда свои тулы писать. И в дополнение, вот я сам пользуюсь JMeter когда нужно.
Вы, наверное, и правда никогда не делаете ошибок, особенно в тестах, которые покрывают всё-всё.
Конечно делаю, кучу ошибок, а потом их исправляю. Это моя ответственность.
А если серьезно. Вы участвовали когда-нибудь в разработке по-настоящему больших систем в очень больших (ну или многочисленных) командах разработчиков?
Я предлагаю не переходить на личности, если вас интересует мой опыт, его легко нагуглить.
Например, банковское ПО. Я видел ситуацию, где было около 7-8 систем, каждая из которых «тянет» данные из остальных. Каждую систему разрабатывает какая-то конкретная команда программистов. Код покрыт юнит-тестами. Обновления систем происходят одновременно около 4-х раз в год. Думаете, и тут без тестировщиков можно обойтись?
Смотрите, мой основной посыл был такой: «А зачем нужны тестировщики, я имею ввиду как отдельный класс? Я всегда считал, что тестировать код — ответственность программиста.»
Т.е. я не говорил о том, что тестировать приложения не нужно или что QA это лишнее. Я лишь говорил о том, что тестирование — это ответственность разработчика и нет необходимости нанимать отдельных людей.
И конечно же это мое личное мнение, но оно сложилось из опыта.
И я согласен с тем, что бывает нужно выделить команду тестирования, но это те же программисты, которые тоже пишут код, только для тестов, а не бизнес логики (и это не то, что понимают под тестировщиком, который пишет автотесты).Dolbe
03.10.2016 10:21там понимается использование тулов типа JMeter. Этого бывает недостаточно, приходится иногда свои тулы писать
Не спорю, когда я работал специалистом по нагрузочному тестированию, было необходимо не только JMeter использовать, но и свои скритпты на Python, Perl, etc. писать. Также, например, необходимо было и в профилировщиках СУБД разбираться (Oracle, на тот момент).
Я предлагаю не переходить на личности
Искренне извиняюсь, если так получилось. Не хотел переходить на личности.
Я лишь говорил о том, что тестирование — это ответственность разработчика и нет необходимости нанимать отдельных людей.
И конечно же это мое личное мнение, но оно сложилось из опыта.
Да уж, и правда, мы с Вами по-разному смотрим на процесс.
И я согласен с тем, что бывает нужно выделить команду тестирования, но это те же программисты, которые тоже пишут код, только для тестов, а не бизнес логики (и это не то, что понимают под тестировщиком, который пишет автотесты).
Мой посыл, как раз, в том, чтобы не было людей-оркестров. До сих пор, мне кажется, это держится в тренде — разделять обязанности и ответственность. Все к этому привыкли.
sskorol
02.10.2016 10:38А зачем нужны тестировщики, я имею ввиду как отдельный класс? Я всегда считал, что тестировать код — ответственность программиста.
Похоже, вы слепо верите в то, что тестирование — это лишь процесс поиска дефектов в приложении, а программист — в состоянии дать объективную оценку своего собственного кода.
Интереса ради, опишите ваш текущий процесс: как разработчики проводят планирование, тестирование, анализ, ретроспективы без участия QA? Над какими продуктами по масштабу вам приходилось работать? Да и к слову, чем по-вашему testing отличается от QA?sentyaev
02.10.2016 18:34Интереса ради, опишите ваш текущий процесс: как разработчики проводят планирование, тестирование, анализ, ретроспективы без участия QA?
Почему вы решили, что у нас нет QA? QA — это одна из задач, просто не выделяем под это отдельных специалистов.
Над какими продуктами по масштабу вам приходилось работать?
Мой профиль Linkedin легко гуглится, там все есть.
Да и к слову, чем по-вашему testing отличается от QA?
Разделение testing и QA, это как разделение кодер и программист, что я считаю с одной стороны неверным, а с другой оскорбительным, т.к. слова тестер и кодер обычно используют в негативных высказываниях. (Если я правильно понял, что вы имеете ввиду).sskorol
02.10.2016 20:11Почему вы решили, что у нас нет QA? QA — это одна из задач, просто не выделяем под это отдельных специалистов.
Т.е. вы хотите сказать, что у вас девелоперы тестируют, к примеру, требования / мокапы, собирают различные метрики / ведут тестовую документацию, мониторят плотность дефектов по отношению к функциональным областям во времени и т.п.? Я ведь не зря попросил описать ваши процессы. Что, к примеру, входит в скоуп имеено ваших задач на проекте(-ах)?
Разделение testing и QA, это как разделение кодер и программист
Прошу заметить, что я написал
testing(как процесс), а неtester(как сленговая характеристика позиции). И прежде чем заводить дискуссию на тему тестирования с девелопером, хотелось бы для начала понимать, что именно вы вкладываете в это понятие (в качестве процесса, а не определения из учебника)?
Вот вы поделились своим опытом, что работу всех тех QA, которые вам встречались, можно было бы смело автоматизировать. Потому собственно вы и не видите смысла в позиции
manual QA, как таковой. А я вот, к примеру, практически не встречал программистов, реально понимающих QA процессы. Но в целом, это нормально, поскольку для этого существуют соответствующие специалисты. Каждый занимается своим делом, не обучая других жизни, и не вставляя палки в колеса. Следовательно, в условиях плотной кооперации, вся команда достигает положительного результата. А рассказывать о том, что какая-то специализация бесполезна, исходя лишь из своего личного опыта, — ни чуть не лучше использования сленговых "кодер" и "тестер". Тем самым, вы закинули огромный камень в огород QA инженеров, среди которых много толковых ребят.
Все профессии нужны, все профессии важны. (с)
sentyaev
03.10.2016 01:57Т.е. вы хотите сказать, что у вас девелоперы тестируют, к примеру, требования / мокапы, собирают различные метрики / ведут тестовую документацию, мониторят плотность дефектов по отношению к функциональным областям во времени и т.п.? Я ведь не зря попросил описать ваши процессы. Что, к примеру, входит в скоуп имеено ваших задач на проекте(-ах)?
У нас полный agile) Я серьезно.
Требования/мокапы — команда обсуждает и уточняет их еженедельно (заказчик — часть команды), мокапы делает заказчик в основном.
Тестирование — ответственность разработчика, т.е. если что-то не работает, то виноват разработчик.
Метрики/плотность дефектов — это моя ответственность как тимлида.
Тестовая документация — у меня есть тесты.
Прошу заметить, что я написал testing (как процесс), а не tester (как сленговая характеристика позиции).
Спасибо за уточнение.
Потому собственно вы и не видите смысла в позиции manual QA, как таковой.
Просто я и сам это делаю.
А я вот, к примеру, практически не встречал программистов, реально понимающих QA процессы.
Я изменил свое отношение к QA когда защищал димлом, мне снизили балл как раз за то, что у меня не было тестов и тестплана.
И да, это печально, что много программистов не понимают тестирование.
Тем самым, вы закинули огромный камень в огород QA инженеров, среди которых много толковых ребят.
Я лишь говорю о том, что программист и QA инженер должны быть одним человеком. Ни в коем случае не хотел кого-либо задеть.
BlackDizel
02.10.2016 19:04вы, имо, конечно правы по принципу: «Кто сторожит сторожей» в замечании
программист — в состоянии дать объективную оценку своего собственного кода.
но слишком переоцениваете QA, что видно из
чем по-вашему testing отличается от QA?
Есть qa, нет его, и есть только «testing»—конечная задача всего этого действа сдать проект заказчику с «приемлемым качеством».
Zeitung
03.10.2016 20:30Тут есть несколько подводных камней.
1) Я работал на проекте, которому уже больше 8 лет, на котором тестирование не автоматизировалось совсем. Там такое колличество кода и функционала, что просто написать с ноля «классическую» тестовую документацию (забить тест кейсы в какой-нить тул) займёт где-то месяцев 6 у всей QA тимы, а потом ещё месяца 3, чтоб догнать все изменения, которые были сделаны за эти пол года. Не говоря уже о покрытии всего этого тестами. Т.е. разработку нужно будет закрыть на год. Или нанять отдельную команду, которая будет только автоматизировать. Ну я таких заказчиков ещё не видел. В лучшем случае просят просто переписать всю систему с нуля и её уже покрывать тестами (как минимум «оригинал» прийдётся переделывать к тому виду чтоб он без костылей принимал Моки). Проект с нуля это другая история. А в ситуации выше без QA не знаю как обойтись. Да проект\момент упущен, но не нужно забывать, что не всегда Вам прийдётся работать над новыми системами…
2) Сейчас я работаю на проекте, в котором все тесты должны быть автоматизированны (как часть деливери). Девелоперы пишут Юнит и Интегрейшин тесты. Отдел QA — system-tests (т.е. мы не используем Моки, а пытаемся следовать юзер-кейсам). Изначально я скептически к этому относился (ну то есть авто тесты — круто, но покрыть ВСЁ это перебор), но через 3 месяца вырисовалась картина, что автоматизировать можно действительно всё. Но если на простых компонентах тесты пишутся быстро, то в тех местах где появляется средненький уровень взаимодействия с юзером, то сложность тест кода возрастает в разы. И вот тут вываливается огромная проблема.
3) Я не видел ещё программиста который по собственному желанию будет писать тесты для кода, написанного другим программистом. Можно нанять отдельного человека писать только тесты. НО! В головах работодателей до сих пор бытует мнение что QA это низкоквалифицированная работа. Соответственно ЗП на эту позицию ниже. Если есть выбор пойти в отдел QA или в отдел разработки — ответ становится очевиден. Тем кто в итоге попадает в такую команду — очень не хватает опыта. Вкладывать деньги в образование персонала — очень врятли, да и времени нет. Поэтому качество написанных тестов резко падает с увеличением сложности бизнесс логики. В итоге мне как тимлиду либо приходится переписывать тест код самому (когда уже капец времени нет), либо наперёд писать мини-фреймворк (в моём понимании это план, которому нужно следовать для тестирования похожих сценариев но с разным ожидаемым результатом), либо заставлять по 3 раза переписывать одно и тоже, т.к. колличество копипаста зашкаливает и т.п.
4) На мой взгляд возможным решением тут был-бы наём Junior«ов тестить чужой код с обещанием промоушена через год. Но тут уже появляется проблема снобства и не желанием или нехваткой времени у старших учить правильно кодить.
5) Я рад что у Вас „полный agile“, и у Вас есть возможность собрать фидбек от пользователей. Но QA очень часто приходится просить изменить UI или весь user case, т.к. логическая цепочка слишком сложная либо не очевидная. Да это проблема проектирования и документации, но именно тестирование документации тоже является частью работы QA. А потом ещё пойди докажи PM, SA и Dev, что после релиза саппорт будет завален звонками.
Ещё хотелось-бы добавить, что тестировать СВОЙ код (white box) — очень плохая практика. Не зря всегда выделяют „black box“ тестинг…
Я свои приложения всегда даю попользовать знакомым\семье. И всегда появляются упущенные сценарии либо не понимание workflow. Банально некоторые вещи слишком заумные. Для меня было шоком, когда 3 человека не смогли найти страничку favorites, которая открывалась по тапу стандартной иконки „звёздочка“.sentyaev
03.10.2016 22:16По первому пункту согласен полностью, тоже бывали такие проекты. Мне помогла книга Работа с унаслелованным кодом. Проблемы такого проекта не решить наверно и за год, но эта книга хотябы помогает начать.
Я не видел ещё программиста который по собственному желанию будет писать тесты для кода, написанного другим программистом.
Да, проблема есть. Я пробую pair programming, иногда помогает.
НО! В головах работодателей до сих пор бытует мнение что QA это низкоквалифицированная работа.
Вот тут вы прямо в точку попали. Обычно у этих работадателей и программисы так себе (не буду утверждать, это из личного опыта).
victorvsk
01.10.2016 13:53Часто конфликты, вне зависимости от профессии, при работе над смежными задачами с обязанностями одного уровня, возникает из-за различия уровня компетенции (или субъективной оценки уровня компетенции себя\коллеги).
Например, Вы же описали, что вам не нравится, когда приходит [некомпетентное] описание задачи «протестируй сайт», точно так же разработчику не нравится [некомпетентное] описание бага «пустая страница при переходе в корзину» вместо «реквест таймаут со статусом 504 при переходе в корзину, когда там находится товар с количеством миллион единиц». В итоге, разработчику нужно тратить свое время на тестирование (работу тестировщика), что бы разобраться, в чем же причина, ведь в тех случаях, что он предварительно проверил — все работает. Кстати, на практике достаточно часто получается, что ошибка совсем в другом месте, или даже совсем не зависит от разработчика и разработчик ее не может исправить.
Ситуация наоборот, это, например, когда разработчик не обрабатывает простейшие случаи: при переходе в корзину шаблон выбрасывает исключение, потому что товаров нет (а у самого разработчика для тестов корзина заполнена), добавили скидку по формуле цена = цена — цена / скидка, но если у пользователя нет скидки — то происходит деление на 0 и т.д.
Zeitung
01.10.2016 13:53Багтреккер это одновременно прикрытие и для девелоперов и для тестировщиков. Даже если компания только начинает путь становления, то можно использовать любой таск менеджер или на крайний случай shared online documents. Найти общий язык девелоперам и тестировщикам довольно просто, только если один из них не возомнил себя пупом мира («баг в моём божественном коде существовать просто не может» или «эта кнопка находится на 1px ниже чем я предполагаю, поэтому мы ничего не деплоим в продакшин»). Но третий человек должен быть для принятия бизнесс решений (хотя-бы сделать выборку тех багов которые должны быть пофикшены перед релизом), и желательно образование\опыт этого человека должно быть хоть немного лежать в плоскости ИТ или разрабатываемого продукта. Меня сейчас кинули на проект, который уже давно жёстко отстаёт от сроков. Девелоперы просто игнорят все имейлы и тикеты от QA. А ПМ на проекте только для навешивания лапши кастомеру и проведения Daily stand up. Смотреть список открытых багов это из разряда космических технологий, да и если продемонстрировать как это сделать — пользы никакой.
demshin
В нашей компании тестировщики и разработчики постоянно тесно взаимодействуют. И никаких конфликтов не возникает. Адекватность — наше все.
А третье лицо при взаимодействии разработчиков и тестировщиков только усложнит процесс.