По моему опыту, тестирование юзабилити незаслуженно остается за бортом. Это особенно заметно по распределению усилий на тестирование. Я часто сталкивался с продуктами, которые сильно выиграли бы от тестирования удобства использования, но на него не хватило времени, которое образовалось бы, распланируй и формализуй его команда проекта.
Держа это в уме, я разработал небольшой список подсказок для тестирования юзабилити, который, возможно, поможет вам, если вы оказались в подобной неприятной ситуации.
Постоянство
Его легко и просто оценить, и оно крайне важно для юзабилити. Сталкивались ли вы с сайтами, на которых текст был представлен в различных шрифтах и размерах, списки были то с буллетами, то с иконками, а цветовая схема менялась от страницы к странице? Долго ли вы оставались на этом сайте? Недолго? Вот и я не стал себя мучить – я стараюсь покидать такие сайты как можно быстрее. Пользователь рассматривает подобное непостоянство как непрофессионализм. Насколько хорош сервис/продукт, если даже сайт сам себе не соответствует? Даже быстрый просмотр страниц сайта может выявить несоответствия. Удивительно, насколько они бросаются в глаза, если вы просто сфокусируетесь на них на некоторое время.
7 декабря компания Петер-Сервис проведет бесплатную встречу PS QA MEETUP.
На встрече будет идти разговор о возможностях Travis CI, а также о том, как использовать TORS + Report Portal, если не хватает ресурсов на анализ результатов автотестов. Формат встречи подразумевает живое общение со спикерами.
19.30 – 20.10 Введение в TravisCI
Артем Соковец расскажет о возможностях Travis CI и поделится опытом использования. Если вы автоматизатор, который хочет прогнать свои автотесты, или разработчик, которому необходимо прогнать модульные тесты на разных окружениях и проверить код статическим анализатором, то вы однозначно не сможете пройти мимо инструментов CI.
20.10 – 20.40 TORS + ReportPortal. Анализ результатов автотестов
Александр Илюшкин расскажет, как можно решить проблему, когда при большом количестве автоматизированных тестов не хватает ресурсов для своевременной аналитики их результата. Для решения этой проблемы в продукте TORS используется интеграция с системой Report Portal. Поговорим о том, как это используется и работает.
Тестирование производительности – обобщенное понятие, которым часто обозначают разные виды проверки ПО. В данной статье команда A1QA с опорой на реальные кейсы расскажет, в какой последовательности проводится тестирование и что измеряется на каждом из этапов.
Первым в череде тестов проводится стресс-тест (StressTest), цель которого – установить предельный уровень производительности продукта. Стресс-тест позволяет проанализировать зависимость ключевых характеристик системы (времени отклика самых важных бизнес-транзакций, количества запросов в секунду, количества транзакций в секунду) от количества одновременно работающих пользователей.
Во время стресс-теста нагрузка на систему подается непрерывно до тех пор, пока не будет достигнут один из критериев его остановки. Например, стресс-тест банковской системы был остановлен при превышении отметки в 1500 пользователей, когда высокая загруженность процессора (более 80%) привела к увеличению среднего времени отклика в пять раз и массовому появлению ошибок HTTP(S).
На втором этапе проводится нагрузочный тест(Load Test), с помощью которого оценивается способность системы справляться с длительной нагрузкой (4-8 часов). Количество пользователей для нагрузочного теста определяется в количестве 80% от результата максимальной производительности, выявленной при стресс-тесте. Уровень нагрузки при тестировании банковской системы поддерживался на одном уровне в течение восьми часов и составил 1200 пользователей. Нагрузочный тест показал существенное ухудшение производительности системы с течением времени, а дополнительное профилирование ее компонентов позволило обнаружить дефекты, проявляющиеся только при длительной работе большого количества пользователей (например, утечки памяти).
Вышел выпуск рассылки за вторую половину ноября, его содержание доступно по ссылке.
Как всегда в выпуске рассылки собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.
Начиная с этой рассылки, мы будем также делать подборку заметок из англоязычных блогов, которые транслируются в нашей ленте. Обратите внимание, что англоязычных блогов в ленте уже больше 100!
Меня зовут Дмитрий Химион, я руковожу отделом обеспечения качества в Avito. Cегодня я хочу рассказать про автоматизацию тестирования в рамках работы с микросервисной архитектурой. Что мы можем предложить разработке для того, чтобы облегчить контроль качества? Читайте под катом.
Вместо вступления
“An implementation should be conservative in its sending behavior, and liberal in its receiving behavior”.
Jonathan Bruce Postel, computer scientist
Что такое микросервисная архитектура?
Чтобы мой рассказ был полным, начнем с основ. Если упростить, микросервисная архитектура — это способ организации сервера приложений. Как он работает? По сути, это просто ответ сервис-ориентированной архитектуры на появление такой практики, как DevOps. Если в SOA не регламентированы размеры сервисов и то, что именно они должны делать, то в рамках микросервисной архитектуры есть некоторые умозрительные ограничения. Микросервис — это некоторая сущность, которая заключает в себе одну небольшую функциональность, которой она заведует и предоставляет внешним сервисам какие-то данные.
Множество попыток было предпринято для того, чтобы смоделировать различные подходы к тестированию ПО. Большая часть из них наверняка вам известна: исследовательское и скриптованное, традиционное и Agile, тестирование и проверки, стандартное и контекстно-зависимое – а также многое, многое другое.
Мне бы хотелось добавить к этому спектру кое-что еще, что я нахожу очень полезным: тестирование по фазам и по цепочкам.
Как следует из названия, модель описывает жизненный цикл тестирования или как серию неких фаз, или как взаимосвязанные цепочки.
Модель оказалась мне полезной для старта обсуждений практик тестирования агностичным способом, позволяя легко вычленить полезную информацию.
В предыдущей статье мы рассмотрели особенности тестирования «серого ящика» по сравнению с «белым» и «черным». Давайте сегодня подробнее остановимся на «черном ящике» и выясним, где и когда его используют, а также какие у него достоинства и недостатки.
Так называемое «black-box тестирование» является методом тестирования программного обеспечения, внутренняя структура, дизайн и реализация которого неизвестна тестировщику (при подготовке тест-кейсов он опирается на требования и спецификацию). Хочу обратить внимание на то, что требования и спецификация не всегда существуют в письменном виде; тем не менее, при тестировании методом черного ящика мы можем опираться на устно описанные требования.
Что такое «черный ящик» согласно терминологии ISTQB?
Black-box тестирование – это функциональное и нефункциональное тестирование без доступа к внутренней структуре компонентов системы. Метод тестирования «черного ящика» – процедура получения и выбора тестовых случаев на основе анализа спецификации (функциональной или нефункциональной), компонентов или системы без ссылки на их внутреннее устройство.
До конференции Heisenbug 2017 Moscow осталось меньше месяца, а это значит, пришло время еще раз изучить программу и наконец принять решение об участии.
Напоминаем вам, что Heisenbug 2017 Moscow - это два дня хардкорных докладов по тестированию для тестировщиков, разработчиков, тимлидов и всех, кому не безразлично качество продукта. Минимум философских рассуждений и максимум практики. Будем изучать подходы к тестированию, полезные инструменты и фреймворки и всё, что может пригодиться при отладке ваших приложений.
Для всех, кто не может приехать на конференцию в Москву лично, есть онлайн-трансляция в высоком качестве с возможностью общаться со всеми участниками и спикерами в Telegram.
Все участники смогут получить материалы конференции сразу же после окончания. А кроме этого вас ждут памятные подарки от организаторов, розыгрыши от спонсоров, вечеринка и море живого общения с коллегами и экспертами со всего мира.
Читайте подробную программу и регистрируйтесь на Heisenbug. Скоро будем тестировать Москву!
Чтобы получить билеты по специальной цене, воспользуйтесь ключевой фразой SoftwareTestingPromo.
15 счастливчиков-победителей конкурсов КоТэ стали обладателями уникального пазла тестировщика, а также других подарков от организаторов конференции. К нам поступило множество приятных отзывов о призах, и вот лишь несколько из них http://prntscr.com/hd25gmhttp://prntscr.com/hd25uphttp://prntscr.com/hd26hd
Благодарим всех, кто принял активное участие в нашем мероприятии!
Есть ли разница между «security testing» и «penetration test»? С вопросом, ответ на который, как мне казалось, лежит на поверхности, я столкнулся на конференции для специалистов по тестированию Testing Stage в начале июня. И хотя выступал я с другой темой, именно этот момент вызвал интерес и резонанс публики. Для большей части моих коллег термины «security testing» и «penetration test» равнозначны. Так ли это на самом деле? Давайте разбираться!
В общем понимании «тестирование на проникновение» представляет собой продукт или услугу по санкционированной попытке обхода средств защиты информационной системы. Результатом теста является отчет, который может/должен содержать список обнаруженных уязвимостей, использованных векторов атаки, достигнутых результатов, рекомендаций по исправлению. Обращаю ваше внимание именно на термин «информационная система» в связи с тем, что это понятие включает в себя не только программное или аппаратное обеспечение, а также данные, персонал, организационные мероприятия, документацию и иные процессы. Т. е. результаты «пентеста» информационной системы зависят не только от качества и условий настройки и эксплуатации реализации программного обеспечения, а также от аналогичных метрик аппаратного обеспечения, корректности действий персонала, налаженности и согласованности операционных процессов и т. д. В то же время «security testing» — это итеративный процесс тестирования безопасности функционирования инфраструктуры в целом, который учитывает все этапы и контроли, и в этом случае «penetration test» — обязательный элемент общей модели «security testing».
Вышел выпуск рассылки за вторую половину ноября, его содержание доступно 
