Home

Тест-анализ -- фундаментальная составляющая тестирования. На Amazon'е этой теме посвящено множество книг, но ни одна из них пока что не переводилась на русский язык.

Что же такое тест-анализ? Какие задачи решает тест-аналитик? Какие виды анализа и исследования тестируемого ПО существуют?

Для ответов на эти вопросы мы публикуем 1-й вебинар Натальи Руколь по курсу "Школа Тест-Аналитика".  Из него вы узнаете о роли тест-аналитика, задачах тест-анализа и форматах исследования программных продуктов.

После того, как мы опубликовали рассказ о четырёх способах упорядочения тестов, предлагаемых тестовым фреймворком TestNG, в комментариях неоднократно звучал вопрос -- не является ли создание зависимостей между тестами плохой практикой?

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

И в качестве ответа на эти комментарии Алексей Баранцев написал две статьи, которые разъясняют, почему, с одной стороны, тесты действительно должны быть независимыми, а с другой стороны -- их всё-таки можно упорядочивать, и все четыре описанных способа могут применяться, в том числе даже жёсткие зависимости между тестовыми методами.

Итак,
Почему зависимости между тестами это плохо?
и
Почему иногда всё-таки можно делать зависимые тестовые методы?

В своей новой статье Наталья Руколь, автор и ведущая Школы Тест-Аналитика, рассказывает о самой сложной части тест-анализа: отказа от тестов по причине нехватки времени. Как, когда, какие?

Тяжкая миссия тестировщика

Какая самая главная задача тестировщика? Какой навык является наиболее ценным для хорошего тестирования?

Начинающие тестировщики обычно считают, что их главная задача - придумать как можно больше тестов:

• Что может влиять на выполнение той или иной операции?

• При каких значениях всё может сломаться?

• Как “положить” систему?

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

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

• чёткое разбиение на классы эквивалентности и доменный анализ,

• комбинаторику значений параметров действия,

• pairwise и triplewise

• и т..д.

Опытный тестировщик видит больше влияний, учитывает больше связей, и как следствие понимает необходимость в проведении значительно большего количества тестов.

И именно здесь - ступень для перехода на следующий уровень экспертизы и мастерства. В дело вступает реальность: в большинстве случаев провести достаточное количество тестов невозможно. “Спасибо, что вы столько тестов придумали, но продукт мы отдаём в тестирование сегодня вечером, а релиз должен состояться завтра”.

У некоторых тестировщиков такая ситуация вызывает постепенную демотивацию: мы не можем протестировать всё! Но просветлённые тестировщики смотрят на ту же проблему под другим углом: “отлично! вот это challenge! мне надо придумать, как протестировать это всё действительно быстро!”. А чтобы протестировать в сжатые сроки, от каких-то тестов придётся отказаться. Каждый из них может найти потенциальный дефект, и получается, что, отказываясь от проведения того или иного теста, мы повышаем вероятность пропуска дефекта. Насколько критичного? Зависит от теста, которому мы говорим “прости и прощай, но не в этот раз”. И получается, что главная задача тестировщика в этом случае - выбрать, какие тесты мы не будем проводить. Не будем тестировать, Карл!

Авторы: А. В. Баранцев, С. В. Грошев, В. А. Омельченко
Труды Института системного программирования РАН

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

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

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

Автор: Баранцев Алексей

Критерий — это некоторый признак, который имеет три основных назначения: при помощи него производится 1) оценка, 2) определение и 3) классификация. Рассмотрим эти три назначения по очереди применительно к тестированию программного обеспечения. Критерий начала тестирования. Критерии прекращения и завершения тестирования. Еще раз о метриках и оценках.

Е.Гузаревич, Д.Ермакович, 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 для хранения данных.

Публикация компании IT-Online

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

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

Автор: Юлия Нечаева

Часто задают вопрос: как быть с тем, что программисты не любят тестировщиков, считают их работу второстепенной, пишут неряшливо – «все равно ведь проверят» либо мстят за каждый найденный баг и пытаются не признавать их за баги.
Или наоборот, программисты жалуются, что тестировщики злорадствуют, найдя баг, и считают личным достижением, если программист наделал много ошибок.

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

Автор: Илья Комендантов

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

Когда встречаю объявления типа: "В связи с расширением штата сотрудников, требуется..", "Молодая развивающаяся компания ищет.. " и подобные им, сразу представляю, как маленькое село вырастает в пгт, оно, в свою очередь, в город, а тот – в мегаполис.

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

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

Такое себе – нагрузочное тестирование. Может стоит для анализа проблем фирмы нанимать перформанс инженеров? Почему бы и нет.. Интересно, были прецеденты?