На сколько я помню, там два-три вопроса в стиле, каким iso регулируется что-то, имхо нет необходимости что-то дополнительно по ним изучать специально для istqb

Мне скучно)
Решил ддя себя, что систематизация знаний мне не повредит. Ведь я уже давно работаю

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

тоже работаю, надо расти там после фондейшн интересные отрасли, все отговаривают просто и я засомневалась

Тут будет много "советчиков" , что мол бесполезно) но я в этом вижу все равно пользу, и не охотно слушать. Явно лишним не будет, если есть время на это

1) Сайт, он скорее всего для чего-то. Т.е. предполагается что человек приходящий на сайт может что-то сделать — почитать какие-то материалы, купить товар, поиграть в игры. Из этого можно выстроить какие-то минимальные идеи насчёт того что пользователь может сделать на сайте, и собрать из них то что называют happy path или hero flow — основной путь пользователя который должен работать.  Из этого пути можно записать какие-то минимальные проверки.

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

2) Когда основные задачи выделены, можно рядом выделить второстепенные, которые рядом или варианты основных.

3) https://dou.ua/lenta/articles/scheme-for-qa/ — вот тут есть неплохой список с кучей идей.

Слушал недавно внутреннюю презентацию рассказывающих про айистикьюби. Говорили что опытным вообще не нужен.  Также в тырнете встречалось куча мнений вида "зазубрил, сдал, забыл" или "сдайте и забудьте".

Как альтернативы по систематизации можно взять материалы канеровского BBST ( http://www.testingeducation.org/BBST/ ) , или Канера и Баха "Lessons learned in software testing" (  https://www.oreilly.com/library/view/lessons-learned-in/9780471081128/ ) , которой есть даже любительский перевод на русский для тех кто в английском не силён ( https://w-bf.livejournal.com/tag/lessons%20learned%20in%20software%20testing )

🙏 спасибо)

🙏

Вспомнил один старый собес, вопрос был. Есть 2 проекта (веб), старый и новый, старый не будет обновляться, новый пишут ему на замену. Для какого из них нужно писать автотесты?
Собеседующие считали, что для старого. Аргумент был прост - он не обновляется, поэтому тесты не придется постоянно переделывать.
Мой ответ - для нового. Аргументы от обратного, т.е. для старого тесты даже при идеальной реализации не понадобятся (точнее не принесут никакой пользы). Ведь обновлений кода нет, поэтому регрессий тоже нет, а косяки инфрастуктуры отслеживаются более специфичными инструментами.
Более того, в условиях не было деталей разработки. Это значит что при TDD ответ очевиден. А при переносе старого бэкенда можно сделать стабильные апи тесты.
Ну и наконец компромиссный вариант для наихудшего сценария, когда фронт постоянно меняют - можно заранее подготовить фикстуры, продумать общую логику, расставить testid.

Ваше мнение?

Одно из основных преимуществ автоматизации - это автоматизация регресс тестов, зачем же инженеру платить за написание автотестов для необновляемого продукта. В данном случае вся суть автоматизации теряет смысл.
Деньги он будет получать те же и тратить времени не меньше, чем на написание тестов для старого продукта, поэтому написание автотестов для старого продукта мне кажется совсем абсурдным))

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

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

Оба подхода имею право на жизнь

собеседующие просто немного ушли в крайность по подходу "стабильное покрывать разумнее" , ну и тут контекста не хватает. Обновление не предусмотрено НЕ РАВНО отсутствие необходимости регресса минимального) какие бы крутышки не были разработчики. задеть что угодно где угодно - это их навык по умолчанию)) Поэтому не стоит зарекаться.

А вообще ответ всегда один - ROI посчитали и выбрали. все. это работает всегда. ROI объективно

У меня пока только один вопрос:
Причём тут вообще TDD?

У меня был только один проект классического переделывания, когда заказчик пришел со старым сайтом и захотел сделать новый с переносом базы. Я не вижу ни одной причины писать новые тесты (!) для старого неподдерживаемого проекта. Можете привести примеры, когда в этом есть хоть какой-то смысл?

Если в старом функционале есть крутой бизнес-функционал, проверка которого занимает много времени, а проверять надо всегда. Какой-нибудь биллинг, например.

И не важно, что его уже не пилят даже.

Что-то у вас кейсы меняются от сообщения к сообщению) если заказчик пришел и сказал пилите мне новую систему целиком а данные потом смигрируем - то команда берет и пилит новый. И тут второго "старого" просто нет.
если заказчик пришел и сказал пилите мне новую веб морду. а слой с данными и бэк возьмите старые и доработайте + надо поддерживать пока старое ибо оно деньги мне приносит. То тут встает вопрос поддержки совместимости доработанного бэка с старой мордой. И длительности сего мероприятия. Вот вам и смысл тестов на старую часть.