Выпуск 10: Стратегия тестирования

Ну вот и снова мы собрались и решили стратегию всея тестирования раз и навсегда! Или нет? Не послушаешь выпуск — не узнаешь!
В выпуске принимали участие:

Сергей Мартыненко, который собирает и классифицирует материалы по стратегиям с 2001 года. Ведёт блог.

Алексей Фёдоров, инженер по тестированию в компании «Технологии  радиоконтроля», «Сердце» Санкт-Петербургского сообщества  тестировщиков.

А также постоянный участник команды Radio-QA, звуковик подкаста — Сергей Атрощенков

Содержание и ссылки на упоминаемые материалы:

Введение

Сессии по стратегии регрессионного тестирования на Weekend Testing Russia

Доклад Сергея Мартыненко на SQA Days’15 «Стратегии тестирования. 42 способа сделать ваш проект успешнее»

Доклад Романа Шейко на SQA Days’17 «Принятие решений в тестировании на примере тестовой стратегии»

Основная часть

Слайды

Смежные доклады

https://ru.wikipedia.org/wiki/Соглашение_об_уровне_услуг

https://ru.wikipedia.org/wiki/Контрольная_карта_Шухарта

https://ru.wikipedia.org/wiki/Операция_Chastise

Пример плана тестирования

https://ru.wikipedia.org/wiki/Фасетная_классификация

Mind Map стратегии Сергея Атрощенкова с одного из Weekend Testing Russia

Вопросы и ответы

О’Бредли “Записки солдата”

Карл Дёниц “Немецкие подводные лодки во Второй мировой войне”

Генри Нив: Организация как система. Принципы построения устойчивого бизнеса Эдвардса Деминг

Элиезер Юдковский «Гарри Поттер и методы рационального мышления»

Agile Manifest

Форд, Тойота и морские свинки

Новости

Тренинги на SQA Days 

Кейноуты на SQA Days 

Индия: Национальная политика шифрования 

Последний писк

Тренинги инженер для инженеров 

 

  • Irina Ivanova

    Самый лучший выпуск — тема действительно мало освещенная. И я внезапно тоже осознала внегласную стратегию в нашем проекте)

  • Andrei Solntsev

    а где код-загадка для разработчиков, который засрал мозг Дорофееву?

  • А я вот не согласен с тем, что цель тестирования — это поиск багов. Мне очень не нравится это определение — потому что, сам термин «баг» — можно и нужно понимать по-разному (в контексте). Данное определение — прямое приглашение к тому, чтобы все понимали цель тестирования по-разному и путали друг-друга!

    Если кто забыл — моё определение краткое определение цели тестирования — выполнение информационного сервиса о состоянии продукта для заинтересованных сторон.

    • а состояние продукта чем определяется?

      • это не то состояние, которое в конечных автоматах 🙂 это состояние в смысле «ну как дела»

        • )) это понятно. «Ну как дела» — как определить?

          • понятно как — ввести метрику как-делов!!! Шучу.

            Если вопрос серьёзный — определить описательно.

          • Серьезный. Я просто не могу себе придумать, как определить состояние продукта, не проверив как работает требуемая функциональность, что в свою очередь опять сводится (или приведет) к обнаружению багов. Во всяком случае «баг» как результат этого исследования чаще всего неизбежен.
            Или это излишне упрощенный взгляд на мир? 🙂 Может отдельный подкастик на эту тему?

          • Sergey Martynenko

            Тут не один подкастик нужен. За примерно 20 лет появилось множество определений и тестировщики до сих пор не пришли к единому мнению. Чем сложнее задача, тем интереснее.

            http://software-testing.ru/forum/index.php?/topic/31858-chto-iavliaetsia-osnovnym-produktom-testirovaniia/

          • Почему не проверив? И проверив, и баги обнаружив (или не обнаружив). Дело в том — что на проверке и поиске багов дело далеко не заканчивается и не ограничивается. И в ходе «определения состояния» появится много информации, которые не будут «баг» даже по самому вольному определению «бага» и тем не менее будут важны.

            И мне больно слышать от людей, считающих себя тестировщиками, фразы типа: это же не моё дело — не стоит в тест-дизайне/спецификация говорит, что это не баг/может быть клиент так захотел.
            А чьё же это еще дело?

          • maksya

            С помощью эмпирических и теоретических методов познания. Это если сухо и кратко =) Если жизненней и шире, то соглашусь — еще подкаст.

    • maksya

      Поддержу. «Поиск багов» — это удобное, но никак не полное определение той фигни, которой мы занимаемся =) Суть тестирования ПО — получение знаний о продукте. Баги — есть лишь преломление этих знаний через призму требований/ожиданий.
      На мой скромный взгляд, одна из ключевых проблем сферы тестирования ПО заключается в ее близорукости. При прочтении материалов по теме складывается стойкое ощущение инновационности, уникальности, неповторимости. А между тем люди занимались тестированием задолго до появления ПО, и продолжают заниматься по сей день. Мы умиляемся каждый раз когда нашу профессию путают, например, с психологическим тестирование, хотя если задуматься, то никакой путанницы нет.

  • offtop: только мне кажется, что общую громкость записи надо увеличивать? Слушаю в машине много подкастов, на вашем — громкость на максимуме и иногда хочется еще прибавить 🙂

  • Alex

    Ужасная музыка за кадром, уберите ее, пожалуйста.

    • Sergey Atroschenkov

      Спасибо за обратную связь.
      Нет, не уберем.