Почему вы решили, что у нас нет QA? QA — это одна из задач, просто не выделяем под это отдельных специалистов.
Т.е. вы хотите сказать, что у вас девелоперы тестируют, к примеру, требования / мокапы, собирают различные метрики / ведут тестовую документацию, мониторят плотность дефектов по отношению к функциональным областям во времени и т.п.? Я ведь не зря попросил описать ваши процессы. Что, к примеру, входит в скоуп имеено ваших задач на проекте(-ах)?
Разделение testing и QA, это как разделение кодер и программист
Прошу заметить, что я написал testing (как процесс), а не tester (как сленговая характеристика позиции). И прежде чем заводить дискуссию на тему тестирования с девелопером, хотелось бы для начала понимать, что именно вы вкладываете в это понятие (в качестве процесса, а не определения из учебника)?
Вот вы поделились своим опытом, что работу всех тех QA, которые вам встречались, можно было бы смело автоматизировать. Потому собственно вы и не видите смысла в позиции manual QA, как таковой. А я вот, к примеру, практически не встречал программистов, реально понимающих QA процессы. Но в целом, это нормально, поскольку для этого существуют соответствующие специалисты. Каждый занимается своим делом, не обучая других жизни, и не вставляя палки в колеса. Следовательно, в условиях плотной кооперации, вся команда достигает положительного результата. А рассказывать о том, что какая-то специализация бесполезна, исходя лишь из своего личного опыта, — ни чуть не лучше использования сленговых "кодер" и "тестер". Тем самым, вы закинули огромный камень в огород QA инженеров, среди которых много толковых ребят.
А зачем нужны тестировщики, я имею ввиду как отдельный класс? Я всегда считал, что тестировать код — ответственность программиста.
Похоже, вы слепо верите в то, что тестирование — это лишь процесс поиска дефектов в приложении, а программист — в состоянии дать объективную оценку своего собственного кода.
Интереса ради, опишите ваш текущий процесс: как разработчики проводят планирование, тестирование, анализ, ретроспективы без участия QA? Над какими продуктами по масштабу вам приходилось работать? Да и к слову, чем по-вашему testing отличается от QA?
Касательно масштабирования тестов — идея то замечательная. Но если у вас на этой почве начали падать больше половины тестов, сдается мне, что проблему надо искать на уровне конфигурации / архитектуры вашего фреймворка, а не городить workarounds в виде IRetryAnalyzer.
К слову, сама фича — весьма сомнительна. Соглашусь с комментарием snowrain по поводу сокрытия реальных проблем. Многие ошибочно считают, что конечная цель автоматизации — зеленый репорт. Но вот только к кому потом прибежит менеджмент, когда рандомный баг, сокрытый сей чудесной фичей, всплывет на продакшене?
Помимо всего прочего, представьте ситуацию, когда, к примеру, билд вообще лежит, а тесты запустились ночью по расписанию. В итоге, благодаря IRetryAnalyzer вы будете ломиться в мертвое окружение x3 раз (исходя из ваших ограничений).
Насчет репортинга тоже усложнили. Как вы думаете, что проще — добавить нужные фичи в существующее решение, или с нуля написать свое? Рекомендую посмотреть в сторону Allure, ExtentReports, ну или на худой конец — ReportNG. При желании и наличии определенных навыков программирования, любой из них можно адаптировать под ваши нужды. Но показывать стейкхолдерам гусей и прочих животных на пол экрана — нонсенс.
Т.е. вы хотите сказать, что у вас девелоперы тестируют, к примеру, требования / мокапы, собирают различные метрики / ведут тестовую документацию, мониторят плотность дефектов по отношению к функциональным областям во времени и т.п.? Я ведь не зря попросил описать ваши процессы. Что, к примеру, входит в скоуп имеено ваших задач на проекте(-ах)?
Прошу заметить, что я написал
testing(как процесс), а неtester(как сленговая характеристика позиции). И прежде чем заводить дискуссию на тему тестирования с девелопером, хотелось бы для начала понимать, что именно вы вкладываете в это понятие (в качестве процесса, а не определения из учебника)?Вот вы поделились своим опытом, что работу всех тех QA, которые вам встречались, можно было бы смело автоматизировать. Потому собственно вы и не видите смысла в позиции
manual QA, как таковой. А я вот, к примеру, практически не встречал программистов, реально понимающих QA процессы. Но в целом, это нормально, поскольку для этого существуют соответствующие специалисты. Каждый занимается своим делом, не обучая других жизни, и не вставляя палки в колеса. Следовательно, в условиях плотной кооперации, вся команда достигает положительного результата. А рассказывать о том, что какая-то специализация бесполезна, исходя лишь из своего личного опыта, — ни чуть не лучше использования сленговых "кодер" и "тестер". Тем самым, вы закинули огромный камень в огород QA инженеров, среди которых много толковых ребят.Все профессии нужны, все профессии важны. (с)
Похоже, вы слепо верите в то, что тестирование — это лишь процесс поиска дефектов в приложении, а программист — в состоянии дать объективную оценку своего собственного кода.
Интереса ради, опишите ваш текущий процесс: как разработчики проводят планирование, тестирование, анализ, ретроспективы без участия QA? Над какими продуктами по масштабу вам приходилось работать? Да и к слову, чем по-вашему testing отличается от QA?
По всей видимости, речь все же шла об Алексее Баранцеве?
К слову, сама фича — весьма сомнительна. Соглашусь с комментарием snowrain по поводу сокрытия реальных проблем. Многие ошибочно считают, что конечная цель автоматизации — зеленый репорт. Но вот только к кому потом прибежит менеджмент, когда рандомный баг, сокрытый сей чудесной фичей, всплывет на продакшене?
Помимо всего прочего, представьте ситуацию, когда, к примеру, билд вообще лежит, а тесты запустились ночью по расписанию. В итоге, благодаря IRetryAnalyzer вы будете ломиться в мертвое окружение x3 раз (исходя из ваших ограничений).
Насчет репортинга тоже усложнили. Как вы думаете, что проще — добавить нужные фичи в существующее решение, или с нуля написать свое? Рекомендую посмотреть в сторону Allure, ExtentReports, ну или на худой конец — ReportNG. При желании и наличии определенных навыков программирования, любой из них можно адаптировать под ваши нужды. Но показывать стейкхолдерам гусей и прочих животных на пол экрана — нонсенс.