Alexej Simakov

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

Исходя из этого могу предположить, что тестировали функционал через исследовательское тестирование по методу черной коробки. Значит вам нужно именно end-to-end тестирование.
Раз проект для веба и без дополнительных трат, то очевидный ответ - Selenium. Про него написано-переписано и на конференциях рассказано тоннами. Selenium поддерживает несколько языков Java, C#, Ruby, Python. Самый низкий порог вхождения у Python. Почитать/посмотреть про page object pattern и вперед.
Мне тут как-то на глаза попадался вполне достойный и даже бесплатный курс "Автоматизация тестирования с помощью Selenium и Python".
На будущее, для диагноза затруднений возникающих в процессе внедрения автоматизации и нахождения возможных путей выхода из них на макро и микро уровне могу посоветовать этот ресурс - testautomationpatterns.org - одна из его создателей небезызвестная Dorothy Graham.

airtest, pywinauto, pywin32, sikulix, Winium, WinAppDriver

Вы в рассуждении говорите о "последовательности" выпадения. Тут нет никакой "последовательности". Монеты можно бросить все сразу или по очереди - разницы нет никакой.

Альтернативно можно решать другую задачу. У нас кубики с пронумерованными сторнами. Первый кубик имеет три стороны (ну представим себе такой), второй - пять, третий - 7, следующий - 2*i+1. Соответственно выбросить единицу на каждом кубике мы можем с вероятностью 1/2*i+1. Нас интересует вероятность того. что после броска всех кубиков количество единиц на них будет нечетным.
Вспомним элементарную задачу. Пусть у нас два шестигранных кубика. Как мы посчитаем вероятность того что мы получим две единицы? Количество благоприятствующих исходов к количеству возможных исходов. т.е. 1 исход из 11. Идем дальше, у нас два кубика. Какова вероятность того что мы бросим нечетное количество единиц? Это вероятность единицы на одном кубике помноженная на вероятнось "не-единицы" на другом. Т.е. 1/6 * 5/6.

Думаю такой подсказки будет достаточно.

Вообще не понимаю зачем брать инструмент для нагрузочного тестирования, когда нужно просто автоматизировать взаимодействие с веб страницей. Не приходилось им пользоваться, так что по самому инструменту ничем не помогу.
Сам принцип довольно простой.
Скрипт берет html страницы и выявляет в нем ней нужные элементы. A потом производит нужное действие в зависимости от того какие элементы нашлись. Если это input type=text - вводит в него значение "test", если это input type=radio то выбирает тот в котором значение самое длинное. Для парсинга html есть там всякиe библиотеки например beautifulsoup.

Абстракции являются способом добавить системе модульности. Потому что требования к (крупной) системе постоянно меняются. Тут заменяемость и расширяемость - важные факторы. Обычно это еще называют "гибкостью". Привязываться к конкретным имплементациям - очень быстро выходит боком. Поэтому все на абстракциях, даже там где они возможно не нужны. Но поскольку инженер не знает, что заказчик захочет завтра - сразу все заворачивает в абстракции. Отсюда появляется масса кода который просто поддерживает эту расширяемость. Поэтому когда смотришь на конечный продукт и на тот код из которого он сделан, думаешь это ведь можно было уместить в 100МБ, а у нас система на 6 Гб. Да, если конечный алгоритм отлить в железе он будет компактным но не будет расширяемым. Это "цена" за возможность внесения корректировок в систему, не переделывая систему целиком.

Нет конечно, если программой такая возможность не предусмотрена. Это надо доки на программу читать.

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

https://github.com/replit однако как это все собрать у себя на машине - понятия не имею.

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

"Повышение экономической эффективности ПО" - эксплуатации или производства? Или того и другого? Что вы понимаете под эффективностью? Денежные затраты на производство? Трудозатраты? Можно сделать никому не нужное ПО которое будет очень качественным, но его польза будет равна нулю. Можно напичкать программу никому не нужными функциями и сделать их очень качественно. А можно сделать уникальный продукт, который будет пользоваться огромным спросом, не особо заморачиваясь о его качестве, и потом допиливать его по ходу распространения. Как тут будут обстоять дела с эффективностью? Сколько ПО выпускается в виде альфы или беты на рынок? Как у них дела с эффективностью? Вроде они на тестирование тратят меньше. Как это все посчитать?

Да есть исследования (например The Economics of Unit Testing / M.Ellims J.Bridges & D.Ince), на scholar.google.com можно найти еще больше, там приводят кумулятивные данные нескольких фирм, сравнивают количество строк кода, количество дефектов найденное этими тестами. Но на вопрос об экономическом влиянии тестирования они не отвечают. В статье вообще денежными суммами не оперируют.

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

Единственный подход к этой теме, если хотите связать это как-то с деньгами - это смотреть на издержки в связи с дефектами. А о таких жирных дефектах которые попали в газеты - масса статей. Только и тут по большому счету тупик - доказать безошибочность нетривиальной программы невозможно. Это следствие теоремы Райса. Т.е затраты на тестирование могут стремиться в бесконечность, но не найти ошибку которая погубит весь проект. Ну и как тут считать эффективность? Риски, вероятности, предположения, оценки, домыслы.

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

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

Вообще, чтобы расширить свой горизонт, и начать более широко смотреть на свои возможности, рекомендую на ютубе записи Джеймсa Бах (James Bach). Все без исключения. Ну вот например ("A Context-Driven Approach to Automation in Testing"), для затравки видео с демками. Или вот ("Open Lecture by James Bach on Software Testing") - обзорная лекция, о том что такое тестирование. Я после нее заинтересовался тестированием и стал тестировщиком и вот уже 5 лет как тестировщик.

Oн поддерживает и десктоп. Mышь и клавиатура поддерживаются. Обработка событий более общая. Например для кнопки мыши определяется только вжата ли она, значит определять щелчек придется самому как комбинацию этих событий. https://forums.coronalabs.com/topic/58255-mouse-an...

В задании звездочек по горизонтали 11, а у Вас 10
Нечетное число должно быть, чтобы в середине точно крест сошелся.

Я видел одну систему "нового типа", это HipTest, там шаги можно переиспользовать. В классических системах, ты просто пишешь/копипастишь текст. Такие системы не нужны, тогда можно и в ворде все хранить.
Когда описания формализованы и имеют семантику, открываются новые возможности чтобы действительно управлять тестами, а не просто их складывать. Тогда ты можешь например ответить на вопрос, сколько тестов у нас проходят через этот экран. Сколько тестов у нас нажимают на эту кнопку. Я считаю, что смысл такой системы в этом. Давать новые возможности работы с данными. А не просто сделать хранилище текста, с аккаунтами, чтобы можно было распределять тексты и собирать галочки проставленные пользователями (тестировщиками). Или еще какие-то там красивые репорты из этого кроить. Т.е. понятно, что это тоже нужно, но не это главное в системе управления тестами. Не это отличает систему управления тестированием, от системы управления <чем-то другим>. Я считаю, что цифровые системы должны не просто быть компьютерной заменой бумаге, а расширять возможности человека. Позволять ему делать то, что ему раньше было не доступно. Тогда это оправдано. Например электронная книга дает возможность полного поиска по тексту, в то время как книги, в лучшем случае, ограничены предметным указателем.

- На каких технологиях приложение?
- Какая длина спринта?
- Как у вас построен процесс написания кода и интеграции?
- Сколько разработчиков?
- Какие роли кроме разработчиков и тестировщиков еще есть на проекте?

Как у вас дела с архитектурой, если не получается добавлять функции не задев при этом значительную часть всей системы?

По идее код перед мерджем должен проверяться на тестировочной сборке. Возможно вам нужен девопсер, если у вас его нет.

Во время проверки (тестирования) можно написать на этот сценарий приемочный тест. Так у вас потихоньку появятся автоматизированные тесты.

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

Разработчики тоже должны тестировать. Тот кто пишет фичу Х проверят фичу Y и наоборот. Нельзя давать проверять свою собственную работу. Нужна культура качества и открытой коммуникации - чтобы разработчики не замалчивали замеченые проблемы, а открыто писали на них тикет.

Переходить в следующий спринт с багами из предыдущего - вообще не айс. Можно сделать один спринт - добавление функционала, второй спринт стабилизация.