Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Heisenbug 2021 Moscow
Большая техническая конференция для тестировщиков
5-7 октября 2021, онлайн

Что пишут в блогах (EN)

Разделы портала

Про инструменты

.
Тест-анализ и тест-дизайн
Ещё раз про pairwise
11.11.2014 15:23

Выступление Алексея Баранцева на онлайн-конференции для тестировщиков Fun ConfeT&QA.

Техника покрытия попарных комбинаций (pairwise testing) – пожалуй, одна из самых «магических». Сотня параметров? Миллионы миллиарды триллионы дециллионы комбинаций? Нет проблем! Берём Магический Инструмент, закладываем в него данные об этих параметрах, нажимаем Магическую Кнопку. Месиво цифр – и на выходе всего десяток комбинаций, которые нужно проверить.

Я встречал две крайности в применении этой техники.

Одна крайность – использование везде, с потрясающе простым обоснованием применимости – «ну, тестов же мало получается, это классно!» Другая крайность – полный отказ от использования этой техники, с не менее замечательным объяснением – «непонятно, как это работает, а тестов получается подозрительно мало, не верю!»

Да, непонятно как это работает внутри. И я не призываю изучать алгоритмы генерации магических комбинаций. Многие прекрасно водят автомобиль, не понимая его внутреннего устройства, принципа работы, использованных инженерных решений. Зато все должны знать, как рулить и как тормозить.

Я расскажу, не прибегая к теории, какие существуют кнопки и рычаги управления техникой покрытия попарных комбинаций:

  • когда она эффективна, а когда не очень,
  • какие зависимости между параметрами мешают применять эту технику, а какие не мешают,
  • как «дробить» и «склеивать» переменные, чтобы заставить технику работать эффективнее,
  • меняется ли результат от «перестановки мест слагаемых»,
  • какие баги пропускает эта техника и почему.

Ах да, конечно, обязательно покажу Магические Инструменты, как же без этого :)

Подробнее...
 
Приложения на SharePoint: «дорожная карта» тестировщика
15.05.2014 18:35

Е.Гузаревич, Д.Ермакович, OOO «Технологии качества», бренд A1QA

Тестирование приложений, построенных на SharePoint – задача нетривиальная, как и поиск информации на эту тему. В данной статье попытаемся расскрыть особенности тестирования приложений на SharePoint, например, что обязательно стоит тестировать и чем можно пренебречь. Кроме того, мы ознакомим читателей с программными ограничениями платформы.

Что такое SharePoint?

Прежде чем переходить непосредственно к особенностям тестирования, стоит сказать несколько слов о самой платформе SharePoint. По сути – это CMS (Content Management System), которая содержит развитую систему документооборота - DMS (Document Management System). Если быть совсем точным, то возможности SharePoint, как CMS, в «зачаточном» состоянии, а вот с задачами организации совместной работы, возможностями создания файлового архива и управления документами он справляется на «высшем уровне»! SharePoint чаще всего применяется для создания корпоративных интранет порталов, предназначенных для облегчения взаимодействия сотрудников в пределах одной компании или организации.

Итак, SharePoint — это веб-ориентированная платформа для совместной работы и система управления документами, разработанная и реализуемая Microsoft. Таким образом, эта платформа становится единым коммуникационным центром и электронным хранилищем информации одновременно. Это решение может использоваться для создания корпоративного веб-портала, на котором размещаются совместно используемые документы или специализированные приложения общего пользования. Данные в SharePoint организованы в виде списков (например, задачи, обсуждения, календари) и библиотек документов. Функциональность SharePoint представляется пользователю посредством веб-частей — элементов управления, показывающих списки и позволяющих редактировать их. Такие веб-части размещаются на страницах, в свою очередь, публикуемых на портале и доступных пользователю через браузер. По своему содержанию SharePoint - приложение ASP.NET 2.0, использующее IIS для отображения веб-страниц и SQL Server для хранения данных.

Подробнее...
 
Переходя все границы...
25.03.2014 12:21

Доклад Алексея Баранцева

Анализ границ - эту технику каждый тестировщик осваивает, наверное, самой первой.

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

Что будет, если пользователь, случайно или намеренно, пересечёт такую технологическую границу - введёт слишком большое число или слишком длинную строку? Должен ли тестировщик пытаться это выяснить? Или может быть достаточно предупредить пользователей, чтобы они не вводили "плохие" данные, а кто ввёл - мы ответственности не несём? А если всё таки мы решили, что тестировщику следует пытаться всё это проверить -как искать эти границы, если они нигде не описаны?

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

Это вторая, более полная версия доклада о границах, с более интересными и живыми примерами. Ведь на границах багов намного больше, чем мы можем себе представить.

Переходя все границы... (Алексей Баранцев, SQADays-11) from Stas Fomin on Vimeo.

Хотите узнать больше про различные техники тест-дизайна? Приходите на онлайн-тренинг Практикум по тест-дизайну или очный тренинг в Москве Тест-дизайн от А до Я

 
Мелочь пузатая, или Объем тест-кейса против содержательности
08.12.2013 22:40

Запись доклада Алексея Лупана с онлайн-конференции Fun ConfeT&QA.

Мы так любим писать тест-кейсы, что учимся этому делу буквально с начала первого дня тестирования до исхода второго дня. Потом всю карьеру доучиваемся. То пишем мелкие тест-кейсики, то ваяем полотна Боттичелли. Подсказать алгоритм «золотой середины» написания грамотных тест-кейсов?

Подробнее...
 
Математика для тестировщиков
08.07.2013 21:30

Продолжаем публикацию лучших докладов SQA Days 13. Сегодня представляем доклад Никиты Налютина "Математика для тестировщиков".

Новые методики тест-дизайна не всегда рождались одномоментно, не все в инженерной практике может появиться в результате только лишь одного озарения и гениальных идей, увиденных во сне. Достаточно большая часть современных практик тестирования появилась в результате кропотливой теоретической и экспериментальной работы по адаптации математических моделей. И, хотя, для того, чтобы быть хорошим тестировщиком, вовсе не обязательно быть математиком, полезно понимать, какая теоретическая база лежит в основе того или иного метода тестирования. В докладе я расскажу о том, какую базу для тестирования дает математическая логика, теория формальных языков, математическая статистика и другие разделы математики; какие направления, связанные с тестированием, существуют в теоретическом computer science; появления каких новых методов можно ожидать в ближайшее время.

Подробнее...
 
Тест-анализ на основе состояний и переходов
19.11.2012 19:45

Подведены итоги очередной онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Как обычно публикуем лучший по результатам голосования доклад.
Это доклад Натальи Руколь "Тест-анализ на основе состояний и переходов".

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

  • Как эти тесты продумать?
  • Как обеспечить высокое покрытие не избыточным количеством тестов?
  • Какие инструменты есть для тестирования состояний и переходов и как их использовать?

 

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

Подробнее...
 
Ода скриптовому тестированию
30.05.2012 20:42

Автор: Наталья Руколь

Последнее время тестирование по заранее написанным тестам (назовём такое тестирование скриптовым) выходит из моды. У противников скриптового тестирования много аргументов, хотя в большую часть из них я, увы, не верю. В этой статье я хочу рассказать о своём взгляде на скриптовое тестирование и его существенных плюсах. Вполне вероятно, что эти плюсы окажутся вам незакомыми. Не потому, что подход неправильный! Возможно, вы просто сталкивались с его неудачной реализацией? Для этого вторая часть статьи: о том, как внедрять скриптовое тестирование наиболее эффективно.

Словарь

В рамках этой статьи я буду называть скриптовым тестирование, перед началом которого создаются тесты, и уже по ним осуществляются проверки. В качестве альтернативы скриптовому подходу можно рассматривать ad hoc, хаотическое и исследовательское тестирования, но о них в отдельной статье — оде тестированию исследовательскому. Пока что мы просто поделим тестирование на скриптовое (основанное на заранее написанных тестах) и без-скриптовое, то есть любое другое :)

Подробнее...
 
Pairwise testing with PICT
30.01.2012 18:17

Автор: Алексей Федорко

Оригинальная публикация

Если в качестве инструмента у вас имеется лишь молоток, каждая проблема начинает напоминать гвоздь. Абрахам Маслоу

В этой небольшой заметке я бы хотел рассмотреть инструмент для попарного тестирования от Microsoft – PICT (Pairwise Independent Combinatorial Testing). Уже несколько раз я применял его в своей работе и был доволен теми гибкими опциями, которые он имеет.

Подробнее...
 
Преимущества и недостатки комбинирования параметров
05.12.2011 15:22

Автор: Александр Федоров

Любой тест состоит из последовательности шагов и набора параметров, которые необходимы для выполнения теста. Так, для создания архива при помощи программы архиватора необходимо не только выбрать данные для архивации и инициировать создание архива, но и определиться с тем, какого типа данные архивируются и где они расположены. В этом примере выбор данных и создание архива будут являться шагами (сценарием), а тип данных и их расположение – параметрами. Один и тот же сценарий может выполняться с различными параметрами – в результате возникает закономерный вопрос, какие параметры и когда использовать. Сегодня мы рассмотрим одну из важных сторон этого вопроса: комбинирование параметров.

Тесты можно разделить на два типа:

  1. На проверку одного параметра
  2. На проверку взаимодействия нескольких (двух и более) параметров

Целью статьи является рассмотрение этих двух типов тестов, преимуществ и недостатков их использования друг перед другом. Они могут напомнить о видах тестирования, модульном и интеграционном, однако поскольку взаимодействие параметров возможно в рамках одного модуля (интеграционное тестирование подразумевает проверку взаимодействия между модулями), я предлагаю использовать иную терминологию: «простой» и «комбинаторный» тест.

Подробнее...
 
Почему мы пропускаем ошибки?
10.10.2011 17:18

Автор: Наталья Руколь

Страшный сон любого ответственного тестировщика – пропуск ошибки. Вы стараетесь-стараетесь, проверяете продукт, тестируете его по 8+ часов ежедневно, а после выпуска пользователь в течение недели сообщает о критичной проблеме. Как такое может быть, почему и как исправить?

 

Подробнее...
 



Страница 7 из 9