SqaВфны8

SQA Days является конференцией №1 на пространстве СНГ и одним из главных мероприятий в Восточной Европе, посвященных тематике тестирования и обеспечению качества программного обеспечения. 19-20 ноября 2010 года в Санкт-Петербурге прошла Восьмая международная конференция в области обеспечения качества ПО «Software Quality Assurance Days»

Конференция посвящена вопросам, связанным с тестированием и обеспечением качества программного обеспечения: • функциональному тестированию; • интеграционному тестированию; • тестированию производительности; • автоматизации тестирования и инструментальным средствам; • конфигурационному тестированию; • тестированию удобства использования (usability); • тестированию защищенности (security); • статическим методам обеспечения качества; • внедрению процессов тестирования на предприятии; • управлению процессами обеспечения качества ПО; • менеджменту команд тестировщиков и инженеров качества ПО; • аутсорсингу тестирования; • тестированию системных приложений (не Web), а также тестированию игр и мобильных приложений; • мотивации проектной команды и сертификации специалистов в области обеспечения качества ПО.

Качество — это ощущение, чувство, субъективная оценка. * качество больше чем отсутствие ошибок в коде * тестирование больше чем написание тест-кейсов * нельзя фокусироваться только на коде и на функциональности * testing is more than checking * checking можно автоматизировать * удобство использования нельзя автоматизировать * тестирование не может быть проведено машиной, но компьютер может помочь в тестировании * разработка ПО похожа на дизайн Тестирование более гуманитарная наука, чем мы можем себе представить «Two Futures of Software Testing»

Основная мысль: тестировщик не может отвечать за качество ПО, т.к. у него нет средств для того, чтобы на это качество повлиять: * не пишет код * нет возможности организационно повлиять на решение об исправлении ошибки * не управляет ресурсами проекта Основной продукт, который производит тестировщик - это информация о текущем состоянии ПО (включая качество). Тестировщик отвечает за качество этой информации, т.е. за качество своей работы. Качество работы тестировщика характеризуется: * объективностью * полнотой * своевременностью * эффективностью Очень важно одинаковое понимание всеми участниками процесса границ сферы ответственности тестировщиков. В ходе дискуссии еще раз была высказана здравая мысль, что брать ответственность на себя (в любом деле) можно только, если ты как-то можешь повлиять на процесс. «Отвечает ли тестировщик за качество?»

«Неудобство использования ПО - в чём вина тестировщиков?» Основные мысли: * Тестируйте и удобство использования, не только функционал! * Прокачивайтесь в юзабилити, дружите с дизайнерами. * Пользуйтесь своим же софтом! — eat your own dog food! Основная проблема : на удобство обращается очень мало внимания - отношение к делу (непонимание потребностей пользователя, непонимание предметной области, отсутствие эмпатии, высокомерие ) - человеческий фактор («когнитивное сопротивление» — использование первый раз очень важно, замыливание глаз, консерватизм) - особенности профессии (главное чтобы программа работала, синтетическаие условия, улучшения в целях тестирования, тестируем не так как работают пользователю) - безысходность (писать или не писать баг?) - руководство тестированием (не планируется тестирование удобства) Что могут сделать тестировщики: - своевременно и обосновано заводить дефекты (неисправность важнее неудобства. Если программа не работает, то неважно насколько она удобна) - тестировать пользовательскую документацию - дружить с дизайнерами и юзабилистами - читать соответствующую литературу и учиться - планировать тестирование удобства - предлагать скопировать удачные решения других программ - пользоваться по мере возможностей своей программой.

«Послание аналитиков тестировщикам» Эффективность проекта по разработке программного обеспечения и информационных систем зависит не только от эффективности выполнения работы отдельными ролями, но и эффективности их взаимодействия между собой. Исходные данные: тестировщик и аналитик это два разных человека. Проблемы: * качество требований * нехватка времени * как следствие — конфликт Причины: * неправильные сроки * нет инструментов для оценки и управления качеством требований * ожидания поставщика и потребителя не согласованы * глубина проработки требований по всем фичам одинакова Можно: * предварительная договоренность * рентабельность разработки требований Как: * совместная работа на ранних этапах * работать вместе, а не по очереди

«Лидерство в тестировании: 5 шагов, которые может сделать каждый» 5 шагов, которые может сделать каждый: * переиспользование: обращайте внимание, что делают вокруг (вдруг уже изобрели велосипед) и делитесь тем, что делаете вы (вдруг кто-то еще не знает о том, что велосипед изобретен) * настойчивость (адекватная): интересуйтесь, что стало с вашей работой * прозрачность: ваша работа должна быть максимально прозрачна для всех участников процесса * конструктивность: сосредоточьтесь на проблемах, а не на людях * удобство: коллегам должно быть удобно при работе с вами

«Девять правил Семпая, или Как стать успешным наставником?» * Вижу цель, иду к ней: - цели должны быть ясными, простыми и записанными на бумаге - они должны быть достижимыми - их стоит разбивать на более мелкие - лучше давать задачи, которые помогут достичь сразу нескольких целей * Желание помогать конкретному человеку: - наставник должен выбирать себе учеников * Стратегия: - от своих действий (ты посмотри) - к его действиям (сделай и расскажи) * Право на свою точку зрения * Доверие: - скрытные проверки - предупреждение о проверке * Ответственность: - наставника характеризует его ученик - ответственность за поступки ученика - радоваться его достижениям - не позволять другим критиковать вашего ученика * Спокойствие: - конструктивная критика - спокойные разговоры * Постоянно стремление к знаниям: - самообразование * Дальнейшая забота об Ученике

«Risk Driven Testing» Основной принцип: в первую очередь тестируется функционал, который подвержен наибольшим рискам. 1. определяем риски 2. составляем список 3. составляем тест-кейсы 4. проводим максимальный набор тест-кейсов Источники рисков: * продукт (ошибки логики, не та функциональность) * проект (сложность, неправильный процесс) * пользователи (могут неправильно использовать) Вероятность возникновения: * сложность функциональности * опытность разработчиков * опыт предыдущих релизов * был ли рефакторинг и т.д. Зачем: * ищем высокоприоритетные баги * это объективно * нет ограничений * расчет можно автоматизировать Как выяснилось это используется в маленьком проекте (4 месяца, без боевой эксплуатации), где релиз раз в неделю, на тестирование тратиться только 3-4 часа, требования меняются не очень часто.

«Качественная борьба за количество» Весь функционал делится на два типа: 1. тот, который надо протестировать обязательно 2. тот, который тестируется, если хватит времени сил Поле деятельности: * функционал * устойчивость * производительность * удобство использования * работа с данными * взаимодействие со смежными системами Необходимо: * расставить приоритеты * сопоставить время с рисками * сопоставить ресурсы с рисками * сопоставить финансы с рисками Когда становится очевидно, что не хватает людей, то поздно количество людей увеличивать. Скорость только снизится. Надо урезать функционал.

«Танки в Лунапарке: нагрузочное тестирование в Яндексе» Phantom – “легкий web-сервер”, который может генерировать до 80 тысяч запросов в секунду с одной машины. Около двух с половиной тысяч тестов в месяц. Агрегированные данные хранятся для каждой секунды теста. Хранить данные можно не более трех месяцев. Яндекс и Jira дружат (420 000 тикетов). Как во всем этом разбираются: настроили фильтр типа “что изменилось за последние пять минут в задачах, связанных с нагрузочным тестированием“, и раз в минуту программно вытягивают из Jira результаты этой фильтрации. Если в системе что-то появилось по поводу нагрузочного тестирования, то упомянутому в тикете сотруднику в jabber приходит сообщение. Почта была признана слишом медленной в этом процессе. Отображается в отчетах то, что нужно человеку в зависимости от его роли. Технические мелочи менеджер не видит, и наоборот (мелочи не видят менеджера). Информация должна подаваться в контексте – очень хороший подход, если информации очень много. Юзеры, которые приходят на сайт сами, ведут себя одинаково, почти предсказуемо. Те, кто приходят с рекламных линков, показывают странное поведение. Попыпаться предсказать поведение юзера – можно, и надо учесть, что это зависит от источника перехода.

«Мобильные технологии. Тестирование. С чего начать?» Особенности мобильных устройств: * меньшая производительность * способы ввода * иные ОС * кросс-платформенность * иные стандарты интерфейсов Лучший способ: дать попользоваться маме или сестре. =) Не забывать тестировать: * при звонках * при wifi * при GPS * при BlueTooth * «метро — замечательное место для поиска багов» * интерфейс * «приложение должно быть вежливым» Основные аспекты: * выделение самых популярных направлений (IPhone/Android); * их сравнительный анализ / немного исторического экскурса в развитие / описание основных понятий; * список полезных ссылок / программ полезных для тестирования; * непосредственный инструктаж: «Что делать, если с мобильными устройствами

«Особенности тестирования безопасности ПО» Тестирование безопасности отличается: * уязвимости находят обычно злоумышленники; * необходимо сосредоточиться на том, что приложение НЕ должно делать * невозможность тестирования некоторых требований безопасности * сложность оценки качества тестирования * Методологии тестирования (фаззирование, тесты на проникновение, сниффинг, анализ исходного кода и т.п. ). * Обзор некоторых стандартов тестирования безопасности (OSSTMM, OWASP Testing Guide, PROTOS, NIST). * Этапы тестирования * Типичные уязвимости * Сложности, которые могут возникнуть при тестировании безопасности. * Виды инструментов, применяющихся при тестировании с обзором некоторых из них.

«Интеллект-карты (Mind-Maps) в тестировании» * тест-анализ * brain-storming * документация * баг-лист * планирование (например можно план на день поставить в качестве фона рабочего стола) * хранение информации о сотрудниках * подготовка и запись доклада * тест-планы * вместо scrum-доски Инструменты : * Mind Jet Mind Manager * xMind * Mind Mapper Интеллект-карты – это инструмент, позволяющий многократно увеличить эффективность деятельности. Примеры их использования: * в проектировании тестов; * в налаживании коммуникаций; * в построении команды; * в подготовке стендов; * в повышении мотивации команды; * в повышении Вашей личной мотивации.

«Об опыте тестирования программного компонента без пользовательского интерфейса» Порой в разработке встречаются программные компоненты, у которых нет пользовательского интерфейса, а программный интерфейс к тому же еще имеет свою специфику, нестандартный. Это могут быть некие подкомпоненты программ, веб-сервисы, API веб-приложений, да и не только веб. Приложения могут быть написаны под windows, а могут работать и под linux. Что делать, если интерфейс нестандартный? Одно из решений на примере тестирования API сервиса для проекта «интернет газеты с элементами блогосферы»: Проект: интернет-газета с сервисами блогосферы. Нужно: протестировать API Вход: POST Выход: JSON Написали свой инструмент: * наборы тестов * запуск * отчетность * конфигурация.

«Тестирование ПО: по другую сторону баррикад.» Что разработчики хотят от тестировщиков (мнение зала): * баг-репорты * тест-кейсы * аналитическая информация * метрики * статистики Что разработчики хотят от тестировщиков (мнение докладчика): * максимальное покрытие тестами * хорошие инструменты для тестирования * своевременное информирование (предусмотреть время на исправление недочетов) * отчеты Что тестировщики хотят от разработчиков (мнение зала): * StableBuild * Change Log * совет, что посмотреть внимательнее * логгер * спецификацию * исходный код * работающие примеры * эмуляторы Что тестировщики хотят от разработчиков (мнение докладчика): * ПО, работающее по спецификации * быстрая реакция на ошибки и запросы * поменьше ошибок в коде * участие в обсуждениях и консультациях

«Нерелизное тестирование» При работе на непрерывном и плотном потоке задач не только разработке, но и тестировщикам необходимо выстраивать свою работу специфичным образом. Гибкость разработки должна поддерживаться гибкостью тестирования, и объектом оценки качества становится не 100%-собранный релиз, а набор изменений, как заказанных изначально, так и появившихся в процессе разработки, промежуточных отсмотров заказчиком, процесса тестирования. Как, не теряя ощущения порядка и сходимости процесса, добиться максимального быстрого прохождения релиза? * Тестирование происходит не релизов, а "пакетов" задач * Разработка осуществляется быстрее, чем тестирование * Тимлид разработчиков решает, что когда и в каком объеме будет тестироваться * Нет кросс-функциональности

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

«Подводные камни в процессах обеспечения качества ПО» Целью доклада является акцентирование внимания на некоторых нюансах в управлении процессами обеспечения качества, которые помогут избежать многих проблем: * Учёт бизнес-целей разрабатываемого продукта * Переработка готового продукта без спецификации * Обеспечение качества при резком уменьшении ресурсов * Особенности анализа статистики * QA должен знать цели проекта * при резком сокращении ресурсов надо перепланировать * метрики: нельзя делать процесс ради процесса

«Parasoft SOAtest» Рarasoft SOAtest - одно из решений для функционального тестирования ПО. Оно позволяет производить функциональное и нагрузочное тестирование, как пользовательского интерфейса программ, так и по широкому кругу протоколов в программных комплексах, основанных на сервисно- ориентированной архитектуре. Решение не требует знания программирования от тестировщиков, в то же время, обеспечивая обширную функциональность. Имеет богатые возможности интеграции с другими продуктами компании Parasoft для улучшения результатов анализа, облегчения работы тестировщиков. * Различные компоненты всей системы заменяем по очереди на SOATest * Тестируем сервисы, предоставляемые компонентами (сервис-ориентированная модель) * Не нужно ждать разработки остальных компонентов. Тестирование можно начать сразу * Advanced mode: Python, J, JS * Интеграция с JTest, .Test для тестирования на проникновение "изнутри" (покажет нам к чему приведет реализация той или иной атаки)

«Применение современных статических анализаторов» В докладе рассматриваются возможности современных статических анализаторов исходного кода, классы ошибок, которые они позволяют обнаруживать. На реальных примерах показывается, что современный статический анализ сильно продвинулся за возможности проверки стилистического соответствия кода, и сегодня статическими методами возможно обнаружение сложных ошибок динамической природы, таких как, например, разыменования нулевых указателей, использование неинициализированных данных, утечек памяти. Раньше обнаружение такого рода проблем требовало тестирования или динамического анализа со всеми сложностями и недостатками этих методов. Статический анализ, конечно, также не является панацеей, но, дополняя другие методы контроля качества, позволяет улучшить качество производимого ПО и сократить полные расходы на разработку (включая тестирование). Возможность совместного применения статического анализа и других методов контроля качества в цикле разработки ПО также рассматривается в докладе. http://www.slideshare.net/astenix/sqa8-urazov

OSSTM: Классификация видов тестирования безопасности по мнению автора(cost, time) * Vulnerability scanning (1,1) * Security scanning (2,4) * Penetration testing (3,2-3) * Risk assessment (6,2-3) * Security auditing (7,7) * Ethical hacking (4,5) * Posture assessment & security testing (5,6) OSSTM: Какая бывает безопасность, по мнению автора * Физическая * Коммуникаций * Беспроводная * Процессов Краткое описание методологии OSSTM. Её назначение, краткое содержание, какие проблемы она охватывает. Что в ней может быть полезно для разработки собственных тестов для тестирования безопасности информационных систем и программных продуктов. «Open Source Security Testing Methodology — Открытый фреймворк по тестированию безопасности»

SqaВфны8

More Related Content

What's hot

Viewers also liked

Similar to SqaВфны8

SqaВфны8