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