товарищи нужна помощь, установил идею, в зависимости закинул селениум веб драйвер и мавен, но не могу это все дело импортнуть, в логах не могу понять в чем дело, напишите в лс если кто - то знает плз

#question #test_design #manual #automation #bus_factor
Чат, есть вопрос по тест-дизайну,

Представьте что есть тестировщики и они педалят тесты и пишут их в тестплан. Все проверки так или иначе ориентированы на грубо говоря какой-то network_id. Каждый нетворк -- это набор выбранных в него "фичей", то есть не факт, что такой нетворк будет создан в реальности. Тестировщики решили насобирать таких нетворков с разными сочетаниями,


Тестировщики эти работают по черному ящику,
Автоматизатор решает эти кейсы автоматизировать, но получает много вопросов от разработчика "ты проверяешь это в другом кейсе, а можно в одном", то есть здесь получается, что тест дизайн от программиста включает знание системы и того, откуда растут ноги у "разных" нетворков. Ручные тестировщики при этом пилят, особо в код не смотря.

Это была ситуация, а теперь вопросы:
1) не вносит ли автоматизатор бас фактор. создавая тесты, в дизайне которых ручные тестировщики не участвуют
2) не лучше ли научить тестировщиков руками тест-дизайнить так, чтобы вопросов от разработчика таких не было (другими словами, тестировщики должны используя белый ящик и классы эквивалентности нарезать тест-кейсов минимально допустимое количество)
3) Не кажется ли вам расхождение автотестов от существующих тест планов бомбой замедленного действия?Даже если они time efficient

да просто нужно признать, что тест-планы для ручного теста не являются single source of truth, и сделать собственный тест-дизайн док, в котором описать как все тест-кейсы создаются. ну то есть у меня нет проблем с тем, чтобы понимать, что обучать ручных тестировщиков может быть дорого и неэффективно, другие задачи сейчас стоят. Главное это не уронить traceability тестов и того, почему данный тест кейс существует.

А просто интересно, какой пример ситуации, когда проверки в двух кейсах, а знание деталей реализации говорит о том, что кейс может быть один?
Просто, там не может быть ситуации, что разработчик исходит из знания внутренних особенностей, исходя из этих знания мы пишем тесты, а при изменении реализации тесты становятся не такими уж хорошими?

Типичный пример: проверка двух типов «аккаунтов», которые наследуют черты общего парент-класса

Тогда bus factor во всей красе. Ибо знать что делает тест будет только один. Разбираться в его записях (если он их всё же оставил) тоже время.

А если вдруг какой-то рефакторинг, и у этих типов станут разные парент-классы, при этом тестируемый функционал внешне не изменится?
Или информация о таких изменениях доносится до тестировщиков, и они будут знать, что надо тесты переписать?

Ну вот я этого и хочу избежать :) но учить тестировщиков автоматизации — серьезный коммитмент, его просто так ни начальство, ни сами тестировщики могут не принять :) сопряжено с повышенными ожиданиями, зарплатных амбициями и тд