Автор: Александр Федоров
Каждый тестировщик пишет тесты по определенному принципу. Даже тот, кто слыхом не слыхал ни о каких методиках, так или иначе руководствуется рядом принципов, которые, как правило, держит в голове, или в редких случаях на бумаге. Но скажите, какой бывалый тестировщик не представлял себе фантастическую ситуацию, когда эти принципы реализованы в коде: софт создает тест-кейсы. Конечно до такой радужной перспективы еще очень далеко, но первые шаги на этом поприще уже сделаны…
Автор: Наталья Руколь
Страшный сон любого ответственного тестировщика – пропуск ошибки. Вы стараетесь-стараетесь, проверяете продукт, тестируете его по 8+ часов ежедневно, а после выпуска пользователь в течение недели сообщает о критичной проблеме. Как такое может быть, почему и как исправить?
Автор: Алексей Федорко
Оригинальная публикация
Если в качестве инструмента у вас имеется лишь молоток, каждая проблема начинает напоминать гвоздь. Абрахам Маслоу
В этой небольшой заметке я бы хотел рассмотреть инструмент для попарного тестирования от Microsoft – PICT (Pairwise Independent Combinatorial Testing). Уже несколько раз я применял его в своей работе и был доволен теми гибкими опциями, которые он имеет.
Автор: Наталья Руколь
Последнее время тестирование по заранее написанным тестам (назовём такое тестирование скриптовым) выходит из моды. У противников скриптового тестирования много аргументов, хотя в большую часть из них я, увы, не верю. В этой статье я хочу рассказать о своём взгляде на скриптовое тестирование и его существенных плюсах. Вполне вероятно, что эти плюсы окажутся вам незакомыми. Не потому, что подход неправильный! Возможно, вы просто сталкивались с его неудачной реализацией? Для этого вторая часть статьи: о том, как внедрять скриптовое тестирование наиболее эффективно.
Словарь
В рамках этой статьи я буду называть скриптовым тестирование, перед началом которого создаются тесты, и уже по ним осуществляются проверки. В качестве альтернативы скриптовому подходу можно рассматривать ad hoc, хаотическое и исследовательское тестирования, но о них в отдельной статье — оде тестированию исследовательскому. Пока что мы просто поделим тестирование на скриптовое (основанное на заранее написанных тестах) и без-скриптовое, то есть любое другое 
Подведены итоги очередной онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Как обычно публикуем лучший по результатам голосования доклад.
Это доклад Натальи Руколь "Тест-анализ на основе состояний и переходов".
Многие тесты, которые мы выполняем, нам интуитивно понятны: попробовать ввести стандартные и не очень значения, вызвать одну и ту же функцию из разных меню, проверить комбинации параметров и их значений. Но помимо них есть и значительно менее очевидные тесты, которые могут находить серьёзные ошибки: тесты на определённые последовательности действий.
- Как эти тесты продумать?
- Как обеспечить высокое покрытие не избыточным количеством тестов?
- Какие инструменты есть для тестирования состояний и переходов и как их использовать?
Доклад будет полезен тестировщикам и тест-дизайнерам, и после него (я надеюсь) вы сможете пропускать значительно меньше критичных дефектов.
Доклад Алексея Баранцева
Анализ границ - эту технику каждый тестировщик осваивает, наверное, самой первой.
Но в действительности применение этой техники вовсе не так просто, как может показаться на первый взгляд, потому что в реальном мире разных "границ" куда больше, чем описано в любой, даже самой хорошей спецификации. Причина этого в том, что в реальной программе существует множество технологических границ, о которых аналитик может даже не подозревать.
Что будет, если пользователь, случайно или намеренно, пересечёт такую технологическую границу - введёт слишком большое число или слишком длинную строку? Должен ли тестировщик пытаться это выяснить? Или может быть достаточно предупредить пользователей, чтобы они не вводили "плохие" данные, а кто ввёл - мы ответственности не несём? А если всё таки мы решили, что тестировщику следует пытаться всё это проверить -как искать эти границы, если они нигде не описаны?
Я расскажу свою точку зрения на применение этой техники, приведу примеры реальных багов, связанных с нарушением технологических границ, подскажу некоторые приемы, которые позволяют их обнаруживать, и дам рекомендации, когда этого можно не делать.
Это вторая, более полная версия доклада о границах, с более интересными и живыми примерами. Ведь на границах багов намного больше, чем мы можем себе представить.
{iframe src="//player.vimeo.com/video/42284184" width="500" height="234" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen}{/iframe}
Переходя все границы... (Алексей Баранцев, SQADays-11) from Stas Fomin on Vimeo.
Хотите узнать больше про различные техники тест-дизайна? Приходите на онлайн-тренинг Практикум по тест-дизайну или очный тренинг в Москве Тест-дизайн от А до Я
Выступление Алексея Баранцева на онлайн-конференции для тестировщиков Fun ConfeT&QA.
Техника покрытия попарных комбинаций (pairwise testing) – пожалуй, одна из самых «магических». Сотня параметров? Миллионы миллиарды триллионы дециллионы комбинаций? Нет проблем! Берём Магический Инструмент, закладываем в него данные об этих параметрах, нажимаем Магическую Кнопку. Месиво цифр – и на выходе всего десяток комбинаций, которые нужно проверить.
Я встречал две крайности в применении этой техники.
Одна крайность – использование везде, с потрясающе простым обоснованием применимости – «ну, тестов же мало получается, это классно!» Другая крайность – полный отказ от использования этой техники, с не менее замечательным объяснением – «непонятно, как это работает, а тестов получается подозрительно мало, не верю!»
Да, непонятно как это работает внутри. И я не призываю изучать алгоритмы генерации магических комбинаций. Многие прекрасно водят автомобиль, не понимая его внутреннего устройства, принципа работы, использованных инженерных решений. Зато все должны знать, как рулить и как тормозить.
Я расскажу, не прибегая к теории, какие существуют кнопки и рычаги управления техникой покрытия попарных комбинаций:
- когда она эффективна, а когда не очень,
- какие зависимости между параметрами мешают применять эту технику, а какие не мешают,
- как «дробить» и «склеивать» переменные, чтобы заставить технику работать эффективнее,
- меняется ли результат от «перестановки мест слагаемых»,
- какие баги пропускает эта техника и почему.
Ах да, конечно, обязательно покажу Магические Инструменты, как же без этого :)
Доклад Алексея Лупана на онлайн-конференции для специалистов по тестированию Fun ConfeT&QA, весна 2012.
Обычный тестировщик начинает карьеру с тест-кейсов, и ими же завершает свой прекрасный жизненный цикл.
Крик из толпы: «Камон! Долой тест-кейсню!»
Мы вооружаемся плюсами тестирования без тест-кейсов, мы минимизируем минусы этого прекрасного подхода, мы захватываем почту-телеграф-телефон-твиттер!
С площади гудит: «Дааааааайошь старые порядки взад!»
Нам с трибуны докладывает Мурка в кожаной тужурке: «Товарищи! Доколе мы терпим засилье тест-кейсов?! Нам нужен Fun! Fun, товарищи! Fun!»
Давайте начнем прямо сейчас, давайте «Отречемся от старого мииииииира»…
Тест-анализ -- фундаментальная составляющая тестирования. На Amazon'е этой теме посвящено множество книг, но ни одна из них пока что не переводилась на русский язык.
Что же такое тест-анализ? Какие задачи решает тест-аналитик? Какие виды анализа и исследования тестируемого ПО существуют?
Для ответов на эти вопросы мы публикуем 1-й вебинар Натальи Руколь по курсу "Школа Тест-Аналитика". Из него вы узнаете о роли тест-аналитика, задачах тест-анализа и форматах исследования программных продуктов.
Автор: Баранцев Алексей
Критерий — это некоторый признак, который имеет три основных назначения: при помощи него производится 1) оценка, 2) определение и 3) классификация. Рассмотрим эти три назначения по очереди применительно к тестированию программного обеспечения. Критерий начала тестирования. Критерии прекращения и завершения тестирования. Еще раз о метриках и оценках.
|
