Кратко о системном тестировании. Цель и основные типы.

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

    Функциональная проверка (functional testing) не требует от тестировщика знаний принципов работы программного продукта, в то же время она требует знаний функ­циональных требований, предъявляемых к системе. Она использует набор тестов, которые определяют, выполняет ли система все то, что она должна делать с точки зрения  пользователя. 

    После того, как тестирование подтвердило адекватность базовой  функционально­сти системы, задачей тестирования становится проверка, насколько хорошо система выполняет свои функции. В рамках испытаний для определения рабочих характеристик (performance testing) выполняются такие проверки, как тестирование в предельных режимах, нагрузочные испытания, контроль синхронизации и проверка восстанавли­ваемости. Испытания на надежность, на эксплуатационную готовность, проверка приспособленности к техническому   обслуживанию также можно включить в число испытаний для определения рабочих характеристик . 

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

Найбільш поширені техніки тест дизайну.

• Еквівалентне розподілення (Equivalence Partitioning - EP). Наприклад, ви маєте діапазон допустимих значень від 1 до 10, ви повинні обрати одне вірне значення всередині інтервалу, припустимо, 5, і одне невірне значення поза інтервалом - 0.
• Аналіз Граничних Значень (Boundary Value Analysis - BVA). Якщо взяти приклад вище, в якості значень для позитивного тестувания оберемо мінімальну та максимальну межі (1 і 10), та значення більше та меньше за межі (0 і 11). Аналіз граничних значень може бути застосований до полів, записів, файлів, до всього, що має межі.
• Причина / Наслідок (Cause/Effect - CE). Це, як правило, введення комбінацій умов (причин), для отримання відповіді від системи (Наслідок). Наприклад, ви перевіряєте можливість додати клієнта, використовуючи певну екранну форму. Для цього вам необхідно буде ввести декілька полів, таких як "Ім'я", "Адреса", "Номер Телефону" після чого, натиснути кнопку "Додати" - це "Причина". Після натиснення кнопки "Додати", система додає клієнта в базу даних та відображає його номер на екрані - це "Наслідок".

Пріоритет дефекту (Priority)

P1 Високий (High) 
Помилка повинна бути виправлена якомога скоріше, так як її наявність є критичною для проекту.

P2 Середній (Medium) 
Помилка повинна бути виправлена, її наявність не є критичною, але потребує обов'язкового вирішення.

P3 Низький (Low) 
Помилка повинна бути виправлена, її наявність не є критичною та не потребує термінового вирішення.

Тестовое Покрытие (Test Coverage)

Тестовое Покрытие - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода.

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

Существуют следущие подходы к оценке и измерению тестового покрытия:

1. Покрытие требований (Requirements Coverage) - оценка покрытия тестами функциональных и нефункциональных требований к продукту путем построения матриц трассировки (traceability matrix).
2. Покрытие кода (Code Coverage) - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей программного обеспечения.
3. Тестовое покрытие на базе анализа потока управления - оценка покрытия основанная на определении путей выполнения кода программного модуля и создания выполняемых тест кейсов для покрытия этих путей.
   

Техніка тестування.

Існує багато прийомів тестування програмного забезпечення. Основні з них ми представили для Вас нижче у списку.

• Ручне тестування - тести виконуються людьми з наперед складеними, або визначеними для кожного випробування тестовими даними.
• Автоматизоване тестування - тести виконуються спеціальними інструментами або самостійними процесами і можуть повторюватись багато раз. Тестові дані попередньо вводяться або генеруються.
• Регресивне тестування - тести, зазвичай, автоматизовані, мають на меті виявлення негативного впливу змін в програмі на функції, що пройшли попередні перевірки.
• Димове тестування - тести, спрямовані на швидку перевірку базової функціональності, з метою виявлення, чи новий білд вартий тестування.
• Дослідницьке тестування - тести, що виконуються за відсутності специфікацій. тестувальник розроблює власну систему тестування, яка базується на накопиченому їм досвіді та оцінює ризики, створюючи сценарії тестування.
• Стрес-тестування - тести призначені для перевірки стійкості програми до надмірного навантаження при нестачі ресурсів.
• Тестування навантаження - тести виконуються при різних рівнях навантаження з метою перевірити поведінку програми та виявити максимально дозволений рівень.
• Тестування продуктивності - тести виконуються для порівняння поточної продуктивності з розрахунковою.
• Тестування інсталяції - тести полягають у встановленні програми на різних платформах-комбінаціях та перевірки: чи всі файли було переписано, чи працює програма коректно.
• Тестування довгим використанням - тести виконуються довготривало, з метою виявлення такого роду помилок, що неможливо виявити при короткому використанні (наприклад, помилки при роботі з динамічним розподілом пам’яті).

Артефакты тестирования.

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

• План тестирования (Test Plan) - это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.
• Набор тест кейсов и тестов (Test Case & Test suite) - это последовательность действий, по которой можно проверить соответствует ли тестируемая функция установленным требованиям.
• Дефекты / Баг Репорты (Bug Reports / Defects) - это документы, описывающие ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Рівні тестування.

Відповідно до етапів розробки ПЗ прийнято виділяти три рівні тестування:

модульне, інтеграційне та системне.

• Модульне тестування, тестування модуля або автономне тестування (module testing, unit testing) - контроль окремого програмного модуля, зазвичай в ізольованому середовищі (тобто ізольовано від решти всіх модулів). Під модулем розуміється логічно замкнутий фрагмент програми, який може бути викликаний через його інтерфейс. Модуль перевіряється на відповідність своїм специфікаціям і внутрішню логіку.
• Інтеграційне тестування або тестування взаємодій (integration testing) - контроль взаємодії між частинами системи (модулями, компонентами, підсистемами).
• Системне або комплексне тестування (system testing) - контроль та/або випробування всього програмного забезпечення, як повної системи, в цільовому середовищі, тобто підтвердження того, що доступ до всіх компонентів системи і взаємодія з ними несуперечливі і передбачені згідно специфікацій системи.

AGILEEE: программа конференции+плюшки

Начинаем обратный отсчет до старта шестой конференции AGILEEE!

Уже готова предварительная программа конференции, а так же плюшки тем, кто регистрируется по самым выгодным ценам. Итак, 2 дня AGILEEE - это:

• 3 потока докладов, мастер-классы, что бы каждый смог получить именно то, что ему нужно;
• 25+ докладчиков международного уровня;
• более 300 гостей из стран СНГ, США и Европы.

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

Только до 15 марта вы можете зарегистрироваться до специальной цене - Regular! Но это еще не всё, вы также сможете воспользоваться специальным промокодом 03GQD4G3L0CH на скидку 5%!

Успейте зарегистрироваться по самому выгодному предложению здесь.

До встречи на AGILEEE!

Якість (Quality) програмного забезпечення.

    Існує одне дуже важливе поняття у тестуванні програмного забезпечення. Всі його розуміють, та не всі можуть дати чітке визначення, що ж таке якість програмного забезпечення?

Даєм відповідь.

Якість (Quality) - ступінь відповідності програмного забезпечення заданим вимогам, потребам або очікуванням користувача. З метою визначення якості системи використовують так звані атрибути якості - характеристики, що відображають дану властивість.

Приклади атрибутів якості:

• надійність ( reliability) - властивість, що відповідає за безперервність коректного протікання процесу;
• готовність (availability) - властивість, що відповідає за постійну готовність системи;
• безпека (safety) - властивість, що відповідає за відсутність катастрофічних наслідків в системному середовищі;
• конфіденційність (confidentiality) - властивість, що відповідає за запобігання несанкціонованому доступу до інформації;
• цілісність (integrity) - властивість, що відповідає за відсутність появи в системі відповідних змін інформації;
• ремонтопридатність (maintainability) - властивість, що відповідає за здатність системи піддаватися ремонту і розвитку;
• зручність роботи (usability) - властивість, що визначає рівень зусиль, необхідних для навчання, роботи, підготовки вхідних і обробки вихідних даних ПЗ.

IT JAM and IT EDUCATION AWARDS 2015!

Новини IT Jam 2015! Шановні друзі! Щойно опублікували інформацію про наших дивовижних спiкерiв, які приєднались до одного з найбiльш вiдомих заходiв украiнської ІТ-індустрії –7го IT Jam “Meet&Mix”. І це ще не все! Нагадуємо, що IT Jam 2015 вiдбудеться у суботу, 21 березня на головній арені країни - НСК «Олімпійський», і цього разу буде присвячений темам Інновацій та IT Освіти - ми покажемо, що класного і цікавого зараз відбувається в IT, і розповімо, як зробити свій перший крок в IT. Безкоштовний квиток-запрошення надасть вам доступ до всіх зон на ІТ Jam 2015:

Дві основні сцени: на яких будуть виступати спiкери з 6 різних країн світу, з відомих ІТ-компаній, які презентують інновації різних проектів та галузей: безпека, електронна охорона здоров'я, енергетика, криптографія, дизайн, eye-tracking системи, мобільність, автомобільна  галузь та іншi.

Ярмарок навчальних ініціатив: ви будете мати можливість дізнатися, як потрапити до IT-сфери, або як покращити свої знання та навички в IT-галузі. Також у вас буде шанс виграти гранти від наших Освітніх Партнерів.

IT EDUCATION AWARDS Ми запускаємо першу щорiчну Нагороду - IT Education Awards, яка спрямована на заохочення тих, хто вкладає свою єнергію та час в навчання і розвиток ІТ професіоналів. Приходьте та дiзнайтесь, хто стане переможцем!

Інтерактивна зона  "Gadget area"  Дрони, Oculus Rift, 3D-принтер, системи eye-tracking, роботи та ще багато чого цiкавого! Приходьте та доторкнiться до майбутнього – воно вже сьогодні! Офіційне відкриття відбудеться о 12:00, але наші двері будуть відкриті з 11:00. Розклад заходу буде опубліковано на нашому сайті ближче до 21го березня. Вхід на захід вільний, але вам необхідно зареєструватися на сайті, щоб отримати запрошення. Заповніть, будь ласка, реєстраційну форму, це -  всього декілька хвилин!

Стартує UA Web Challenge VII Всеукраїнський чемпіонат з веб-розробки

Відкрито реєстрацію в номінаціях:

• Front-end developer
• Back-end developer
• QA 
• Web Designer
• Best Team

Дві категорії: Junior та Middle/Senior.
Участь безкоштовна.

Зареєструйтесь: uwcua.com

Чемпіонат UA Web Challenge надасть Вам можливість:

• Знайти нову роботу, контакти, замовлення
• Перевірити і оцінити себе
• Порівняти і підняти свій рівень
• Отримати море позитиву від участі

Партнери UA Web Challenge VII:
Генеральний партнер сезону GlobalLogic, партнер сезону Astound.

Difference between error, failure, fault, bug, defect.

Error/mistake: A human action that produces an incorrect result.

Fault/defect /bug: A flaw in a component or system that can cause the component or system to fail to Automated Teller Machine perform its required function, e.g. an incorrect statement or data definition. A defect, if encountered during execution, may cause a failure of the component or system.

Failure: Deviation of the component or system from its expected delivery, service or result.

Rapid Testing: Огляд системних випробувань.

1. Застосувати критерій входу в випробування.

• Чи складений план проведення випробувань, чи готова до роботи випробувальна система;
• Чи проведене тестування модулів і перевірка взаємодії та функціонування компонентів системи;
• Виконати перевірку на герметичність на вході.

2. Прогнати тести.

• Здійснити прогін тестів відповідно до плану проведення випробувань;
• Скласти звіти по виявленим дефектам, ввести дані, що дозволяють відслідкувати несправності;
• Провести перегляд дефектів;
• Підтвердити усунення дефектів.

3. Сформувати звіти по результатам тестування.

• Звіти про стан тестування;
• Звіти про результати тестування;
• Звіт з аналізом дефектів.

4. Застосувати критерій виходу з випробувань.

• Чи виконаний прогін усіх тестів?;
• Застосування критеріїв успішного/невдалого проходження теста;
• Застосування критеріїв неусунених дефектів;
• Провести перегляд готовності до випуску.

Rapid Testing: Проектування та реалізація тестів.

1. Використати план проведення випробувань в якості вхідних даних для проектування та розробки тестів.

• Стратегія тестування (об’єм, підхід, критерії);
• Випробувальна система (архітектура, середовище, конфігурації);
• Працезатрати на тестування і графік виконання тестових робіт.

2. Проектування тестів.

• Визначення цілей тестування;
• Визначення специфікації вхідних даних для кожного тесту;
• Визначення конфігурації засобів тестування, що використовується для прогону кожного тесту;
• Перевірити проекти тестів на повноту покриття та технічну точність.

3. Розробка тестових випадків.

• Розробити детальні методики тестування;
• Автоматизувати часто використовувані тести, а також тести, що вимагають значних затрат часу на виконання;
• Розповсюдити управління конфігурацією системи програмного забезпечення на тестові випадки;
• Визначити установку та очитку тестів з урахуванням залежностей між тестовими випадками.

4. Перегляд та налагодження тестових випадків.

• Переглянути методику тестування;
• Налагодити тестові випадки;
• Перевірити автоматизовані тести, використовуючи для цієї мети статичні та динамічні засоби.

• 

Сравнение сервисов бета тестирования мобильных приложений

Коллеги, мы решили более детально проанализировать серсисы для бета тестирования мобильный приложений. Sergii Nezdolii  уже со стороны разработчика предоставил нужные сведенья.

Критерии отбора:

• Поддержка iOS, Android (опционально WinPhone)
• Возможность автоматизации процесса загрузки новых билдов (наличие upload API, интегрируемость с CI сервисами - Jenkins)
• Удобство интерфейса самого сервиса, возможность добавления новых пользователей с разными уровнями доступа
• Стоимость
• Поддержка Crash репортов
• Аналитические данные (Загрузки, сессии, трекинг, возможность получения фидбэка от пользователей … )

Сервисы, с которыми приходилось сталкиваться:

TestFlight Beta Testing based on iTunes Connect

Сервис существовал отдельно и известен больше как TestFlightApp

Теперь же c 26 февраля cервис полностью отключен и заменен TestFlight Beta Testing внутри iTunesConnect. Таким образом Apple дает “официальную” возможность разработчикам предоставлять тестовые версии приложений. Но в то же время даже для тестовых версий приложений их нужно вручную загрузить и дождаться ревью со стороны Apple, что, в свою очередь, замедляет процесс тестирования.

Больше деталей ниже.

Платформы:

iOS и только iOS. Более того, само приложение Testflight Beta, через которое тестировщики могут получить тестовые версии, требует минимум iOS 8.0, что делает невозможным использование данного сервиса для тестирования на iOS < 8.0.

Автоматизация:

Отсутствие API для загрузки, загрузку можно сделать через стандартный  Apple Application Loader, жесткая привязка к аккаунту разработчика. Наверняка есть возможность подружить Jenkins и iTunesConnect, но скорее всего разработчикам стоит ожидать поддержки загрузки приложений посредством использования “родных” OSX Server + Xcode Bots - больше информации: Xcode Guide - Continuous Integration 

Usability:

• 1000 пользователей на 1 приложение;
• Каждая версия для “внешних” тестировщиков должна пройти ревью;
• Большое количество мануальных шагов;
• Отсутствие возможности группировки пользователей, возможность только пригласить пользователя; 
• Возможность для тестировщиков оставить отзыв о тестируемой версии приложения;
• UPD: Apple анонсировал поддержку групп пользователей: 

"Announcing TestFlight Groups

February 12, 2015

Now it’s easier than ever to manage external testers in TestFlight. Organize your testers into groups to quickly send builds, provide separate instructions on where to focus, and apply an action to several testers at once in TestFlight. "

Стоимость:

Бесплатно (для зарегистрированных разработчиков).

Crash:

Стандартная поддержка Crash репортов от iTunes Connect, оставляет желать лучшего. Отсутствие уведомлений о новых Crash репортах, отсутствие детальной информации о условиях возникновения креша не дают возможности разработчикам быстро и эффективно отреагировать на ситуацию. Больше информации о поддержке Crash репортов: Apple: Improving Customer Experiences.

Analytics:

iTunesConnect Sales & Trends предоставляют информации о количестве скачиваний и апдейтов приложений, а также данные о платформе (iPhone/iPad) и территории.

Вывод: 

В целом Testflight сервис после покупки его Apple трансформировался в проприетарный сервис Apple с невозможностью автоматизации процесса. Сейчас он больше похож на Beta App Store с тем же процессом review, но ограниченным количеством пользователей. Сервис больше подойдет для закрытого бета тестирования финальных версий приложения непосредственно перед релизом, но никак не для Continuous Delivery.

Android Alpha/Beta testing via Play Market

Официальный способ публикации  Alpha/Beta версий приложения от Google. 

Платформы:

Android

Автоматизация:

Отсутствует. APK файл нужно загружать вручную. Процесс ревью отсутствует. 

Usability:

Возможность создания закрытых групп alpha/beta тестировщиков посредством  Google Groups. Не более. При этом тестировщики не могут оставить фидбек 

Стоимость:

Бесплатно (не учитывая стандартной оплаты Android разработчика).

Crash:

Через стандартную Google Play Developer Console.

Analytics:

Через стандартную Google Play Developer Console.

Вывод:

Как и TestFlight Beta, данный сервис больше подойдет для закрытого бета тестирования финальных версий приложения непосредственно перед релизом, но никак не для Continuous Delivery.

TestFairy

Данный сервис сам по себе является интересным тем, что предоставляет возможность записывать видео сессий тестирования. До недавнего времени поддерживал только Android платформу, после новостей о закрытии TestFlight заявил о поддержке в том числе и iOS. 

Платформы:

Android, iOS.

В iOS легко интегрируется через Cocoapods.

Автоматизация:

Есть поддержка upload API, для Android в том числе есть простой в использовании Gradle Plugin. К тому же относительно недавно появился Jenkins plugin, на который тоже стоит обратить внимание.

Usability:

Сервис предоставляет возможность создавать группы пользователей, просматривать статистику загрузок, сессий и другой аналитической информации. Хорошая альтернатива бывшему TestFlight, тем более с поддержкой iOS. Существует приложение для Android и web приложение для iOS, система уведомлений пользователей о новых билдах. С iOS интеграцией пока еще не все четко описано и непонятно, каким образом можно администрировать пользовательские девайсы, если есть необходимость обновить Ad Hoc профайлы для iOS. К тому же тестировщики могут предоставлять фидбек, который будет доступен на Web Dashboard сервиса (только для оунеров).

Стоимость:

Есть возможность бесплатного использования, с ограничениями в 2 приложения, 1 администратора и 1000 тестировщиков. Для “попробовать” такого вполне достаточно. Затем же при необходимости увеличить количество приложений до 25, включить возможность нескольких администраторов и получить другие плюшки, придется платить $499 в месяц.

Crash:

Есть поддержка Crash репортов для обеих поддерживаемых платформ. Репорты отсылаются автоматически без вмешательства/согласия пользователя.  Плюс к тому же сервис предоставляет возможность просмотра стандартных логов iOS NSLog и Android Logcat.

Analytics:

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

Вывод:

Данный сервис отличается от других возможностью записывать видео сессий тестирования. Легкость интеграции, добавления новых пользователей и распространения iOS и Android приложений тоже делают сервис привлекательным. В то же время цена подписки на месяц является достаточно высокой, если сравнивать с другими сервисами. Для записи видео сессий тестирования существуют альтернативные сервисы, к примеру Lookback, пока что в стадии Beta, пока что для iOS.

HockeyApp

Из интересного: недавно был куплен Microsoft.

"HockeyApp is the best way to collect live crash reports, get feedback from your users, distribute your betas and analyze your test coverage. It was launched to the public in May 2011. Before this, we had already developed HockeyKit , QuincyKit, and MacDevCrashReports , which was the first ever crash reporting solution for iOS and Mac developers. Find out more about our team members below."

Особенностью является поддержка не только Ad-Hoc, но и Enterprise для iOS. 

Платформы:

iOS,  интеграция через Cocoapods, поддержка Ad-Hoc, Enterprise

Android, Windows Phone, OS X, Windows 

Больше информации о интеграции.

Автоматизация:

Для Android существует Gradle plugin.

Для iOS и других платформ можно воспользоваться Public API.

Для Jenkins существует отдельный Hockeyapp+Plugin.

Кроме того, существует множество других дополнительных инструментов.

Usability:

Web интерфейс предоставляет полный контроль над пользователями, приложениями, настройками уведомлений и пр.:

• Возможность создавать команды пользователей;
• Возможность создавать тэги для приложений, пользователей;
• Возможность конфигурировать частоту и условия уведомлений;
• Несколько ролей пользователей (Owner, Developer, Tester) с различным уровнем доступа;
• Администрирование API ключей, используемых для CI, загрузки приложений;
• Уведомления о новой версии внутри приложения 

Есть возможность добавить опцию Фидбека в сами приложения, чтобы тестируете могли оставить отзывы. Отзывы доступны на веб дашборде.

При расширенной интеграции с приложениями возможна сегментация пользователей. 

Стоимость:

Пробный период на месяц без ограничений.

После этого доступны несколько тарифных планов, как бизнес(начиная с $30 за месяц), так и персональных (начиная с $10 за месяц)

Планы отличаются в-основном количеством приложений (для бизнес планов еще и количеством оунеров).

Количество разработчиков, тестировщиков и членов команды неограниченное для всех планов.

Crash:

HockeyApp предоставляет автоматическую группировку похожих краш репортов по названиях классов, методов, номерам строк для  iOS, Mac, и Android приложений. Более того, есть возможность включать/отключать отлавливание краш репортов. Плюс, если оно включено, и приложение упало, при следующем запуске приложение предложит пользователю отослать краш репорт.

Analytics:

Для каждого приложения и билда в отдельности присутствует аналитика с данными по:

• Количеству установок;
• Типу девайсов;
• Версии ОС;
• Количеству крашей;
• Времени использования приложения;

Периодически добавляются новые метрики. Для некоторых есть возможность представления в виде диаграмм. 

Вывод:

Данный сервис легко интегрируется и конфигурируется, поддерживает CI.

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

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

К тому же данный сервис покрывает максимальное количество платформ.

HockeyKit

Платформы:

iOS - Ad-Hoc только. Недавно была включена поддержка клиентов для Андроид.

Автоматизация:

Wiki по автоматизации и интеграции с iOS давно не обновлялась. С учетом больших изменений build tools в последних версиях Xcode возможно придется разбираться с iOS клиентом с нуля.

Для Android информация посвежее, интеграция происходит через Gradle. 

На стороне сервера есть uploadAPI, опять же может быть устаревший.

Usability:

Поддерживает:

• OTA установка приложений;
• In-app обновления;
• Несколько приложений одновременно;
• Администрация команд;
• Статистика по установкам приложений.

Стоимость:

Бесплатный.

Crash:

Не поддерживает.

Analytics:

Изначально - статистика по установкам. Все остальное - на плечах разработчиков.

Вывод:

Open Source продукт, среду для которого придется устанавливать и настраивать самостоятельно. Сам проект достаточно давно не обновлялся, потому возможно не будет работать из коробки.

Crashlytics aka Fabric

Изначально данный сервис позиционировался для сбора краш репортов.

Недавно был анонсирован новый сервис Fabric, который агрегирует в себе: 

• Crashlytics как сервис для сбора и анализа краш репортов
• Beta by Crashlytics как сервис распространения тестовых версий приложений
• Digits - сервис простого и быстрого signup
• Answers - сервис аналитики
• Mopub - сервис монетизации

Платформы:

iOS - интеграция через IDE плагин + SDK.

Android - интеграция через IDE plugin, gradle plugin, SDK

Автоматизация:

Crashlytics предоставляет универсальный upload API, который можно использовать для загрузки билдов. Более того, gradle плагин для Android Studio добавляет таски автоматической загрузки билдов. Плюс, Crashlytics умеет интегрироваться с наиболее популярными third-party сервисами.

Usability:

Сервис обладает дружественным пользовательским интерфейсом. 

Абсолютно вся информация (статистика, аналитические данные) показывается в виде графиков и диаграм, которые обновляются в режиме реального времени.  Лучшего представления и визуализации информации я не видел ни в одном другом сервисе. Гибкая система нотификаций позволяет настроить их таким образом, чтобы разработчик/менеджер/тестировщик был всегда в курсе именно той информации, которая ему нужна. Большая база FAQ в разделе Support позволяет быстро найти ответы на большинство вопросов.

Стоимость:

Буквально недавно слоганом на странице парусника был: Free for most. Enterprise features on demand. Сейчас же : Free for everybody! Enterprise features for all.

Crash:

Предоставляет real-time статистику по количеству крашей, приоритизирует наиболее частые краши, предоставляет данные о количестве пользователей, у которых возникли проблемы, позволяет изменять статус крашей, закрывая нерелевантный или исправленные. 

Информация по каждому крешу аккумулируется, показывается информация по:

•  Девайсам;
•  Версии ОС; 
•  Jailbroken;
•  Количество свободного места на момент краша;
•  Количество свободной памяти на момент краша;
•  Было ли приложение активным на момент краша;
•  График по дням, предоставляющий информацию о количестве крашей на каждый день.

Analytics:

• Активные пользователи за день;
• Новые пользователи за день;
• Активные пользователи за месяц;
• Пользователи без крашей;
• Сессии;
• Длинна сессий;
• Real-time pulse активных в данный моменты пользователей;
• Сборки;
• Активные девайсы за день;
• Активные пользователи по ОС за день;

Вывод:

Crashlytics (aka Fabric) изначально позиционировался как сервис дела анализа краша репортов, но добавление таких сервисов, как Beta, Answers, а также наличие API для автоматической загрузки новых билдов позволяют использовать этот сервис в качестве Continuous Delivery сервиса. 

Real-time анализ краш репортов и аналитические данные позволяют использовать сервис в качестве инструмента визуализации как внутри команды, так и для клиентов, предоставляя актуальную информацию о количестве пользователей, сегментах девайсов и ОС. 

К тому же многих может привлечь бесплатность данного сервиса. 

На данный момент HockeyKit распространяется как Open Source, включает 2 компонента: обязательный сервер на PHP5 и опциональный клиент. Сервер не требует БД, работает напрямую с файловой системой.

До новых встреч! Stay tuned!

@ Sergii Nezdolii