Тест на аналитическое мышление: используешь ли ты логику?

Тест на аналитическое мышление: используешь ли ты логику? Аналитика
Содержание
  1. Описание
  2. 10 вопросов для начинающего бизнес-аналитика: онлайн-тест по основам бизнес-анализа
  3. К формальным описаниям
  4. Example проект
  5. Аналитические тесты для оценки возможности достижения успеха
  6. Аргументы запуска
  7. Базовые сущности
  8. Ваши аналитические способности
  9. Глубина декомпозиции
  10. Декомпозиция
  11. Исследование программного продукта
  12. Как выглядит мой обычный день в роли тест-аналитика
  13. Логическая карта
  14. Немного истории
  15. Онлайн тест
  16. Определение классов эквивалентности (equivalence partitioning)и анализ граничных значений (boundary value analysis)
  17. Приоритезация
  18. Причина / следствие (cause/effect)
  19. Проверки списка событий
  20. Программа тренинга
  21. Пройти тест. тест на аналитическое мышление | календарь лунных дней на www.analitik-expert.ru
  22. Реальный проект
  23. Сервисы отправки событий
  24. Тест-анализ – портал tmguru
  25. Тестирование аналитики ui-тестами
  26. Тестирование аналитики вручную
  27. Тестирование путей (path testing)
  28. Заключение
  29. Отзывы
  30. Итоги

Описание

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

  • как нам протестировать эту фичу?
  • за что взяться в этом продукте?
  • что важно тестировать именно в этой итерации?
  • как нам успеть проверить всё самое важное?

Вы можете отвечать на этот вопрос с формальным документированием тестовой стратегии, а можете хранить его в голове. Вне зависимости от формата, тест-анализ и ответы на все эти вопросы – неотъемлемая часть тестирования, и на этом тренинге мы на примерах разберём все ключевые техники и инструменты тест-анализа.

10 вопросов для начинающего бизнес-аналитика: онлайн-тест по основам бизнес-анализа

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

Вам предлагается интерактивный тест для начинающих бизнес-аналитиков из 10 вопросов на знание основ профессии и простых задач, которые часто встречаются на практике. Ответы на многие из этих вопросов мы разбирали в статьях нашего блога. Подробно изучить темы, упоминаемые в тесте, вы сможете на специализированных курсах Школы прикладного бизнес-анализа.

Выбирайте из предложенных вариантов тот, который считаете верным. Правильный ответ с объяснением вы узнаете после того, как нажмете кнопку ОТПРАВИТЬ. Успехов!

Загрузка

Подчеркнем, что данный тест не претендует на звание профессионального экзамена, такого как, например, международная сертификация IIBA® по BABOK®Guide, проверить знание основных понятий которого вы можете здесь. Однако, такое небольшое упражнение поможет начинающим стажерам и студентам, которые самостоятельно проходят обучение бизнес-анализу, пытаются разобраться с огромным объемом новой информации, систематизировать ее и применить к решению практических задач. Также в помощь начинающим бизнес-аналитикам мы подготовили статью с описанием основных проблем, с которым junior-специалист может столкнуться в начале своей карьеры с комментариями BABOK®Guide и советами из личного опыта.

Для освоения профессии бизнес-аналитика под руководством опытных коллег, устранения пробелов и получения новых прикладных навыков, приходите на специализированные курсы  Школы прикладного бизнес-анализа в наш лицензированный учебный центр обучения и повышения квалификации аналитиков, менеджеров и ИТ-специалистов в Москве:

К формальным описаниям

Разные компании определяют названия должностей и обязанности на свой вкус, поэтому будет правильнее вести разговор о ролях. К сожалению, здесь мы также возвращаемся к проблеме отсутствия четких формулировок и зон ответственности. Обратимся к профессиональным стандартам (де-юре и де-факто).

1. Системный аналитик

Деятельность системного аналитика регламентирует профессиональный стандарт РФ «Системный аналитик», в соответствии с которым целью вида профессиональной деятельности является «Разработка, восстановление и сопровождение требований к программному обеспечению, продукту, средству, программно-аппаратному комплексу, автоматизированной информационной системе или автоматизированной системе управления на протяжении их жизненного цикла».

В этом же документе мы найдем упоминание следующих функций:

Таким образом, гипотеза о том, что «системный аналитик отвечает за конечные требования к системе, а бизнес-аналитик решает проблемы бизнеса», стандартом не подтверждается.

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

При этом, при разработке именно программных продуктов функции бизнес- и системного аналитика во многом совпадают. BABOK не предлагает волшебную пилюлю в споре «Бизнес-аналитик vs. Системный аналитик» – наоборот, он дает пространство для маневров («Бизнес-аналитика могут также называть [барабанная дробь] системным аналитиком»).

С BABOK солидарен и Карл Вигерс, автор книги «Профессиональная разработка требований к программному обеспечению», ставящий знак равенства между терминами «бизнес-аналитик», «системный аналитик», «инженер по требованиям» и «менеджер по требованиям».

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

3. Тест-аналитик

Целью тест-аналитика, в конечном итоге, является организация максимально эффективного (при существующих ограничениях) тестирования программного продукта. На пути к данной цели тест-аналитик:

Роль «Тест-аналитик» встречается исключительно в плоскости разработки и тестирования программного обеспечения, хотя используемые методы применимы во многих отраслях.

При этом уже не будет необходимости останавливаться на следующих вопросах:

В большинстве компаний роли бизнес- и системного аналитика объединены; обязанности тест-аналитика возложены частично на системного/бизнес-аналитика, а частично – на тест-менеджера и инженеров по тестированию. Эти роли могут быть объединены с ролью технолога, проектировщика, технического писателя и менеджера проекта – всех, кто умеет «переводить с языка бизнеса на язык программистов».

Тем не менее можно искусственно разделить границы ролей. Как и в любой профессии, пришедшей к нам с Запада, здесь допустимы различные трактовки и точки зрения (более того, на каждый аргумент в защиту той или иной позиции найдутся пять аргументов в противовес).

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

Бизнес-аналитик решает проблемы бизнеса и полностью погружен в предметную область; автоматизация и внедрение информационных систем может быть одним (но не единственным) из решений – в таком случае бизнес-аналитик или ограничивается бизнес-требованиями, или играет роль системного аналитика. Таким образом, бизнес-аналитик «ближе к бизнесу».

Системный аналитик решает проблемы бизнеса исключительно автоматизацией; при работе совместно с бизнес-аналитиком его функциональная область ограничивается принятием решений по реализации продукта. Системный аналитик «ближе к сфере технических специалистов».

Тест-аналитик – технический специалист; определяет оптимальный набор тестов и их приоритеты для того, чтобы вся важная функциональность была протестирована в текущих ограничениях (времени/бюджета); при отсутствии системного аналитика играет его роль, также может подключаться к работе на этапе формирования бизнес-требований.

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

Example проект

iOS-проект, где используется автоматизированное тестирование аналитики UI-тестами. 

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

Тест, покрывающий все эти события:

import XCTest
 
final class AnalyticsTests: TestCaseBase {
    
    private let loginScreen = LoginScreen()
    private let menuScreen = MenuScreen()
    
    // MARK: - Login
    
    func testLoginSuccess() {
        launchApp(with: AppLaunchParameters(sendMetricsToPasteboard: true))
        
        analytics.assertContains(name: "open_login_screen")
        loginScreen.login(success: true) 
        analytics.assertContains("authorization", ["success": true])
    }
    
    func testLoginFailed() {
        launchApp(with: AppLaunchParameters(sendMetricsToPasteboard: true))
        
        analytics.assertContains(name: "open_login_screen")
        loginScreen.login(success: false)
        analytics.assertContains("authorization", ["success": false])
    }
    
    // MARK: - Menu
    
    func testOpenMenu() {
        launchApp(with: AppLaunchParameters(sendMetricsToPasteboard: true))
 
        loginScreen.login(success: true)
        waitForElement(menuScreen.title)
        analytics.assertContains(name: "open_menu_screen")
    }
    
    func testMenuSelection() {
        launchApp(with: AppLaunchParameters(sendMetricsToPasteboard: true))
        
        loginScreen.login(success: true)
        waitForElement(menuScreen.title)
 
        menuScreen.profileCell.tap()        
        analytics.assertContains("menu_item_selected", ["name": "Профиль"])
        
        menuScreen.messagesCell.tap()
        analytics.assertContains("menu_item_selected", ["name": "Сообщения"])
    }
}

Аналитические тесты для оценки возможности достижения успеха

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

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

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

Аргументы запуска

Я уже упоминал такие вещи, как:

ProcessInfo.processInfo.isUITesting
ProcessInfo.processInfo.sendMetricsToPasteboard

При запуске UI-тестов на аналитику будут передаваться два аргумента: –UI-TESTING и –SEND-METRICS-TO-PASTEBOARD. Первый показывает, что приложение запущено в режиме UI-тестирования. Второй — что приложению разрешено отправлять события аналитики в буфер обмена. Чтобы получить доступ к этим аргументам, нужно написать расширение для ProcessInfo:

import Foundation
 
extension ProcessInfo {
    var isUITesting: Bool { arguments.contains("--UI-TESTING") }
    var sendMetricsToPasteboard: Bool { arguments.contains("--SEND-METRICS-TO-PASTEBOARD") }
}

Базовые сущности

Представим событие аналитики в виде следующей структуры:

public struct MetricEvent: Equatable {
 
    public let name: String    
    public let values: [String: AnyHashable]?
 
    public init(name: String, values: [String: AnyHashable]? = nil) {
        self.name = name
        self.values = values
    }
}

Структура MetricEvent будет использоваться и в коде приложения, и в коде UI-тестов. Поэтому вынесем её в отдельный модуль — MetricExampleCore. Для этого нужно создать новый Target типа Framework.

Дополнительный анализ:  Методы UX-исследований

Событие что-то должно отправлять, поэтому объявим соответствующий протокол:

import MetricExampleCore
 
/// Сервис отправки событий в аналитику
public protocol MetricService {
    
    func send(event: MetricEvent)    
}

В первой строчке импортируем модуль, в котором объявили структуру MetricEvent.

Ваши аналитические способности

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

Для последнего типа человека характерно более последовательные и взвешенные выводы и умозаключения. Аналитическое мышление подразумевает разделение большого массива информации на условные блоки. Хотите узнать свою склонность к такому умозаключению? Не пытайтесь мысленно поделить этот текст на части, а лучше пройдите тест на аналитическое мышление и получите ответ на свой вопрос.

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

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

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

Глубина декомпозиции

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

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

По клику на картинку откроется полная версия.

Как можно видеть на иллюстрации выше, для некоторых модулей достаточно деления до второго уровня (так называемая «Пакетная установка»), а для других – до четвертого (так называемая «Расширенная установка»). Случается, что для некоторых модулей хватает и одного уровня.

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

Декомпозиция

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

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

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

3. Вычленяемые подсистемы должны взаимно исключать друг друга, а в сумме – полностью характеризовать систему.Напрашивается аналогия с пазлом: если сложить подсистемы вместе, должна получиться сама система. Целостность и качество этой системы можно гарантировать только с учетом взаимодействия подсистем.

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

По клику на картинку откроется полная версия.

Исследование программного продукта

Тест на аналитическое мышление: используешь ли ты логику?

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

Как выглядит мой обычный день в роли тест-аналитика

Утром мне на почту приходит письмо от заказчика с данными для получения дистрибутива продукта и формальными требованиями к нему. Плохие новости – технического задания как такового у нас нет. Хорошие новости – представитель заказчика оказался открытым к общению молодым человеком.

Что же нам за сегодня предстоит сделать? Исходя из определения, тест-аналитик – это член команды тестирования, основная задача которого определить «ЧТО тестировать?» Для этого мне необходимо выполнить следующие действия:

Логическая карта

Сформировав предварительное представление о продукте, составляю логическую карту (интеллект-карту).

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

Подобный подход позволяет достигнуть одновременно нескольких целей.

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

Во-вторых, при детализации карты достигается разделение функций до наименьших, атомарных составляющих (собственно, выполняется декомпозиция продукта), представленное в графическом виде.

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

Существует множество инструментов для построения карт:

Все они отличаются удобством использования, набором параметров и ценой (есть и бесплатные варианты). Самым простым инструментом служит лист ватмана и фломастер, но карту в электронном виде все-таки удобнее корректировать и дополнять. Более подробно тема интеллект-карт раскрыта здесь. Замечу, что во время процесса построения карты крайне желательно получать обратную связь от заказчика.

Немного истории

Еще несколько лет назад на HR рынке мы наблюдали бум позиций менеджеров. «Сотрудник банка и страховой компании», «консультант магазина электроники», «риелтор», «ответственный за формирование требований к программному продукту» – все именовали себя менеджерами.

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

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

Пришлось проститься с надеждой на мгновенный карьерный взлет. Кто-то пошел в тестирование, кто-то – в программирование, а кто-то решил попробовать себя на позиции «Аналитик», которая на тот момент ассоциировалась только с биржей, акциями и Уолл Стрит, но при этом полностью соответствовала навыкам, полученным в университете.

Онлайн тест

Процедуру можно проводить как индивидуально так и в группе. На прохождение задания отводится 15 минут. Эта методика не допускает использование калькулятора, также при прохождении запрещены любые вспомогательные пометки на бумаге – все расчёты необходимо проводить мысленно.

Что вас ожидает в тесте:

  • Вам будет предложено 20 числовых рядов, включающих по 10 чисел.
  • Каждая строчка подразумевает некую последовательность или взаимосвязь.
  • В каждом ряду содержится пропуск с многоточием, который необходимо заполнить правильным ответом, проанализировав схему взаимодействия.

Определение классов эквивалентности (equivalence partitioning)и анализ граничных значений (boundary value analysis)

  • Если область определения параметра — диапазон каких-то упорядоченных данных, то имеет смысл выделение трёх т.н. классов эквивалентности: “слева” от диапазона (невалидные значения), “внутри” диапазона (валидные значения) и “справа” от диапазона (снова невалидные). При выделении классов нужно использовать включающие границы с целью однозначности и точности: одно и то же значение не может относиться к двум классам одновременно.

    Анализ граничных значений может быть применен к полям, записям, файлам, или к любого рода сущностям имеющим ограничения.
  • Если область определения это набор неупорядоченных данных, то всегда можно выделить как минимум два класса — валидные и невалидные значения.

    Полученное разбиение можно “дробить” дальше. Например, множество латинских букв можно разбить на два подмножества: латинница в верхнем и нижнем регистре соответственно.
Дополнительный анализ:  Профессия системного и бизнес-аналитика. ПрофГид


Пример:

Приоритезация

Тест на аналитическое мышление: используешь ли ты логику?

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

В общем случае выполнять приоритезацию можно по следующим критериям:1. Требования клиента.Требования клиента очень важны и связаны с продвижением продукта и торговой деятельностью.2.

Степень риска.Функционал, отказ которого принесет наибольшие потери, необходимо тестировать в первую очередь и наиболее тщательно.3. Сложность системы.В первую очередь следует протестировать наиболее сложные свойства.

Это поможет избежать перерасходов бюджета и времени.4. Временные ограничения.Очень важно протестировать все необходимые свойства до выхода релиза. Можно повременить со свойствами, запланированными на следующий релиз. Полезные сведения о приоритезации тестирования можно почерпнуть в докладе Натальи Руколь.

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

По клику на картинку откроется полная версия.

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

Причина / следствие (cause/effect)

Простая проверка действий и их результата. Как правило, ввод комбинаций условий (Причин) для получения ответа от системы (Следствие).
Например, вы проверяете возможность добавлять клиента, используя определённую экранную форму. Пользователю необходимо заполнить несколько полей — “Имя”, “Адрес”, “Номер Телефона” — а затем нажать кнопку “Добавить”. Это Причина.

  1. Выискиваем и связываем причины и следствия в спецификации
  2. Учитываем “невозможные” сочетания причин и следствий
  3. Составляем “таблицу решений”, где в каждом столбце указана комбинация входов и выходов, т.е. каждый столбец это готовый тестовый сценарий
  4. Приоритизируем решения.

Проверки списка событий

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

/// Проверяет наличие события с указанным именем
/// - Parameters:
///   - name: Название события
///   - count: Количество событий с указанным именем. По умолчанию равно 1.
func assertContains(
    name: String,
    count: Int = 1) {
 
    let records = extractAnalytics()
 
    XCTAssertEqual(
        records.filter { $0.name == name }.count,
        count,
        "Событие с именем (name) не найдено.")
}

В итоге получился класс AnalyticsTestBase. Посмотреть его можно на GitHub — AnalyticsTestBase.swift

Создадим класс, наследника XCTestCase, от которого будут наследоваться классы, тестирующие аналитику. Он создает класс AnalyticsTestBase для тестирования аналитики и метод launchApp, запускающий приложение.

import XCTest
class TestCaseBase: XCTestCase {
    
    var app: XCUIApplication!
    var analytics: AnalyticsTestBase!
    
    override func setUp() {
        super.setUp()
        
        app = XCUIApplication()
        analytics = AnalyticsTestBase(app: app)
    }
    
    /// Запускает приложение для UI-тестирования с указанными параметрами.
    func launchApp(with parameters: AppLaunchParameters = AppLaunchParameters()) {
        app.launchArguments = parameters.launchArguments
        app.launch()
    }
}

Метод будет принимать AppLaunchParameters (параметры запуска приложения, о которых я говорил выше).

struct AppLaunchParameters {
    
    /// Отправлять аналитику в UIPasteboard
    private let sendMetricsToPasteboard: Bool
    
    init(sendMetricsToPasteboard: Bool = false) {
        self.sendMetricsToPasteboard = sendMetricsToPasteboard
    }
    
    var launchArguments: [String] {
        var arguments = ["--UI-TESTING"]
        if sendMetricsToPasteboard {
            arguments.append("--SEND-METRICS-TO-PASTEBOARD")
        }
        return arguments
    }
}

В обычных UI-тестах приложение будет запускаться с параметрами:

AppLaunchParameters(sendMetricsToPasteboard: false)

А в UI-тестах на аналитику:

AppLaunchParameters(sendMetricsToPasteboard: true)

Теперь можно писать тесты на аналитику. Например, это тест на экран входа:

Программа тренинга

1. Введение. Исследование продукта

  • Типы, виды и цели исследования продукта
  • Цели тестирования в вашем конкретном случае
  • Инструменты: интеллект-карты, списки, диаграммы
  • Процесс исследования и источники входной информации о тестируемом продукте: как не потерять важное?

Домашнее задание: исследование тестируемого продукта в заданном формате

2. Уточнения по продукту. Классы эквивалентности, граничные значения и domain analysis

  • Разбиение на классы эквивалентности и поиск границ в разных типах значений: числа, строки, объёмы, тексты, е-mails и т.д.
  • Доменный анализ: связи классов эквивалентности в разных влияющих на тестирование параметрах
  • Приоритизация тестовых значений, выбор оптимального набора значений внутри классов и доменов

Домашнее задание: анализ классов, границ и доменов на примере 1 функции тестируемого продукта

3. Тестовая комбинаторика

  • Совмещение различных проверок в рамках одного теста
  • Комбинирование негативных проверок
  • Минимальные и максимальные варианты комбинаторики
  • Риски в выборе того или иного подхода в комбинаторике, глубина тестового покрытия, выбор подходящих вариантов

Домашнее задание: создание тестового набора на проанализированный функционал

4. Продвинутая тестовая комбинаторика

  • Разбор сложных моментов из предыдущего ДЗ
  • Комбинаторика разных подходов в комбинаторике
  • Pairwise, triplewise
  • Матрица взаимозависимостей тестовых параметров

Домашнее задание: создание тестового набора на другой функционал

5. Тестирование состояний и переходов

  • Анализ продукта на предмет различных состояний и возможных переходов
  • Выявление жизненных циклов для разных сущностей в системе
  • Диаграмма состояний и переходов

Домашнее задание: разработка диаграммы состояний и переходов

6. Продвинутое тестирование состояний и переходов

  • Диаграмма состояний и переходов с учётом циклов, ветвлений и условий
  • Матрицы возможных переходов
  • Комбинирование тестов по диаграмме состояний и переходов

Домашнее задание: разработка тестов по диаграмме состояний и переходов

7.  Таблицы решений (Decision tables)

  • Анализ бизнес-логики и условий тестируемого приложения
  • Техника создания таблиц решений
  • Комбинирование тестов на основе таблицы решений

Домашнее задание: разработка тестов с использованием таблицы решений

8.  Мозговой штурм и критическое восприятие в тест-анализе

  • Техники исследования продукта
  • Как задавать вопросы, когда непонятно, что спрашивать
  • Техники мозгового штурма

Домашнее задание: проведение мозгового штурма и поиск новых классов эквивалентности в тестируемом функционале

9. Тестирование прав доступа

  • Сбор требуемой информации по правам доступа
  • Выявление скрытых ограничений
  • Способы тест-анализа при тестировании прав доступа

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

10. Тестирование окружений и локализации

  • Риски при поддержке различных окружений
  • Разбор тестирования окружений на примере кроссбраузерного веб-тестирования
  • Приоритизация кроссбраузерных тестов

Домашнее задание: стратегия тестирования различных окружений и локализаций

11. Стратегия тестирования

  • Цели и задачи стратегии тестирования
  • Комбинирование техник тест-анализа из лекций 1-9
  • Выбор подходящих техник в зависимости от функционала и особенностей
  • Учёт взаимозависимостей в функционале и борьба с дублирующимися тестами
  • Учёт нефункционального тестирования

Домашнее задание: разработка стратегии тестирования

12. Регрессионное тестирование

  • Риски при повторном тестировании
  • Анализ влияний новых доработок на текущий функционал
  • Определение необходимого объёма регрессионного тестирования

Домашнее задание: разработка стратегии регрессионного тестирования

13. Тестирование требований

  • Критерии качества требований и спецификаций
  • Процесс тестирования недокументированных требований
  • Поиск ошибок, несоответствий и взаимоисключающих требований

Домашнее задание: проведение тестирования раздела требований

14. Документирование тестов

  • Форматы документирования (тест-кейсы, тест-сессии, тест-сценарии, чек-листы)
  • Критерии выбора подходящего формата
  • Системы ведения тестов
  • Согласование тестов с другими участниками проекта
  • Правила внедрения любого из выбранных подходов

Домашнее задание: выбор и “защита” подхода документирования тестов

15. Тестирование тестирования

  • Оценка тестового покрытия
  • Оценка эффективности тестов
  • Планирование тест-анализа, создание стратегии покрытия продукта тестами

Домашнее задание: выработка вашей стратегии к оценке тестирования и тест-анализа на проекте

16. Итоги

  • Объединение всех рассмотренных техник и процессных решений
  • Сравнение и выбор подходящих в вашем конкретном случае
  • Ответы на глобальные оставшиеся вопросы
  • Допрохождение домашних заданий
  • План по внедрению всех рассмотренных решений в вашем проекте
  • Мотивашечки

Домашнее задание: план внедрения улучшений. Светлое будущее!

Онлайн-тренинг продолжительностью 16 занятий примерно по 30 минут с практическими домашними заданиями.

Тренинг очень насыщенный, в нём много домашних работ, поэтому выделяйте достаточно незагруженный рабочий период под его прохождение!

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

Пройти тест. тест на аналитическое мышление | календарь лунных дней на www.analitik-expert.ru

Тест-на-аналитическое-мышление

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

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

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

Тест на аналитическое мышление: используешь ли ты логику?

Рекомендуем также обязательно ознакомиться с расчетами:

Расчет Числа ПутиПерейти на страницу расчета Числа Пути → → →

Расчет числа СудьбыПерейти на страницу Расчет числа Судьбы → → →

Расчет Числа СердцаПерейти на страницу расчета Числа Сердца → → →

Расчет Числа ИндивидуальностиПерейти на страницу расчета Числа Индивидуальности → → →

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

Дополнительный анализ:  Тест-аналитики – кто это? — Лаборатория Качества

Разместите на вашем сайте один или несколько наших информеров. Для их просмотра перейдите по ссылкам:
Лунные информеры горизонтальные
Информер расчета совместимости по биоритмам
Информер расчёта индекса массы тела
Информер расчёта восхода и захода солнца
Информер-тест Расчёта суточных биоритмов человека

А может вас заинтересуют такие информеры?

Вертикальный
лунный информер

Информер
расчёта биоритмов

Информер
Тестов на здоровье

Взято с сайта: Календарь лунных дней: фазы луны и биологические ритмы

Просмотров: 33773

Реальный проект

Пример UI-тестов на аналитику экрана авторизации из реального проекта — LoginAnalyticsTests.swift

Пример, как мне, разработчику, помогли UI-тесты на аналитику. На одном проекте нужно было произвести рефакторинг и редизайн главного экрана приложения. Экран был сложным, с большим количеством событий аналитики. На тот момент в проекте я уже настроил тесты.

Сервисы отправки событий

Этому протоколу будут соответствовать классы, отправляющие события куда-либо. К примеру, класс для отправки событий в AppMetrica:

import Foundation
import MetricExampleCore
import YandexMobileMetrica
 
open class AppMetricaService: MetricService {
 
    public init(configuration: YMMYandexMetricaConfiguration) {
        YMMYandexMetrica.activate(with: configuration)
    }
 
    open func send(event: MetricEvent) {
        YMMYandexMetrica.reportEvent(event.name, parameters: event.values, onFailure: nil)
    }
}

В нашем случае нужен класс, который отправляет события в буфер обмена. Создаем его:

import Foundation
import MetricExampleCore
import UIKit
 
final class MetricServiceForUITests: MetricService {
 
    // Массив всех отправленных событий аналитики
    private var metricEvents: [MetricEvent] = []
 
    func send(event: MetricEvent) {
        guard ProcessInfo.processInfo.isUITesting,
              ProcessInfo.processInfo.sendMetricsToPasteboard else {
            return
        }
        
        if UIPasteboard.general.string == nil ||
           UIPasteboard.general.string?.isEmpty == true {
            metricEvents = []
        }
 
        metricEvents.append(event)
 
        if let metricsString = try? encodeMetricEvents(metricEvents) {
            UIPasteboard.general.string = metricsString
        }
    }
 
    private func encodeMetricEvents(_ events: [MetricEvent]) throws -> String {
        let arrayOfEvents: [NSDictionary] = events.map { $0.asJSONObject }
        let data = try JSONSerialization.data(withJSONObject: arrayOfEvents)
        return String(decoding: data, as: UTF8.self)
    }
}

В методе send можно проверить, что приложение запущено в режиме UI-тестирования и разрешена отправка событий в буфер обмена. Затем в массив всех отправленных событий добавляется новое. 

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

// MetricEvent.swift
...
    /// Представляет событие в виде словаря для передачи в JSONSerialization.data(withJSONObject:)
    public var asJSONObject: NSDictionary {
        return [
            "name": name,
            "values": values ?? [:]
        ]
    }
...

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

final class LoginViewController: UIViewController {
    
    private let metricService: MetricService
    
    init(metricService: MetricService = ServiceLayer.shared.metricService) {
        self.metricService = metricService
        super.init(nibName: nil, bundle: nil)
    }
    ...

Чтобы не передавать каждый раз вручную эту зависимость, можно использовать паттерн Service Locator и создать класс ServiceLayer. В нем будет создаваться и храниться MetricService, который будет передаваться во все контроллеры.

import Foundation
import YandexMobileMetrica
 
final class ServiceLayer {
    
    static let shared = ServiceLayer()
    
    private(set) lazy var metricService: MetricService = {
        if ProcessInfo.processInfo.isUITesting {
            return MetricServiceForUITests()
        } else {
            let config = YMMYandexMetricaConfiguration(apiKey: "APP_METRICA_API_KEY")
            return AppMetricaService(configuration: config)
        }
    }()
}

Если приложение запущено в режиме UI-тестирования, то для отправки событий используется MetricServiceForUITests. В ином случае AppMetricaService.

Тест-анализ – портал tmguru

Тест-анализ определяет, что именно будет протестировано, формируя наборы условий тестирования. Финальный список наборов зависит от базиса тестирования (требований к компоненту или системе), целей тестирования и связанных с проектом рисков.

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

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

Тестирование аналитики ui-тестами

У любого события есть имя, у некоторых бывают еще и параметры. Например, у  «успешность авторизации» имя authorization и булевый параметр success.

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

На практике есть два способа передачи данных из приложения в UI-тесты:

  • Можно сохранить текстовые данные в невидимое текстовое поле или в свойство accessibilityLabel невидимой «вьюшки». Но в этом случае меняется иерархия «вьюшек», и это может привести к багам. Кроме того, не получится очистить список отправленных событий из UI-тестов.

  • Или можно сохранить текстовые данные в буфер обмена, к которому у UI-тестов есть доступ. Этот вариант лучше, так как иерархия «вьюшек» не изменяется. Буфер обмена можно очистить из UI-тестов, а еще это проще в реализации.

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

Так в итоге будет выглядеть UI-тест, проверяющий события аналитики на экране авторизации:

Тестирование аналитики вручную

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

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

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

  3. Либо события аналитики можно логировать и сразу отслеживать в консоли.

События аналитики в Console.app
События аналитики в Console.app

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

Это всё способы тестирования события аналитики вручную. Но если в приложении событий много, то такое тестирование будет не быстрым.

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

Тестирование путей (path testing)

Часто под ним имеется в виду метод тестирования белого ящика Control Flow Testing, в котором тест-кейсами покрываются все потоки и логические пути ПО. Подробнее можно прочитать здесь:

Однако, его же можно использовать для покрытия тестами логики тестируемой системы, если у нас имеются BPMN-диаграммы и UML activity-диаграммы, описывающие процессы, проходящие в ней.
Количество сценариев будет зависеть от количества логических узлов ветвлений.

Посмотреть/послушать о такого рода применении метода можно здесь

, где докладчик скомбинировал этот метод с вышеупомянутой

Заключение

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

смертного

тестировщика при получении им в тестирование продукта.

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

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

Отзывы

Елена Лисицкая, Adyax,QA Manual

Мне понравилось:

  • удобство обучения (ученик может сам планировать свое время для просмотра материала и подготовки домашнего задания.Нет привязки к определенному времени);
  • объем информации (очень много полезной информации,которую можно с успехом применять на практике);
  • доходчивое объяснение (материал был изложен достаточно подробно и понятно);
  • возможность попрактиковаться на своем проекте.

Практики даже больше было,чем теории, что несомненно является приоритетом в любом обучении.Спасибо Наталье Руколь и Юлии Мироновой за отличную работу и за то,что дали нам возможность погрузиться в огромный и необъятный мир тест-анализа!

Итоги

Плюсы подхода:

  1. Продуктовому аналитику или тестировщику не нужно проверять все события аналитики вручную. А это экономия времени и, соответственно, денег.

  2. Если у вас настроен CI, то UI-тесты на аналитику можно запускать по расписанию, например, раз в неделю или по команде из Slack.

Есть и минусы:

  1. UI-тесты выполняются относительно долго. Имеет смысл запускать их только в процессе регрессионного тестирования перед каждым релизом.

  2. UI-тесты на аналитику смогут написать только те тестировщики, которые имеют опыт написания нативных UI-тестов.

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

Поэтому в случае большого проекта есть смысл автоматизировать проверку событий аналитики. 

Оцените статью
Аналитик-эксперт
Добавить комментарий

Adblock
detector