Home

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

Текст предоставлен JUG.RU Group – организаторами конференции по тестированию Гейзенбаг. Ближайшая конференция Гейзенбаг 2017 Moscow состоится в декабре в Москве. Подробности: https://heisenbug-moscow.ru/

При тестировании распределенных систем нефункциональные требования выходят на первое место, а для обнаружения сложных дефектов приходится применять специальные методы. Мы уже говорили о них с Андреем Сатариным в предыдущем интервью и сегодня попытаемся развить эту тему.

Андрей Сатарин занимается тестированием распределенных систем в Яндексе. Принимал участие в совершенно разных проектах: тестировал игру в Mail.ru, систему облачного детектирования в Лаборатории Касперского, а также систему расчета валютных цен в Deutsche Bank.

— Отказоустойчивость — одно из важнейших нефункциональных требований к распределенным системам. Как проводится тестирование отказоустойчивости? 

Андрей Сатарин: Сбои можно эмулировать в тестовой среде, так работает известный инструмент Jepsen, созданный Кайлом Кингсбери (Kyle Kingsbury). Второй подход предполагает внедрение сбоев в продуктивном окружении и обычно ассоциируется с Chaos Monkey компании Netflix, из которого выросло целое движение — хаос-инжиниринг. Он избавляет нас от проблем с повторением продуктовой среды и дает высокую уверенность в работоспособности системы, но более опасен и требует определенной зрелости продукта. 

Есть и третий подход, позволяющий проверить работоспособность алгоритмов еще до написания кода с помощью специальных инструментов, таких, например, как TLA+. Два наиболее известных примера его использования: разработка Amazon Web Services и Azure Cosmos DB.

Автор: Барт Ванхерк (Bart Vanherck).

Оригинал статьи: http://www.bartvanherck.be/2017/01/12/testers-can-learn-from-the-hunger-games/

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

Недавно я прочитал первую часть трилогии "Голодных игр" Сьюзан Коллинз. Книга, если задуматься, крайне интересная. Что можем мы, как тестировщики, вынести из Голодных игр?

1. Исследуй свое окружение

Когда Китнисс, главная героиня книги, входит в виртуальный мир, она понятия не имеет, что он из себя представляет. Каждый год игры проводятся в новом виртуальном пространстве. Что это значит для нее? Ей нужно познакомиться с этим пространством. Где находится вода, где можно найти еду, и так далее. Как она это делает? Исследуя мир вокруг себя.

В мире тестировщиков все аналогично. Каждый новый продукт или даже новый билд содержит какие-то нововведения. Тестировщику нужно исследовать этот новый билд. Как это работает? Какие ошибки тут можно допустить? Если я сделаю вот так, что случится дальше?

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

Если вы недавно в тестировании или только хотите попасть в эту область, приглашаем вас в нашу новую Школу для начинающих тестировщиков. Теорию можно прочитать в книжках, но как ее применять? Как насчет практики на реальном проекте, проведения ретроспективы в группе и составления портфолио?

Мы решили добавить в онлайн-обучение элементы Scrum, ведь именно гибкие методологии обычно встречаются в реальной работе. Так почему бы сразу не попробовать общаться в небольшой группе? В группе не только проще делать ДЗ, это очень мотивирует! Первая группа учится уже месяц, посмотрите, что они пишут на ретроспективе:

В апреле в Екатеринбурге прошла IT-конференция DUMP 2017. В числе восьми тематических секций была представлена и тема тестирования. Предлагаем вам посмотреть видеозапись доклада, который будет полезен тем, кто в этой области не очень давно - “Как “продать” баг разработчику”.

В докладе рассказано о том, как обосновывать баги. И зачем это надо: зачем вообще «продавать» баг кому-то из команды.

Доклад был подготовлен автором курсов по тестированию ПО, Ольгой Назиной, в том числе как видео в помощь студентам ее тренингов:

“Онлайн-интенсив для начинающих тестировщиков”;

“Техники и инструменты поиска и оформления дефектов”;

“Школа для начинающих тестировщиков”.

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

Тестирование программного кода — кропотливый и сложный процесс. Львиную долю работы в нем совершают unit-тесты. Пока они не «загорятся зеленым», тестировать дальше смысла нет. 

Как же писать unit-тесты правильно? Стоит ли гнаться за 100% покрытием? С какими сложностями приходится сталкиваться инженерам на практике? Своим опытом делятся Marc Philipp и Всеволод Брекелов. 

Marc Philipp – один из основных разработчиков фреймворка JUnit 5 – инструмента для Java-тестировщиков. В данный момент работает в качестве инженера в немецкой компании LogMeIn над облачными SaaS-решениями.

Всеволод Брекелов — Senior QA Engineer в компании Grid Dynamics, более 5 лет занимается тестированием, имеет опыт построения автоматизации тестирования с нуля.

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

Некоторые инструменты могут помочь создать лёгкие, надежные и легко поддерживаемые скрипты, но сами тяжелы в использовании. Другие — более просты в использовании, но на выходе вы получаете тест скрипты которые тяжело поддерживать. Каждый раз мы сталкиваемся с выбором, при котором мы где-то выигрываем, а где-то проигрываем.

Учитывая эту ситуацию, когда мне говорят про то, что некий инструмент обещает решить данную проблему — мне автоматически становится довольно интересно.

На протяжении прошлой недели я работал с простым, но мощным софтом — Katalon Studio. Он вмещает в себя UI возможности, которых мне так не хватает в Selenium WebDriver и гибкость, которой не может похвастаться UFT. И да, он абсолютно бесплатный.

=> Если вам интересно узнать больше, мы уже сделали один обзор этого бесплатного инструмента: Katalon Studio review. 

Оригинал статьи: http://www.testingexcellence.com/bad-requirements-software-testers-nightmare/

Автор: Намита Коли Арора (Namita Kohli Arora)

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

Реальный мир никогда не бывает переполнен розовыми пони, и то же самое справедливо для наших рабочих задач. Я множество раз сталкивалась с тест-проектами, которые были крайне далеки от идеала: в них отсутствовала даже самая базовая документация, и не было никакого намека на централизованное управление тестированием. Худшее, с чем я встречалась – это проекты, в которых или вообще не было требований, или эти требования были записаны абы как. Работа над такими проектами сводит меня с ума и стоит мне многих бессонных ночей (я не преувеличиваю – попытки разобраться в разрозненных информационных потоках заставляют мозг работать 24/7). Но нравится мне это или нет, такие проекты – наша реальность, и у нас нет выбора: с ними приходится иметь дело.

"Плохие требования" – довольно широкое понятие. К примеру, это могут быть:

"Альфа Лаборатория" —особое подразделение«Альфа-Банка»

В 2013 году мы взяли классический, сильный банк, умеющий хорошо управлять деньгами, добавили к нему digital-команду,построили wow-офис и создали «Альфа-Лабораторию». В Лаборатории мы занимаемся тем, что создаем продукты для коммуникации с нашими клиентами (людьми и компаниями)через digital-каналы. Наши продукты: «Альфа-Клик», «Альфа-Мобайл», «O!pp», «Альфа-диалог», «Альфа Бизнес-Онлайн»и «Альфа Бизнес-Мобайл» и др.

Мы – сообщество отличных людей с общими целямии классными ценностями. Мы люди, одержимые будущим и технологиями. Нам нравится всё новое и интересное, мы с радостью включаем всё примечательное в наши бизнес-процессы.Agile, KANBAN, Design-thinking — для нас не просто модные слова, они - важная часть нашей жизни. Мы любим хорошие идеи и людей, способных эти идеи создавать и воплощать. Мы находимся в постоянном поиске таких людей.
Мы не-просто-ходим на не-просто-работу.

Несмотря на то, что мы - банкиры, наш офис и распорядок жизни в нем ничем не напоминает банковский. Офис «Альфа-Лаборатории» - это особое пространство, где всё устроено так, чтобы нам было в нем просто хорошо. Мы также устраиваем кучу крутых вещей, позволяющих нам развиваться и развивать наши продукты. Мы придумали и делаем Alfa-Camp - долгосрочную программу поиска и развития стартапов, целью которой является реализация продуктов для онлайн-индустрии. Мы проводим Hackathon – событие, на котором наши внутренние команды не просто делают презентацию идеи, а создают работающие приложения, и это не проекты «в стол». Одно из таких приложений прошлого года стало стратегическим проектом «Альфа-Банка» в новом году. А ещё мы запустили программу iChooseAlfa, по которой уже несколько лет стажируются лучшие студенты сильнейших московских вузов. Мы нравимся тебе?

ЕСЛИ ТЫ РАЗРАБОТЧИК (JAVA, JAVASCRIPT, IOS, ANDROID), ДИЗАЙНЕР, PRODUCT OWNER, SCRUM MASTER, АНАЛИТИК ИЛИ ТЕСТИРОВЩИК, ТО МЫ ЖДЕМ ТЕБЯ В СВОЕЙ КОМАНДЕ!

Резюме присылайте по адресу: Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript