Home

Павел Новик, ЗАО «Технологии качества», бренд A1QA

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

Однако, все не так просто, как может показаться на первый взгляд.

I. Непроста и неказиста жизнь рядового программиста тестировщика.

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

Что же делать со всеми приведёнными проблемами? Наверняка многие из Вас задумывались о возможном решении или предотвращении каждой из них.

Запись доклада Сергея Атрощенкова с онлайн-конференции Fun ConfeT&QA, весна 2012 года.

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

Если программисты могут описывать бизнес-логику, то и у нас есть богатство выбора, чем же заняться:

• Беседовать с заказчиком до потери пульса… Простите, до окончательного уточнения требований.
• Писать тесты для бизнес логики.
• Готовить тестовое окружение.
• Помочь заказчику и программистам найти общий язык и выработать совместное видение проекта.

И именно о 4м пункте я и расскажу.

На помощь, в этой задаче, к нам приходят макеты (концепт-скрины, если угодно). Для обсуждения названий контролов, для обсуждения того, что и на какую форму приложения необходимо поместить – это хорошая помощь. И, бывает так, что макет влияет на бизнес-логику: когда заказчик увидит прототипы, может оказаться, что его видение Кунг-фу вовсе не подразумевало ленивого медведя в роли Мастера…

Примеры создания макетов будут демонстрироваться с использованием инструмента Balsamiq.

SQL для тестировщиков – это такая вещь в себе. Все знают, что SQL тестировщикам нужен, но никто не знает зачем. Вернее, есть такие люди, которые знают, ведь не зря в двух вакансиях из трех знание SQL идет отдельной строкой. Но эти знающие люди будто находятся в каком-то тайном клубе. «Первое правило клуба знающих о том, зачем тестировщику SQL – не говорить о клубе знающих о том,…»

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

После чего – затишье аж до 2011 года, когда ещё один участник клуба «знающих» завел беседу на тему того, что же должен знать тестировщик и зачем.

А дальше утечка информации пошла более интенсивно и всё новые и новые тестировщики постигали сакральное знание: что же такое SQL и зачем оно нам? Появлялись новые темы на форуме, появлялись новые статьи в блогах: http://vestfalka.blogspot.nl/2013/03/test-it-sql.html и http://vestfalka.blogspot.nl/2013/03/7-sql-server.html.

Что самое приятное, сейчас вопрос о том зачем же нужен SQL в тестировании уже не возникает, а если и возникает – то ответов на него очень много, всегда можно найти такой, который подойдет именно тебе.

У нас на портале тоже был курс SQL для тестировщиков. Мы не стоим на месте, наши курсы растут и развиваются вместе с нами, мы всегда прислушиваемся к мнению наших учеников. Вот и курс SQL для тестировщиков рос-рос, сначала из маленького 4-лекционного стал большим 6-лекционным, а теперь и вовсе разделился на два, в полном соответствии с пожеланиями тех, кому «вот тут непонятно, давайте ещё раз пройдемся» (http://software-testing.ru/trainings/schedule?task=3&cid=230), и тех, кому «давайте без воды и ещё про триггеры расскажите!» (http://software-testing.ru/trainings/schedule?&task=3&cid=96).

Не знаете к какому курсу присоединиться? Не беда! Специально для Вас мы создали тест: http://software-testing.ru/lms/course/view.php?id=180 для определения Вашего уровня подготовки в SQL. На основании полученных результатов Вы сможете принять взвешенное решение. Попасть в опросник можно с использованием тех же логина и пароля, которые используются для входа на форум.

Только помните: первое правило клуба знающих SQL – никому не говорить о клубе знающих SQL!

Доклад Рины Ужевко с онлайн-встречи, приуроченной к Дню тестировщика 2014.

Каждый геймер мечтает работать в играх. У Рины мечта сбылась — она оказалась по ту сторону виртуальности и готова приоткрыть нам завесу тайны: как происходит процесс создания игры? как тестируется самая сложная механика -  баланс? Она расскажет не только про опыт взаимодействия с пользователями, но и много другого интересного. А ещё будет немного практики. Готовы тестировать игры? :)

Запись доклада Павла Абдюшева на онлайн-конференции Fun ConfeT&QA, весна 2012.

Часто в форуме появляются вопросы, которые обобщенно звучат так: «Есть фича. Помогите протестировать», без уточнения контекста использования. В итоге набирается некоторый набор позитивных и негативных кейсов, проверяющий, что конкретная функция работает, так называемый, чит-шит. Основной акцент в таких кейсах, как правило, делается на проверку ввода через пользовательский интерфейс и обработки разный значений с учетом используемых технологий.

Но можно ли считать, что выполнив этот набор кейсов, фича будет хорошо протестирована?

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

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

Компания Badoo с радостью делится второй частью докладов с конференции для тестировщиков LoveQA, которая проводилась в середине февраля. Первую часть докладов можно посмотреть здесь.

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

Что может сделать тестировщик, который хочет быть более эффективным? С чего стоит начать?

В докладе будет рассказано о подходе «изнутри-наружу», который позволит по-новому посмотреть на свою роль в команде и начать с изменений в самом себе.

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

Доклад будет интересен тем, кто ищет способ повысить продуктивность своей работы.

Keyword-driven подход к автоматизации тестирования был описан в литературе более 10-ти лет назад, однако в русскоязычных источниках по этой теме информации довольно мало.

В докладе, в рамках конференции AT Days, наш тренер Геннадий Алпаев, автор тренинга Автоматизация тестов с использованием TestComplete, рассказал о том, в чем заключается подход, когда применяется, его достоинства и недостатки, а также показал пример практической реализации Keyword-driven подхода для простого тестируемого приложения с помощью TestComplete и SilkTest.

Выложена еще одна часть записей докладов с прошедшей в Минске конференции SQA Days 12.

Релизимся чаще, или тернистый путь к continuous delivery
Александр Баяндин, 2ГИС, Новосибирск, Россия

Управление качеством в Agile. Как опередить баги
Антон Столяр, EPAM Systems, Минск, Беларусь

Сервисы на базе автоматизации тестирования
Артем Семенов, Align Technology, Inc., Москва, Россия

Архитектура автоматизированных тестов
Алексей Лянгузов, Grid Dynamics International, Inc, Санкт-Петербург, Россия

Описания докладов по ссылке Подробнее...

Выложена еще одна часть записей докладов с прошедшей в Минске конференции SQA Days 12.

Прогнозирование процесса выявления дефектов при тестировании программного обеспечения
Дмитрий Маевский, Одесский политехнический университет, Одесса, Украина

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

Нагрузочное тестирование Web проектов
Николай Миронцев, SmartBear Software, Тула, Россия

Доклад посвящен проблеме нагрузочного тестирования. Дается понятие данного вида тестирования и родственных ему: стресс-тестирования и тестирования производительности. Объясняется, зачем вообще проводят нагрузочное тестирование, всегда ли это необходимо и приводится общая схема его реализации. Подробно излагаются особенности нагрузочного тестирования для Web-проектов, а также рассматривается ряд тонкостей, которыми не следует пренебрегать в процессе создания стабильного web-приложения.
Вторая часть доклада представляет собой краткий обзор возможностей продукта LoadComplete от компании SmartBear, который является мощным и удобным инструментом для проведения комплексного нагрузочного тестирования. Особое внимание уделяется процедуре записи тестов и сценариев, возможности параметризирования переменных, значительно облегчающей задачу эмуляции многопользовательских запросов, а также подсистеме генерации отчетов и графиков.

Тестирование телеком-систем
Вячеслав Лукьяненко, A1QA, Минск, Беларусь

Каждый из нас пользуется мобильным телефоном и редко кто задумывается о том, что по другую сторону радиосигналов и проводов находится огромная система, которую тоже кто-то тестирует. Хотите узнать, как она работает? Хотите узнать, как происходит тестирование у операторов сотовой связи?
Из доклада вы узнаете, как человечество пришло к существующим телеком-системам: из чего они состоят, как работают, что скрывается за мудреной аббревиатурой OSS/BSS. Вы узнаете, какие задачи выполняет отдел тестирования, какие используются стратегии и техники: может быть что-то вы можете использовать и в своей, не менее интересной, доменной области?»

Тестирование по жесткой схеме! Или 27 + 2 фишки в построении процесса тестирования!

Игорь Любин, News360, Москва, Россия

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

Рассматриваемые под-темы в докладе:
• Планирование и определение целей
• Постановка и контроль задач
• Организация и улучшение процесса тестирования
• Выпуск версий и оценка результатов

Реалистичное нагрузочное тестирование
Валерий Куваев, Hewlett Packard в России, Москва, Россия

Реалистичное моделирование нагрузки для большого проекта - несбыточная мечта ответственного QA менеджера. Она, однако, не так далека от реальности. Нужно ответить лишь на некоторые вопросы.
Как разработать близкий к реальному сценарий нагрузочного тестирования приложения? Сколько и каких пользователей должно быть в системе? Какие действия они выполняют? Как смоделировать и воспроизвести влияние сетей WAN, 3G, 4G,WiFi и др. на характер открытой пользовательской сессии?
Давайте посмотрим, как средства эксплуатационного мониторинга и эмуляции сетей могут решить эту задачу.

И рады сообщить, что открыта регистрация на следующую конференцию SQA Days 13, которая пройдет в Санкт-Петербурге 26-27 апреля.

Перед конференцией пройдет тренинг Сергея Поваляшко "Метрики: проекты, процессы, качество". Всем участникам конференции предоставляется 10% скидка на участие в тренингах перед конференцией.