АБ
...
Если аналитик по должности или разраб случайно что-то протестирует, это плохо? А так ещё и таски же есть. Ну или я тебя не понял.
Плохо. Потому что потом ты за эту работу заплатишь еще раз, когда протестируют тестировщики
Size: a a a
2020 June 23
L
Это когда "мы его уже рассмотрели"?) Локализовать ошибку - это прямая обязанность QA. Предлагать решение - в обязанностях обычно не значится.
Если не значится, значит и говорю, кто может и разбирается в проекте на уровне исходников, тот предлагает и ищет первопричину появления (не всегда ведь тестерам кнопочки по инструкции тыкать). Локализация ошибки это одна из способностей QA, за которую ему и платят. Просто QA это личность, которая имеет нетривиальный взгляд и находится наравне с продактом, поэтому не вижу проблемы в том, что он может предлагать и влиять на проектирование с точки зрения плюсов и для разработки и для бизнеса.
.
Плохо. Потому что потом ты за эту работу заплатишь еще раз, когда протестируют тестировщики
А мне нравится когда разраб тестит, а потом пишет что он проверил и как, в отчёте, вот приятно после таких людей двойную работу делать
MP
Если не значится, значит и говорю, кто может и разбирается в проекте на уровне исходников, тот предлагает и ищет первопричину появления (не всегда ведь тестерам кнопочки по инструкции тыкать). Локализация ошибки это одна из способностей QA, за которую ему и платят. Просто QA это личность, которая имеет нетривиальный взгляд и находится наравне с продактом, поэтому не вижу проблемы в том, что он может предлагать и влиять на проектирование с точки зрения плюсов и для разработки и для бизнеса.
Но если нет опыта в разработке то как можно предлагать конкретные решения ?)
L
Но если нет опыта в разработке то как можно предлагать конкретные решения ?)
* кто может и разбирается в проекте на уровне исходников,
L
хуже! мы созваниваемся и она шарит экран мне и бизнес-аналитику :)))
примерно так можно инструкции по работе для пользователей проводить
AG
Ну кто ж спорит. Но понимание ролей и их функций помогает четче определиться в их распределении, даже если оно не соответствует стандарту. Я понимаю, что в компании один и тот же человек может выполнять работу нескольких спецов, но надо разделять, что из этой работы - QA, а что - остальное :)
Ты смешиваешь роли с активностями.
QA - это не роль, это пул задач.
Но ладно, давай. QA - набор активностей, которые должны помогать (и упрощать) достижение командой целевых показателей качества с наименьшими затратами времени и ресурсов.
Является ли участие кого-то, отвечающего за QA, в принятии архитектурных решений в плане, например, тестируемости системы, прозрачности её состояния или, в целом, её соответствия этим самым критериям качества, чем-то, что позволяет это качество обеспечивать?
Не всегда, но в некоторых случаях да, определенно.
И тут мы, конечно, вкатимся в твой светлый безопасный интерпрайзный мир, где всегда есть ЛПР и решения принимает только он, а все остальные не лезут, что б не дай бог бонуса не лишили.
Но, неожиданно, не все команды работают так.
QA - это не роль, это пул задач.
Но ладно, давай. QA - набор активностей, которые должны помогать (и упрощать) достижение командой целевых показателей качества с наименьшими затратами времени и ресурсов.
Является ли участие кого-то, отвечающего за QA, в принятии архитектурных решений в плане, например, тестируемости системы, прозрачности её состояния или, в целом, её соответствия этим самым критериям качества, чем-то, что позволяет это качество обеспечивать?
Не всегда, но в некоторых случаях да, определенно.
И тут мы, конечно, вкатимся в твой светлый безопасный интерпрайзный мир, где всегда есть ЛПР и решения принимает только он, а все остальные не лезут, что б не дай бог бонуса не лишили.
Но, неожиданно, не все команды работают так.
L
Но если нет опыта в разработке то как можно предлагать конкретные решения ?)
но если задаться целью быть таким тестером, то можно на пару лет свалить в разработчики, а потом вернуться в тестеры, хах
T
примерно так можно инструкции по работе для пользователей проводить
в том числе :) мы потом будем видео для них делать. А пока важно понаблюдать как при первом столкновении просходит, где затыки, где непродумано.
.
но если задаться целью быть таким тестером, то можно на пару лет свалить в разработчики, а потом вернуться в тестеры, хах
Наличие этих самых навыков разработки это скорее плюс в карму куа
T
L
...
Наличие этих самых навыков разработки это скорее плюс в карму куа
Также наличие навыков тестера у разраба тоже огромный плюс
.
Да
T
у меня тут в команде неопытный разраб пытался уболтать меня написать ему юнит тесты
MP
но если задаться целью быть таким тестером, то можно на пару лет свалить в разработчики, а потом вернуться в тестеры, хах
Пару лет это чтоб проектировать решения, а если скажем открыть кусок кода и посмотреть что условно калькулятор не на то делит это совсем другой навык разработки )
L
в том числе :) мы потом будем видео для них делать. А пока важно понаблюдать как при первом столкновении просходит, где затыки, где непродумано.
Из опыта, сделайте кнопки побольше, хах
.
Также наличие навыков тестера у разраба тоже огромный плюс
Отличные ребята получаются при этом, имхо
T
Из опыта, сделайте кнопки побольше, хах
ахаха! :) спасибо! это действительно совет на все времена!
L
ахаха! :) спасибо! это действительно совет на все времена!
Да мы просто сдали уже GPS для логистов, там пришлось чекбоксы увеличить
T
Да мы просто сдали уже GPS для логистов, там пришлось чекбоксы увеличить
у нас пока чекбоксов нет :) у нас пока математика шалит. У нас система типо сама маршруты просчитывает укладку комплектов делает с учетом того, какие товары с какими возить можно, что вертикально, что горзинтально, длину вес, машину подбирает, маршрут ей составляет :) логистов учим уже просто модерировать этот процесс