Работа в продуктовой компании: какие навыки нужны тестировщику

Работа в продуктовой компании: какие навыки нужны тестировщику

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

Следует отметить, что в аутсорсе обычно нанимают на конкретную работу:

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

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

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

Разработка идей для развития продукта

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

Поэтому для продуктового тестировщика важны следующие компетенции:

  1. Умение мыслить текущими целями и понимать Product Vision (на этапе запуска MVP и при работе с удержанием пользователей идеи будут принципиально отличаться);
  2. Знание продуктовых метрик и принципов по проверке гипотез;
  3. Понимание принципов и техник оценки юзабилити, в том числе готовность проводить опросы и тесты на пользователях;
  4. Навыки работы с инструментами для анализа маркетинговой и пользовательской статистики.

Развивать эти компетенции поможет общение с продакт-менеджерами, анализ метрик и статистики, изучение соответствующих инструментов и материалов.

Работа с требованиями

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

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

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

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

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

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

  1. Опыт работы в разных процессах и техническое образование, которое включало в себя семинары по формированию и управлению требованиями. Либо тренинги по бизнес-анализу или работе с требованиями;
  2. Навыки аргументации, коммуникации и умение работать с возражениями. Их можно развивать как тренингами, так и личностным ростом.

Проектирование интерфейса/UX

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

К слову, тестирование юзабилити — это базовая компетенция мануального тестировщика (если ссылаться на ISTQB сертификацию тестировщиков). Поэтому вносить предложения в прототипы и дизайн можно вполне правомерно 🙂

Базовые знания для оценки юзабилити:

  1. Общие правила оформления интерфейса, принципы юзабилити;
  2. Работа с цветом и иконографикой;
  3. Гайдлайны конкретной платформы (iOS, Android) к элементам интерфейса, технологиям;
  4. Правила оформления текста. Важна грамотность, умение преподнести информацию в текстовом формате и оценить степень ее содержательности;
  5. Интуитивно понимать и чувствовать пользователя (как использует приложение, какие ошибки может допускать), ставить себя на его место;
  6. Понимание особенностей и предпочтений по взаимодействию с приложением пользователей из разных стран.

Разработка

На этой стадии не будет отличий между продуктом и аутсорсом.

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

Тестирование

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

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

Рассмотрим несколько примеров:

Тестирование совместимости (конфигурационное)

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

И НЕверно тестировать:

  • Только на одном устройстве (это высокий риск пропущенных багов);
  • На всех устройствах подряд (это очень времязатратно);
  • На топ-девайсах из статистики (они могут быть одинаковыми по своим характеристикам и тесты бесполезны).

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

  1. Разбираться в производителях устройств, в моделях и их отличительных особенностях (вариации экранов, процессоров, графических процессоров, камер и так далее);
  2. Знать, как влияют разные версии ОС и их настройки на поведение приложения;
  3. Поддерживать актуальность своих знаний и парка устройств (девайсы и ОС выходят несколько раз в год).

Эти знания не дают в университетах, про это не говорят явно, а изучать нужно. И тут уже вопрос управления временем и своими знаниями.

Тестирование клиент-серверных приложений

Чтобы их проверять нужно знать:

  1. Что такое серверное API и как его тестировать;
  2. Особенности протокола, по которому идет взаимодействие клиента с сервером;
  3. Какие проверки делать на клиенте, какие на сервере и какие только вместе;
  4. Структуру базы данных (например, если изменяется БД, происходит миграция БД, то возникает риск критических багов);
  5. Инструменты, помогающие снифферить трафик, работать с БД (поиск и просмотр информации, наполнение тестовыми данными с помощью sql-запросов).

В аутсорсе всё это тоже важно. Однако, есть вероятность столкнуться с  сильными ограничениями со стороны заказчика (например, нет доступа к БД), распределением ответственности (серверные программисты сами тестируют API) и отсутствием возможности использовать инструменты. При работе со своим продуктом таких ограничений нет, и погруженность в каждую техническую деталь становится серьезнее и важнее с ростом продукта. Эти знания получают либо через техническое образование в университете, либо заканчивая длительные курсы уже во время работы (по серверной разработке, по базам данных и другие).

Тестирование локализации

Многие продуктовые компании рано или поздно начинают делать приложения «на весь мир». А «весь мир» —  это пользователи разных менталитетов, языков, привычек. И одно дело — проверить, что есть переводы на выбранные языки, и совсем другое — проанализировать адаптацию для пользователей из целевых стран.

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

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

Саппорт и анализ поведения пользователей после релиза

В большей степени от саппорта поступают либо пользовательские баги, либо вопросы пользователей:

  • Для поиска первопричин багов необходимы все вышеперечисленные навыки. Здесь максимальное сходство с аутсорсом.
  • Поступающие вопросы интересны с точки зрения того, в каких улучшениях нуждается аудитория. Такую же роль играют отзывы в App Store и Google Play.

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

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

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

Заключение

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

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

Первое размещение на Tproger

Путь к управлению своим временем (на личном опыте)

Задачи нарастали постепенно – вроде сначала все плавненько, приходишь, работаешь, отчитываешься руководству. А потом появляется куча коммуникаций, каждому что-то обещаешь сделать, кто-то тебе обещает и твои задачи зависят от этих обещаний. Ты сам начинаешь жить более самостоятельной жизнью – своя квартира (пусть и съемная), обязанности и ответственности (например, кредит на машину), заводишь себе кота или собаку и т.д. И всё – начинает казаться, что время исчезло из твоей жизни – у тебя куча задач – потестировать, заавтоматизировать, проверить требования, оплатить кредит, покормить кота, полить цветы….. Ты задерживаешься на работе, у тебя не хватает времени на хобби или просто отдохнуть.  Ты ничего не успеваешь.

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

Моя презентация с конференции SQA Days на тему управления временем – //drive.google.com/open?id=1xJIw81P3Yd9jia8AY6LNHcS9tV70jOa8

По пути к управлению своим временем from Vlad Orlikov on Vimeo.

Открытие 1 – Максим Дорофеев и мыслетопливо

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

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

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

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

Но с блокнотами сложность в том, что, если ты задачу не сделал сегодня, то ее нужно будет переписывать в план на завтра или когда-то еще. Задачи могут теряться. Да и сам список дел получается слишком большим и сложным со временем – что-то перечеркнуто, сложно искать нужное.

Открытие 2 – НЕ блокнот

Конечно, пришло все таки принятие того, что это должен быть не блокнот.

Сейчас очень много тулов для управления своими задачами и на самом деле, какой из них использовать личное дело каждого. Я несколько лет использовала Trello с колонками “Беклог”, “На неделю”, “Сегодня”, “Завтра”, “Сделано”, но со временем мне стало не хватать функциональности Trello и я перебралась в Todoist. Но это не значит, что эти инструменты лучшие – я знаю много людей, которым они “не зашли”. Нужно искать свой. Если не легла душа, если не понравилось, не подходит под вас, пробуйте следующий.

——

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

Я пожила таким образом какой-то период времени, но вот счастья как-то не было. Чем-то я все равно была недовольна.

Открытия 3 – колесо баланса и правило 20 минут

И здесь на одном из занятий в университете на курсе по психологии нам дают задание, которое называется “Колесо баланса”. Оно очень простое и вы можете сделать его прямо сейчас. Вам нужно нарисовать 8 осей и обозначить на них шкалу от 1 до 10. Каждая ось имеет свое название дом и семья, работа и карьера, деньги, дети, друзья, хобби, здоровье, хобби и развлечения. Названия осей вы можете взять предлагаемые  (в интернете очень много вариантов для осей), а можете заменить на свои, если есть что-то для вас более важное.

Далее нужно по каждой оси проставить значения о текущем состоянии. Например, здоровье на 5 из 10, любовь на 10 из 10. Что такое 10 решаете только вы, сами для себя.

И последнее – нужно соединить все точки между собой и посмотреть, что получилось. В идеале, должно получится колесо, чтобы оно легко “катилось” по жизни. Пусть не на 10-ку, но это должен быть круг, колесо, которое будет говорить о том, что мы сохраняем баланс между разными сферами жизнедеятельности. А вот если появляются какие-то остро или тупоугольные области, то эт не колесо и ваша жизненная карета превращается в ковыляющую телегу %) Чему-то в вашей жизни вы уделяете недостаточно внимания.

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

Тут может возникнуть вопрос про то, как успеть по всем этим направлениям.

Открытие 4 – правило 20 минут

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

Т.е. выделите всего лишь 20 минут на каждую из важных для вас сфер жизни. Пусть не каждый день, но через день-два. И это будет уже маленькая радость для вас.

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

—-

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

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

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

Открытие 5. 2х минутные задачи

Классикой в тайм-менеджменте является книга Девида Алена “Getting Things Done” (GTD). В целом, весь алгоритм сводится к тому, что изображен на слайде – идея в том, чтобы с самого начала правильно “фильтровать” все свои входящие задания – что-то делегировать, что-то в список задач, что-то в архив, что-то в список проектов на дальнейшую декомпозицию.

Но самым интересным для меня стало правило 2х минут – если задача занимает меньше двух минут, то сделать ее нужно СРАЗУ. Не надо никуда записывать, не надо раздумывать долго. Просто взять и сделать.

Например, “Исправить severity у бага” можно очень быстро. Или даже “оплатить коммунальные” в мире с интернет-банкингом можно за 2 минуты

Открытие 6. «Лягушки» на завтрак

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

Но мне понравилось, что Глеб предлагает на завтрак кушать лягушек. Лягушка – это неприятная по каким-то причинам для вас задача, это, может быть звонок, уборка, общение с кем-то и т.д. Каждый день перед основными задачами стоит заставить себя съесть одну лягушку (сделать одну неприятную задачу). Из опыта, скажу, что это дает еще легкий эффект гордости от своего поступка “наконец-то я ее сделал! я молодец!”  и воодушевление на будущие задачи.

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

Кроме лягушек у Архангельского есть еще слоны. Это большие залежавшиеся задачи. Слонов нельзя съесть целиком. Их надо разделять на более мелкие.  Дорофеев и Ален называют их проектами. Чтобы сделать большой проект, нужно каждый день делать от него по кусочку (и тут еще раз вспоминаем правило 20 минут). Слоны появляются обычно, если вы неправильно формулируете свои задачи или неправильно оцениваете свои силы.

Открытие 7. Приоритеты по Эйзенхауэру и квадрат II

И не секрет, что входящие задачи нужно оценивать по приоритетности, а не бросаться их сразу делать. И здесь самой яркой для меня классификацией приоритетов становится матрица приоритетов по Эйзенхаузену. Есть 2 оси (срочность и важность) и 4 образующих квадранта.

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

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

Третий – неважные, но срочные дела.

Четвертый – неважные и несрочные.

Если вы работаете только в I квадранте, то это очень быстрый и хороший путь к выгоранию. Увы.

Задачи неважные (третьего и четвертого) квадрантов, если вы менеджер, то можно делегировать на вашу команду – и это их точка роста для будущего.

Менеджер, лид должен работать в квадранте II – это задачи-залог его будущей эффективности.

Рассортировать/разобрать почту, выполненные задачи, пересмотреть расписание, апрувнуть баги или тесты в ЧЛ для новых фич – это ВАЖНОЕ И СРОЧНОЕ для лида команды тестировщиков!

Я тестировщик. Сижу проектирую тесты или чеклист пишу по новому функционалу, тут прилетает вопрос от ПМа на тему того, есть ли у нас такой баг. Я трачу время, нахожу ответ. Дальше приходит новый билд с этой фичей и оказывается у меня все еще не готовы кейсы. Я не могу начать работу. Некоторые в таких случаях сделают вывод о том, что никогда не успевают работать по чеклисту, и вообще, что чеклисты бесполезны. Вопрос встречный – почему вы решили, что ответить на вопрос важнее, чем подготовить тесты? Ответ “ну он же ПМ” не подходит. У каждого своя работа и свои приоритеты. Более того, большинство задач НЕ СРОЧНЫЕ, их только такими выдают.

Еще ситуация. Вы как лид сидите и метрики собираете. Ваш тестировщик проектировал тесты для фич, которые уже в разработке. Говорит, что все готово, можно проверять. Чему отдадите предпочтение – метрикам или тестам?

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

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

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

Открытие 8. Расписание

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

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

Далее практически, цитирую этот курс.

На первом шаге планирования

  • формируется список задач
  • задачи формулируются они максимально просто и конкретно, с пониманием сроков
  • при этом прогнозируются трудозатраты на каждую задачу (эстимируется время)

На втором шаге планирования

  • для каждой задачи присваивается приоритет от I до IV (лично я никогда это визуально не отображаю никак, а просто в голове подобный анализ провожу)
  • выделяются делегируемые задачи и добавляются соответствующие управленческие задачи (например, если вы даете задачу кому-топровести ревью чеклиста, то у вас должна быть задача на то, чтобы узнать результаты, возможно с кем-то обсудить, а если человек делает это первый раз, то еще и задача про пояснение того, как это делать)

На третьем шаге планирования

  • фиксируются «жесткие» дела в календаре, которые были запланированы ранее (митинги, собеседования, обучение)
  • для запланированных мероприятий дополнительно планируются подготовка и подведение итогов
  • фиксируются в календаре I и II – срочные важные и несрочные важные дела
    • слонов берем кусками! (они обычно в II)
  • и оставляется 30-40% времени для зеленых зон – это время «про запас» – не забитое задачами время в календаре.Например, совещания могут затянуться, всегда возникают какие-то дополнительные вопросы у кого-то, что-то надо перепроверить или что-то дополнительное непредвиденное сделать – вот для этих целей и нужны зеленые зоны.
    • а если вдруг задач дополнительных не будет, то вы как раз таки берете дела из квадрантов III, IV (неважные) и выполняете их.

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

Открытие 9. Энергия, эмоциональный запас сил

Составляя расписание нужно эстимировать задачи и не пытаться впихнуть невпихуемое.

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

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

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

Открытие последнее. Дисциплина.

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

  1. Каждое утро (или вечер, кому как удобно, но важно, чтобы это было регулярно) нужно  обновить список дел на сегодня (завтра):
    1. ЗАЭСТИМИРОВАТЬ!!!! По-честному, а не как хотелось бы, чтобы это было сделано.
    2. Выбрать, что сделаешь, вспоминая Эйзенхауэра, эстимейт и свою ЭНЕРГИЮ!
    3. Расставить задачи в нужной очередности и назначить время дня для их выполнения
    4. Не полениться добавить управленческие задачи по подготовке и подведению итогов (например, перед митингом подготовка, а после – результаты)
  2. Получив задачу 2х-минутную, сделать ее сразу, а если задача больше, чем на 2 минуты, НЕ БРОСАТЬСЯ за нее, а записать И выбрать ожидаемую дату выполнения
    1. Если это проект (он же слон), то задачу «Распланировать проект»
    2. Если задача делегируется, то назначить управленческие задачи
    3. Если ты занят, то не бояться отказать тому, кто отвлекает
    4. Записывать идеи в отдельный список. Идеи – это не задачи. Но быстрореализуемые идеи должны становится сразу задачами. И часто не нужно ждать никакого согласования с кем-то вышестоящим, а просто брать и реализовывать свою идею.
  3. Выполнив задачу, ОТМЕТИТЬ, что она выполнена СРАЗУ ЖЕ и взять по плану следующую (т.е. надо мониторить свой план весь день, а не как получится)
  4. Раз в пару недель «чистить» беклог задач и идей, перепланировать будущие дела

—-

Для многих подобная строгость будет казаться избыточной, некоторые будут говорить, что так, из жизни исчезает изюминка, неожиданность, все по плану и все скучно. Может быть. Я не буду этого отрицать. Но я, например, не забиваю задачами все 24 часа в сутках, я фиксирую рабочие задачи и какие-то другие проекты (такие как участие в программном коммитете конференции, организация событий в сообществе QA Club Minsk, личные дела, привязанные ко времени, типа посещения врачей, концертов, фиксирую данные кому-то обещания или полученные от кого-то и т.п.). Почти все личное время я оставляю свободным и не чувствую каких-то проблем с тем, что из жизни исчезла непредсказуемость.

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

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

Цитаты Дейкстры

Edsger_Wybe_DijkstraЭдсгер Вибе Дейкстра – голландский учёный, оказавший в середине прошлого века огромное влияние на развитие компьютерной индустрии.

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

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

  • Если отладка — процесс удаления ошибок, то программирование должно быть процессом их внесения.
  • Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации.
  • Вопрос «умеет ли компьютер думать» имеет не больше смысла, чем вопрос «умеет ли подводная лодка плавать».
  • Глубоко ошибается тот, кто думает, что изделиями программистов являются программы, которые они пишут. Программист обязан создавать заслуживающие доверия решения и представлять их в форме убедительных доводов, а текст написанной программы является лишь сопроводительным материалом, к которому эти доказательства применимы.
  • Средства не виноваты в том, что их безграмотно используют.

 

Автоматизация тестирования iOS приложений: наше маленькое исследование UI Tesing из Xcode 7

Менеджерам и тестировщикам iOS приложений, у кого в команде есть автоматизация, на заметку…
В XCode 7 инструмент для автоматизации тестирования UI Automaion был объявлен как устаревший. Он не удалён из набора инструментов… он просто устаревший. 🙂
На его замену Apple выпустила UI Testing и рассказала о нём на конференции WWDC //developer.apple.com/videos/play/wwdc2015-406/.

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

Важные мысли про UI Testing:

  • работает только на iOS 9+
  • необходим доступ к коду самого проекта, в нем создается новый Target “iOS UI Testing Bundle”
  • тесты пишутся прямо в Xcode (на Objective C или Swift). Они не попадают в сам билд приложения, а собираются в отдельный бандл (проект), который устанавливается на девайс
  • запуск тестов также происходит из Xcode. Но, похоже, можно сделать запуск и из командной строки – //krausefx.com/blog/run-xcode-7-ui-tests-from-the-command-line
  • пишут, будто UI Testing быстрее, но у нас получилось наоборот: тест, который выполнялся за 20 секунд с помощью UI Automation, UI Testing выполнял за 30 секунд.
    так же, как и для UI Automation, используются Accessibility свойства для идентификации и проверки состояния элементов UI
    в целом интерфейс написания тестов выглядит дружелюбнее, родной IDE (Xcode), код компилируется, в отличие от javascript в UI Automation, т.е. ошибки синтаксиса будут сразу выявляться
  • тесты, созданные по методу Record and Play, понятнее и выглядят более надежными
  • UIT не поддерживает комплексные жесты, такие как pinch, drag или tap по указанным координатам
  • UIA не удобный для создания тестов, но более гибкий
  • благодаря интеграции в проект приложения, сами разработчики будут иметь возможность легко запускать эти тесты.

Интересные и полезные статьи:

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

 

Будет интересно узнать, если у кого-то есть свой опыт и свои мысли по этой теме.

Исследовательское тестирование и исследовательские туры Виттакера

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

Спасибо моим коллегам, которые на себе опробовали каждый тур и дали свой фидбек! Без них, книги Виттакера “Exploratory Software Testing”  и мировой паутины не получилось бы статьи!

Введение в исследовательское тестирование

Что такое исследовательское тестирование?

Исследовательское тестирование (exploratory testing) – это одновременное изучение программного продукта, проектирование тестов и их исполнение.

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

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

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

 

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

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

Тест – это что то, что дает тебе новую информацию о программе. Один и тот же тест выполненный дважды уже нельзя назвать тестом, это уже будет скорее проверка. [Бах]

 

Когда следует применять  исследовательское тестирование?

Самые распространенные случаи:

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

Но, на самом деле, теория исследовательского тестирования 3.0 отказывается вообще от термина “исследовательское тестирование”, заявляя о нем как об избыточном и бесполезном. Исследовательское тестирование – это любое настоящее тестирование.

 

Как организовать исследовательское тестирование?

Для управления исследовательским тестированием может использоваться Session-Based Test Management. В основе этой модели лежат:

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

 

Идея туров в исследовательском тестировании

Чтобы систематизировать исследовательское тестирование можно использовать идею туров.  Туры – это идеи и инструкции по исследованию программного продукта, объединенные определённой общей темой или целью. Туры, как правило, ограничены по времени – длительность тестовой сессии не должна превышать 4 часа.

Идею туров развивали в своих работах Канер, Бах, Хендриксон, Болтон, Кохл и другие. В конце статьи есть дополнительные ссылки на их работы.

Джеймс Виттакер, хоть и не придумал саму идею туров, но предложил свой подход к исследовательскому тестированию с использованием туров и в своей книге “Exploratory Software Testing” в доступной форме озвучил идею туров и описал сами туры.

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

 

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

 

Общая карта районов приложения и туров по ним

 

 

 

Матрица по турам и типам багов, которые они находят

Матрица основана только на опыте применения в моей команде.

 

Continue reading

“Наташа, порекомендуй хорошего начинающего тестировщика”

Последнее время я чаще стала слышать вопрос “Наташа, порекомендуй хорошего начинающего тестировщика!” И моим естественным желанием является рекомендовать тех, кто закончил мои курсы. =)

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

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

  • “Рекомендация” обозначает, что лично я вижу в этом выпускнике перспективу, верю в то, что у него есть способности, возможности и ОГРОМНОЕ ЖЕЛАНИЕ стать хорошим тестировщиком.
  • “Сертификат о завершении” говорит о том, что человек успешно закончил обучение – и домашние задания и теория были выполнены на достойном уровне, сдал выпускной тест. Это хорошие выпускники, которые могут быть хорошими тестировщиками.
  • “Сертификат об участии” обозначает, что человек принимал участие в курсе, знает какие-то базовые вещи. Однако либо мало домашних выполнял, либо мало посещал, либо не сдал итоговый тест.

Если информации нужно больше, то можно обращаться ко мне лично (контакты на страничке контактов).

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

Всем добра и успехов!

 

Заметки про тайм-менеджмент

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

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

 

Но, чтобы управлять временем и чувствовать себя свободно необходима практика и дисциплина. Постоянно! Прямо сейчас!

Continue reading