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

Подписаться

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

Конференции

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

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

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

Лучшие вакансии

.
Бесплатная YouTube-трансляция Heisenbug 2017 Moscow
08.12.2017 10:47

Конференция: Heisenbug 2017 Moscow

Дата: 8-9 декабря 2017 года

Бесплатная трансляция (только первый зал): страница трансляции на официальном сайте организаторов конференции.

Программа

Конференция проводится в течение двух дней. Первый день начинается в 10.00, второй — в 10.30. Каждый день оканчивается завершающим кейноутом (в 17.35 и 18.15 соответственно).

Актуальную программу первого зала можно увидеть на странице трансляции.

Подробнее...
 
Самый сложный случай, с которым я столкнулся, работая программистом
07.12.2017 11:16

Автор: Gerald M. Weinberg

Оригинальная публикация: http://secretsofconsulting.blogspot.ru/2017/10/my-most-challenging-experience-as.html

Перевод: Анастасия Данилкина

Читатели задали мне вопрос: «С каким самым сложным случаем вы столкнулись, работая программистом?»

Мы разрабатывали систему слежения для проекта Меркурий, которая должна была отправлять человека в космос и возвращать его живым обратно. Задача «вернуть живым» была сложной, но не единственной. Были и другие трудности:

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

Подробнее...
 
Тестовая документация. Превращаем таблицы в деревья
06.12.2017 11:00
      Автор: Святушенко Елена Андреевна, руководитель отдела тестирования в компании Touch Instinct

      Оригинальная публикация: https://habrahabr.ru/company/touchinstinct/blog/334660/

      В предыдущей статье я рассказывала, как в нашей компании проходит первая стадия тестирования проекта — анализ. Сегодня расскажу о следующем этапе — проектирования и документирования тестов.

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

      Вид тестовой документации также зависит от ситуации на проекте и ожиданий заказчика.

      Подробнее...
       
      Расширяем тестирование граничных значений
      05.12.2017 10:52

      Автор: Юлия Миронова, ведущий специалист компании "Лаборатория качества"

      Оригинальная публикация: http://quality-lab.ru/extend-testing-of-boundary-values/

      Самый первый метод тест-анализа, который каждый начинающий тестировщик постигает инстинктивно, – это метод граничных значений. Но так ли он прост, как это кажется на первый взгляд? Давайте разберемся!

      Для сравнения разных подходов возьмем конкретный пример. Пусть у нас на сайте есть форма предварительного расчета стоимости страховки жизни, базирующаяся на очень простой формуле. Клиент вводит возраст и сумму в рублях, на которую он хочет застраховать свою жизнь. Если клиент моложе 18 лет или старше 60, выводится сообщение: «К сожалению, на данный момент у нас нет для вас подходящих предложений». Во всех остальных случаях мы просто считаем процент от введенной суммы; этот процент равен возрасту клиента. Да, я знаю, что в реальности расчет будет гораздо сложнее, но для наших целей такая модель подойдет.

      Подробнее...
       
      Атака на юзабилити
      04.12.2017 10:23

      Автор: Дэвид Гринлис (David Greenlees)

      Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2014-February.pdf#page=3

      Перевод: Ольга Алифанова

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

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

      Постоянство

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

      Подробнее...
       
      PS QA MEETUP, 7 декабря, бесплатная встреча от компании Петер-Сервис
      01.12.2017 11:14

      7 декабря компания Петер-Сервис проведет бесплатную встречу PS QA MEETUP.

      На встрече будет идти разговор о возможностях Travis CI, а также о том, как использовать TORS + Report Portal, если не хватает ресурсов на анализ результатов автотестов. Формат встречи подразумевает живое общение со спикерами.

      19.30 – 20.10 Введение в Travis CI

      Артем Соковец расскажет о возможностях Travis CI и поделится опытом использования. Если вы автоматизатор, который хочет прогнать свои автотесты, или разработчик, которому необходимо прогнать модульные тесты на разных окружениях и проверить код статическим анализатором, то вы однозначно не сможете пройти мимо инструментов CI.

      20.10 – 20.40 TORS + Report Portal. Анализ результатов автотестов

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

      Зарегистрироваться на бесплатное участие

      Будет онлайн-трансляция мероприятия. Ссылка появится здесь за 2 дня до мероприятия.

       
      Тестирование производительности: последовательность тестов, измеряемые показатели, правила подачи нагрузки
      01.12.2017 10:24

      Тестирование производительности – обобщенное понятие, которым часто обозначают разные виды проверки ПО. В данной статье команда A1QA с опорой на реальные кейсы расскажет, в какой последовательности проводится тестирование и что измеряется на каждом из этапов.

      Первым в череде тестов проводится стресс-тест (Stress Test), цель которого – установить предельный уровень производительности продукта. Стресс-тест позволяет проанализировать зависимость ключевых характеристик системы (времени отклика самых важных бизнес-транзакций, количества запросов в секунду, количества транзакций в секунду) от количества одновременно работающих пользователей.

      Во время стресс-теста нагрузка на систему подается непрерывно до тех пор, пока не будет достигнут один из критериев его остановки. Например, стресс-тест банковской системы был остановлен при превышении отметки в 1500 пользователей, когда высокая загруженность процессора (более 80%) привела к увеличению среднего времени отклика в пять раз и массовому появлению ошибок HTTP(S).

      На втором этапе проводится нагрузочный тест (Load Test), с помощью которого оценивается способность системы справляться с длительной нагрузкой (4-8 часов). Количество пользователей для нагрузочного теста определяется в количестве 80% от результата максимальной производительности, выявленной при стресс-тесте. Уровень нагрузки при тестировании банковской системы поддерживался на одном уровне в течение восьми часов и составил 1200 пользователей. Нагрузочный тест показал существенное ухудшение производительности системы с течением времени, а дополнительное профилирование ее компонентов позволило обнаружить дефекты, проявляющиеся только при длительной работе большого количества пользователей (например, утечки памяти).

      Подробнее...
       
      Явные и неявные ожидания в Selenium WebDriver
      16.11.2017 23:37

      Доклад Ярослава Пернеровского на конференции TestingStage'17.

      Обсудить в форуме

       
      Скидка на Heisenbug, инструменты тестирования API, мобильная безопасность: новости тестирования за конец ноября - 2017
      29.11.2017 11:22

      Вышел выпуск рассылки за вторую половину ноября, его содержание доступно по ссылке.

      Как всегда в выпуске рассылки собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

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

      Подписаться на рассылку можно по ссылке.

      Обсудить в форуме

       
      Ядро автоматизации тестирования в микросервисной архитектуре
      28.11.2017 12:32

      Автор: Дмитрий Химион, Head of QA at Avito

      Оригинальная публикация: https://habrahabr.ru/company/avito/blog/333644/

      Меня зовут Дмитрий Химион, я руковожу отделом обеспечения качества в Avito. Cегодня я хочу рассказать про автоматизацию тестирования в рамках работы с микросервисной архитектурой. Что мы можем предложить разработке для того, чтобы облегчить контроль качества? Читайте под катом.

      Вместо вступления

      “An implementation should be conservative in its sending behavior, and liberal in its receiving behavior”.
      Jonathan Bruce Postel, computer scientist

      Что такое микросервисная архитектура?

      Чтобы мой рассказ был полным, начнем с основ. Если упростить, микросервисная архитектура — это способ организации сервера приложений. Как он работает? По сути, это просто ответ сервис-ориентированной архитектуры на появление такой практики, как DevOps. Если в SOA не регламентированы размеры сервисов и то, что именно они должны делать, то в рамках микросервисной архитектуры есть некоторые умозрительные ограничения. Микросервис — это некоторая сущность, которая заключает в себе одну небольшую функциональность, которой она заведует и предоставляет внешним сервисам какие-то данные.

      Подробнее...
       
      Тестирование по фазам и по цепочкам: сходства и различия
      27.11.2017 11:35

      Автор статьи: Аарон Ходдер (Aaron Hodder)

      Оригинал статьи: http://testerkiwi.blogspot.ru/2017/05/phased-vs-threaded-testing.html#more

      Перевод: Ольга Алифанова

      Множество попыток было предпринято для того, чтобы смоделировать различные подходы к тестированию ПО. Большая часть из них наверняка вам известна: исследовательское и скриптованное, традиционное и Agile, тестирование и проверки, стандартное и контекстно-зависимое – а также многое, многое другое.

      Мне бы хотелось добавить к этому спектру кое-что еще, что я нахожу очень полезным: тестирование по фазам и по цепочкам.

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

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

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