Comments 6
Когда говорят, что тестировщики что-то там должны уметь «ломать» — я перестаю дальше слушать. Тестирование вообще не про это. Тестирование скорее сродни работе детектива, и никакой деструкцией не занимается. Все сломано уже до нас, мы просто выявляем эти «поломки». Мы мы ищем способы сделать неочевидное — очевидным.
А про классы эквивалентности и pairwise, ну не знаю стоит ли об этом снова писать — везде уже написано-переписано. И что я вам скажу — за пять лет я воспользовался этим знанием 1 раз.
Куда полезнее знать архитектуру приложения, чтобы понимать на что у него может быть «аллергия». И сразу пробовать уязвимое место.
Тестировщик не обезьяна, которая должна составлять таблицы эквивалентности и тупо следовать им — это может сделать и автомат. Тестировщик должен пользоваться головой. Все строго формальные, систематические подходы — это не для ручного тестировщика. Он слишком ценен.
Когда уже люди поймут, что ручной тестировщик это не тогда, когда нет автоматизации. А тогда, когда, нам нужна находчивость и острый ум. Поэтому эту задачу мы отдаем в ручное тестирование. Человек слишком ценный инструмент, чтобы заколачивать им гвозди. Гонять тесты в ручную по матрице эквивалентности — это вот прям про это. Забивать гвозди микроскопом.
Это конечно не значит, что тестировщику не нужно этого знать — нужно даже очень. Просто из таких учебников и пособий для тестировщиков, складывается представление о его навыках и возможностях, а они гораздо шире. И приходит это с опытом. Только вот многие так и продолжают тестировать по матрице, год, другой… Им даже деньги платят, и они думают, что делают что-то полезное. А они просто прожигают свой ресурс. Топят печку нефтью.
Найти ошибку в программе — не сложная задача. Их кругом как грязи. Даже на сайтах производителей интрументов для тестирования. (Да, я горько ухмылялся, когда натыкался на такие). Гораздо важнее для практики умение и желание довести найденную ошибку до ее починки. И это тоже навык тестировщика. Только этому почему-то ни в каких учебниках не учат. Ты завел багрепорт, теперь это твой ребенок, и ты с ним будешь бегать и не давать его в обиду. Любить свое приложение как самого себя тоже нигде не учат.
Все эти формальные методики, если ставить их на первое место — быстро превратят вас в одноклеточных.
А про классы эквивалентности и pairwise, ну не знаю стоит ли об этом снова писать — везде уже написано-переписано. И что я вам скажу — за пять лет я воспользовался этим знанием 1 раз.
Куда полезнее знать архитектуру приложения, чтобы понимать на что у него может быть «аллергия». И сразу пробовать уязвимое место.
Тестировщик не обезьяна, которая должна составлять таблицы эквивалентности и тупо следовать им — это может сделать и автомат. Тестировщик должен пользоваться головой. Все строго формальные, систематические подходы — это не для ручного тестировщика. Он слишком ценен.
Когда уже люди поймут, что ручной тестировщик это не тогда, когда нет автоматизации. А тогда, когда, нам нужна находчивость и острый ум. Поэтому эту задачу мы отдаем в ручное тестирование. Человек слишком ценный инструмент, чтобы заколачивать им гвозди. Гонять тесты в ручную по матрице эквивалентности — это вот прям про это. Забивать гвозди микроскопом.
Это конечно не значит, что тестировщику не нужно этого знать — нужно даже очень. Просто из таких учебников и пособий для тестировщиков, складывается представление о его навыках и возможностях, а они гораздо шире. И приходит это с опытом. Только вот многие так и продолжают тестировать по матрице, год, другой… Им даже деньги платят, и они думают, что делают что-то полезное. А они просто прожигают свой ресурс. Топят печку нефтью.
Найти ошибку в программе — не сложная задача. Их кругом как грязи. Даже на сайтах производителей интрументов для тестирования. (Да, я горько ухмылялся, когда натыкался на такие). Гораздо важнее для практики умение и желание довести найденную ошибку до ее починки. И это тоже навык тестировщика. Только этому почему-то ни в каких учебниках не учат. Ты завел багрепорт, теперь это твой ребенок, и ты с ним будешь бегать и не давать его в обиду. Любить свое приложение как самого себя тоже нигде не учат.
Все эти формальные методики, если ставить их на первое место — быстро превратят вас в одноклеточных.
Спасибо за комментарий! Я отчасти в Вами согласен, но тем не менее все зависит от задачи и от роли тестировщика в проекте.
Чтобы хотел дополнить:
1. Тест-дизайн — это больше правила, чем стандарт. Никто не обязывает ими пользоваться, и более, как я писал в статье, их применяют в зависимости от ситуации. Описанные здесь техники — лишь часть. Они характерны больше для полностью нового ПО, которее пишется с нуля. Для ПО, которое в эксплуатации, более подходят техники принятия решений, переходов состояний и другие техники, ориентированные на бизнес процесс. В следующей статье я постараюсь их рассмотреть.
2. Искать уязвимое место — это больше относиться к тестированию, основанному на рисках. Для тестирования на основе рисков совсем другой подход. Но если честно, я все чаще и чаще сталкиваюсь именно с ним.
3.
4.
Чтобы хотел дополнить:
1. Тест-дизайн — это больше правила, чем стандарт. Никто не обязывает ими пользоваться, и более, как я писал в статье, их применяют в зависимости от ситуации. Описанные здесь техники — лишь часть. Они характерны больше для полностью нового ПО, которее пишется с нуля. Для ПО, которое в эксплуатации, более подходят техники принятия решений, переходов состояний и другие техники, ориентированные на бизнес процесс. В следующей статье я постараюсь их рассмотреть.
2. Искать уязвимое место — это больше относиться к тестированию, основанному на рисках. Для тестирования на основе рисков совсем другой подход. Но если честно, я все чаще и чаще сталкиваюсь именно с ним.
3.
Найти ошибку в программе — не сложная задача.Все зависит от задачи. Если мы тестируем веб-приложение какого-нибудь агрегатора, то возможно да, но если мы тестируем формирование банковских резервов или автопилот для самолета, то найти дефект не такая уж и легкая задача становится.
4.
Все эти формальные методики, если ставить их на первое место — быстро превратят вас в одноклеточных.Как я писал в статье, мы так или иначе на интуитивном уровне применяем их. И я согласен с Вами, что рисовать матрицы и таблицы — не айс. Поэтому тестровщик должен уметь формировать проверки в голове. А техники позволяют ему думать в правильном направлении.
если мы тестируем [...] автопилот для самолетатут конечно. Однако целевая аудитория обычно ребята которые тестируют веб. Понятно, для некоторых приложений нужно уметь формальный систематический подход. Но это меньше 1 процента всех приложений с которыми придется столкнуться. А то что ручному тестировщику дадут тестировать автопилот самолета… ну разве что он его тестирует когда летает в отпуск пассажиром, сам того не зная.
Обычно это потребительские приложения, в которых не нужно глубоко копать, чтобы натнуться на какую нибудь фигню.
Поэтому тестровщик должен уметь формировать проверки в голове. А техники позволяют ему думать в правильном направленииНу да, "… ум в порядок приводит", пожалуй.
Интересная статья, жду продолжения)
parwise testing
Как можно в обучающем материале неправильно написать идентификатор?
Ладно опечатки в словах, но тут это выглядит печально.
Sign up to leave a comment.
Немного о простом. Тест-дизайн. Часть 1