Можно поговорить про:
- актуальные баги — чего можно было бы избежать при наличии автопроверок.
- риски в приложении ( тоже чего можно было бы избежать и тратить меньше времени)
- авторитеты в программировании (Мартин Фаулер тот же)
- авторитеты как компании — большие местные вроде  Luxoft-EPAM или западные, "Как тестируют в Google"
- если это стартап, то перспективы покупки: могут спросить о тестировании тоже

Процитировать западных статей — автопроверки вполне хайповая тема.

Если багов нет, или на них плевать, или приложение никому не нужно, и никто нам не пример, и ничего знать не хотим... то оно может так и жить, конечно.

Отвечу на два вопроса сразу.
Нужны - ну потому что две недели назад умудрились сломать прод, и думаю пару сотен тысяч на этом потеряли, подробнее не скажу. Причем там был плавающий баг, который был в проде достаточно давно, но руками мы его вряд ли бы поймали. Тесты в Дженкинсе гоняются по расписанию, могли бы поймать, просто это место было не покрыто.
Почему было не покрыто, и почему разработчики катят в прод без тестирования - тестировщиков сильно не хватает, 80% времени я тестирую руками, и то успеваю проверить смок + новый функционал. Остальные 99% времени занимаются ручным тестированием

Ну вот это менеджеру говорили? Желательно с обоснованием, сколько надо тестировщиков и какие на них планы

Я понимаю, что все плохо)
Но вариант "бросить все и свалить в другое место" пока не предлагать, для меня все таки интересный челлендж сделать выстроить процесс тестирования

Говорил, но видимо не совсем так. У меня все таки нет опыта организации тестирования с 0, так что если есть какие-то материалы на эту тему - скажите, где искать?

у вас не получится выстроить процесс тестирования, если на него не будут давать деньги, а к тестированию будут относиться как к ненужной прокладке между говнокодом и продакшеном.

материалы не подскажу, все исключительно на собственных граблях и только в месте, где понимают, какой value несет тестирование, и готовы содействовать и помогать.

хотя, конечно, если получится, респект, с радостью почитаю об этом.

Окей, понял, спасибо)

Если у вас не хватает тестировщиков, и все что ты можешь - это проверить смоук, и новый функционал, то если ты начнешь писать автотесты, да еще е сли у вас бардак с процессами, то тебе вообще времени ни на что не хватит, или надо будет по 12+ часов работать. Вам надо тестировщиков найти, выстроить процессы с ручным тестированием, а потом автотесты писать по мере свободного времени

Спасибо больше, посмотрю!

ничего разрабам доносить не надо. Доносить надо бизнесу. Или СТО как посреднику между бизнесом и технарями. Если бизнесу автотесты не нужны по каким то объективным причинам(тестирование рынка прототипами и тп) - ну что поделать. Если же нужны, но они не знают или не понимают в чем профит - надо рассказать и показать

Определите, какую проблему хотите решить, тесты нужны чтобы что? После этого доносите проблему до тех, кого она аффектит.

СТО сидит справа от меня, директор по продукту через стол, гендир в 5 метрах. Ну, когда мы в офисе. Значение все вроде понимают, просто все ждут, что я принесу готовый план что и как делать, и который подойдёт в наших условиях.
А моего опыта и знаний не хватает, чтобы просто придти и сказать "вот делаем так и так, потому что <...>, и вот такой профит это принесет".
Собственно, вопрос был в том, где можно хоть какую-то информацию найти.

лиду будет пофигу, если он умный он и так знает зачем автотесты нужны, если не знает - объяснить врядли выйдет.
Менеджер - зависит от того, что за он и какие у него функции. Если это погонщик - тоже толку мало. Выходить надо на бизнес людей. И использовать понятную им аргументацию:
1. Баг на проде с отказом обслуживания клиентов - просер бабла компании. Приводишь примеры 3х последних сильных косяков, можно примрено посчитать сколько юзеров словило проблемы, в зависимости от бизнес-модели перемножить на средний чек или ltv, если были проблемы с регой - посмотреть сколько рег потеряно, перемножить на конверсию в платящих
2. короткое описание сравнительной стоимости критического дефекта при нахождении его на стадии тестирования, или при нахождении его на проде
3. какие простые шаги(процессные) нужно предпринять, чтобы избежать будущих проблем из пункта 1
4. какие долгосрочные шаги(процессные) нужно предпринять, чтобы избежать подобных проблем в перспективе

Ну готовь план. ты видишь проект изнутри, ты видишь в чем главные косяки. от этого и отталкивайся. первые шаги - фикс самых стремных проблем (деплой на прод без аппрува куа например, отсутсвие авто регрессии на ключевые стабильные элементы).

Да, в целом так гораздо понятнее, большое спасибо. Кажется, надо погуглить и поспрашивать про защиту проектов перед заказчиками и защиту бюджета тестирования. Реально просто раньше таким не занимался

Ну я тож когда в первый раз делал - примерно по такой схеме. Главное бизнесу - где они теряют деньги. Абстрактные краосты кода и красивые процессы - им пофигу обычно

Коллеги, привет! Кто какие решения использует для автоматизации тестирования верстки на Java?

Galen