А вас не смущает что навскидку в 90% компаний на позиции девелопера именно активно девелопить код это отсилы 15% от всей работы ?
Оставшиеся 10% компаний — это продуктовые компании (причем на ранних этапах разивития), где вот именно что нужно во всю решать нерешенные задачи и вот это все.
И что иронично — типичные задачи с интервью никак обычно не показывают умееет ли кандидат решать нерешенные задачи. И весьма слабо показывают умеет ли кандидат «решать» уже решенные задачи (найти похожее и подпилить напильником)

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

И никто даже не заикнулся что Software Testing это вообще-то самая натуральная engineering задача.
Ни больше и не меньше. ( Так же как и дев)
И что если браться делать engineering задачу не умея решать такие задачи — то результат будет соответствующий.
Ну сами знаете какой результат — бесконечные критические баги из продакшена и вот это вот все.

Ок, если я пойду делать Exhaustive testing для Amazon, то вам предлагаю сходить кое-что проверить.
Например что для всех прямоульных треугольников сумма квадратов катетов равна квадрату гипотенузы.

Прошу заметить, что у Amazon кейсов намного меньше чем существует прямоугольных треугольников (их бесконечное количество если что). И для треугольников такую проверку уже сделали. Причем давно.

Если, чтобы провернуть Exhaustive testing нужен либо полный перебор либо его еквивалент. Вот этот еквивалент нам и должен быть интересен. И как его сделать знают те же математики, у которых вообще теоремы про бесконечно большие множества, и ничего, сделали.

Бо у матиматиков с их теориями то всё возможно, а здесь на это денег никто не даст )

Можно подумать что вы это умеете чтоб вам на это денег давать. А то вот математикам которые умеют — очень даже дают денег, взять хотя бы machine learning.

Кстати, если аргумент был про деньги — тогда стоит писать что-то про «exhaustive testing is expensive». А то сразу невозможно...

Опа, приехали. Значит,

Exhaustive testing is impossible

А ещё фундаментальная теория называется...
Это же надо, не можете сделать полный перебор.
А точнее не хотите.
Hint: у математиков с их бесконечнымм множествами как-то получается, а тут сразу невозможно

Автор так ловко жонглирует стоимостью нахождения и починки багов как-будто знает что это такое и как это чинить (сколько это стоит).
Спойлер: нет, не знает

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

Ах да, ещё один не менее важный момент.
Просто выйти за рамки обычных сценариев вот вообще не достаточно для того выяснить ни как продукт будет вести себя у пользователя, ни какие там у пользователя потребности и хотелки.
Обе задачи довольно сложные, потому что сюрприз — они про будущее. Чуть ли не буквально в будущее смотреть.
Ну т.е. просто гаданием на кофейной гуще — ’а вот это пользователю надо’, или ’ у пользователя наша софтинка будет наверное будет вот так работать’
Не отделаетесь.
Там действительно нужно делать самое натуральное исследование , с гипотезами , доказательствами и експериментами.
Коими в софтверных проектах и не пахнет.

Что мы доказываем? Что следование принцыпам гарантирует качество?

Нет, доказываем что некое утверждение верно или не верно.
Те базовые принципы, если внимательно посмотреть это не приципы, а набор утверждений.
И вопрос был, есть ли доказательство этих утверждений ?
(хотя бы логическое обоснование)

На всякий случай добавляю 7 базовых принципов тестирования для ознакомления

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

Эти 7 принцыпов (не стейтментов)

Это все-таки не принципы, а утверждения (стейтменты). Потому как приципам следуют, а утверждения (простите за тафтологию) утверждают
И это не одно и то же

А конкретного вопроса я так и не услышала :)

Напишу еще раз. Есть ли у этих стейтментов логическое обоснование, оно же доказательство ? Если есть, то где его можно почитать ?

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

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

На всякий случай добавляю 7 базовых принципов тестирования для ознакомления:

Если не сложно, просветите откуда эти 10...простите 7 заповедей взялись?

Вот оно как.
Предлагаете чтобы все девы делали работу за троих ( и свою и QA и analyst), а зарплату получать за одного.
А остальные двое соответственно — работу за 0 человек , а зарплату за одного.
Чего уж, интересная концепция ...

Можно. Например нужно перевести на автотесты все имеющиеся мануальные тесты.
Стратегия начинается с правильной постановки задачи — автоматизировать существующие тесты, так чтобы не поломались существующие основные QA цыклы (периодические регрессии, CI/CD планы, релизные цыклы и т.п.).
Пример достижения цели
1. Проанализировать имеющиеся кейсы.
Наметить как именно можно их все автоматизировать (какие фреймворки, почему именно эти фреймворки, насколько тот или иной подход затратный, как это потом интегрировать в существующий CI и т.д.)
2. Набросать примерный план действий, включая случаи когда все идёт сильно не так.
Когда, как и сколько новых автотестов включать в основной QA.
3. Взять несколько пробных тестов, и проделать всю автоматизацию до конца. Такой себе Proof of Concept. Посмотреть на все проблемы которые по ходу дела возникнут.
Если надо, то проделать все сначала, допока весь подход к автоматизации не окажется приемлемым.
4. Проскейлить пункт 3 на оставшиеся кейсы.

Note: сложна часть это пункт 1. Сформулировать и обосновать подход к автоматизации. Многие проблемы можно избежать только так (а-ля выбрали фреймворк который к примеру не скейлиться, или не налазит на CI)

Речь идёт именно про стратегию тестирования. Какие тесты делать, зачем их делать.
Сюда же входит какие тесты авто, в каком порядке, куда эти авто тесты приткнуть, какие части софта и как покрывать, и т.д. и т.п.
Можно даже сделать отдельную ’стратегию автоматизации’.
Такие задачи обычно делает как раз лид.
И да, это я так не прозрачно намекаю/советую делать стратегию перед тем браться за такие большие таски, как автоматизация.
Ну а так лайк за попытку.

А где стратегия тестирования (то бишь всего QA процесса) ? Опять нету?
Или вся стратегия это ’ будем писать такие тесты которые умеем, и черт его знает что из этого выйдет’ ?
Note: автоматизация автоматизацией, а без стратегии довольно быстро приходит хаос.

Феодализм. В Украине действует феодализм. Ну а из него проистекают плюс минус все проблемы описанные в соседних ветках.
Ну а за что обычно не любят феодализм надеюсь не надо объяснять. Это если не любят конечно, а то некоторым , судя по всему, норм.

Читаешь такие статьи, и складывается устойчивое впечатление что QA в большинстве своем вообще не занимаются качеством софта. Не понимают что такое формальная логика, не понимают как работает софт, и что такое это самое его качество.
Я уже молчу про более сложные понятия (покрытие, статистический фейл рейт и т.п.)
Disclaimer: когнитивные искажения , bias и т.п. конечно есть, но они влияют на работу куда меньше чем Отсутствие понятия о формальной логике.
Печалька....