Ссылка на презентацию Олега: https://oneumyvakin.github.io/talks-built-in-quality/

к теме вчерашнего митапа - интересный доклад с GTAC 2011 с провокационным названием Test is Dead (En)
https://www.youtube.com/watch?v=X1jWe5rOu3g

вариаций много и надо смотреть, что ближе к специфике конкретного проекта
попиарю Сашин фейсбучек, в котором он пиарит доклад от баду:
https://www.facebook.com/story.php?story_fbid=10217481657491469&id=1176944423

а здесь можно почитать про то, о чем рассказывал Олег:
https://www.scaledagileframework.com/built-in-quality/

вот я примерно тем же грежу

коллеги, такой вопрос в тему смещения влево
погрузился в тему, почитал разные статьи/доклады (даже на хабре есть парочка)
если я правильно понял, сама тема не нова и она про то, чтобы начать тестировать раньше для того, чтобы получать фидбек раньше (помогать не создавать баги, вместо того чтобы указывать на уже написанные баги), вовлечение разработчиков и как следствие разгрузка тестирования - это больше сайд эффект самой методики
плюс есть еще например сдвиг вправо http://blog.qatestlab.com/2017/07/04/shift-right-testing/
оба сдвига по сути - методики, которые можно сочетать и использовать для повышения качества продукта
то есть в идеале тестировщик составляет некие ноутсы еще до начала разработки, проанализировав будущий продукт (по тз, через коммуникации, пропустив через свой опыт), и этими ноутсами (и своим знанием системы) руководствуется разработчик
от докладов же складывается ощущение, что сдвиг влево сейчас используется в принципе для того, чтобы за счет разработчиков высвободить себе время:
1) на разрыв порочного круга "много ручного - мало автотестов"
2) на исследовательское тестирование, а манки тестинг отдать разработчикам
3) плюс чтоб снизить зависимость разработки от тестирования (аналог бас фактора, "двум тестировщикам уйти в отпуск - непозволительная роскошь")
разработчик сам пишет чеклист, тестировщик делает ревью (или даже не делает)
то есть получается какое-то решение проблем тестирования за счет разработки? ну и за счет этого наращиваем скорость не теряя качества. Как-то меняется сама суть методики
на встречу к сожалению не попал, так что задним числом размышления на тему
буду рад услышать разные мнения

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

разработчики могут тестировать свой код, но это сдвиг влево, а шаг назад

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

При тестировании справа он мало (условно) тратит времени на разработку, зато потом тратит его на доделывании/переделывании того где набажил.

При тестировании слева он больше тратит времени на разработку, зато делает то что надо с первого раза (в идеале)

Где в итоге пользователь быстрее получает качественный результат однозначно сказать сложно. Но факт, что эту метрику необходимо улучшать. В том числе за счёт сдвига влево это можно делать. Кому это интересно, те двигают :)

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

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

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

Классически это решалось (помощь тестировщика) жестким разделением не только ролей, но и функций. Мы же у себя, оставив разделение ролей (с подготовкой тестов помогает тестировщик), функцию тестирования результата отдаём разработчику по большей части. И это эффективно делать именно разработчику, т.к. цикл "баг найден-баг исправлен" (feedback loop) стремится к нулю. К тому же разработчик лучше это заавтоматизирует.

Насчёт "манки-тестинг" - нехороший термин и неправильный здесь, потому что он несёт негативный окрас. У нас разработчик не делает манки-тестинг, а проверяет свою работу. В том числе автоматическими тестами, передавая роль обезьянки роботам :)

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

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

Почему кто-то решил, что это чето новое...

В плане идей ничего нового нет. А в плане реализации этих идей нового очень много :)

А можно привести это старое доброе опредение?)

Что-то там про активности, направленные на обеспечение качества продукта

Ну такое. Под это расплывчатое определение можно подвести все существующие методики тестирования/обеспечения качества
Да под это определение можно подвести ещё даже не придуманные методики😂 И говорить - да чё, это давно придумали

Концепция одна