«

»

Сен 21

Кейс: Бедная Вера

http://sgolem.deviantart.com/art/Bubbles-207090586

Мне понравился опыт с публичным решением кейса Менеджер Самоделкин, кстати, появился ещё один интересный и весьма толковый ответ. 🙂
И я решил повторить. К сожалению в пятницу интернет подвел, поэтому публикую новый кейс сегодня.

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

Вводная.
В молодой, но чертовски перспективной продуктовой компании работа идет своим чередом вот уже год. Уже три месяца в команде из 10 человек работает опытная тестировщица Вера, которая для компании стала первым специалистом по тестированию. Когда её нанимали, директор Евстигней сказал: «Я доверяю Вам, вашему опыту и Вашим рекомендациям. Используйте то, что посчитаете нужным для тестирования. Я хочу, чтобы менеджер проекта мог ответить на мой вопрос: «Мы можем отдавать пользователям версию продукта?»,  я читал, что тестировщики в этом могут помочь».
замечательный директор (прим. автора поста).

Компания выпускает релизы каждые два месяц. Методология разработки: «Как получится, но мы слышали что-то про SCRUM и Agile вообще.»

Ситуация.
Дела у Веры идут замечательно, она пишет тесты, выполняет их. Команда любит Веру, тестировщица всегда приветлива, не грузит их глупыми UI багами, только хардкор, только exception(ы), только серьезные баги. Отчеты менеджеру проекта предоставляются. По итогам месяца работы было решено, что работа Веры полезна для компании.

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

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

  • Импорт данных в программу;
  • Оптимизация нескольких запросов к БД для уменьшения времени отклика сервера;
  • Новая форма логина в приложение.

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

И вот настала пора релиза.

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

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

Вопросы:

  • Какие здесь есть проблемы?
  • Когда эти проблемы были упущены?
  • Что и какие действия могут помочь  в данной ситуации?

С интересом жду ваших вариантов ответов.

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Яндекс

8 комментариев

Перейти полю для комментария

  1. Alexander

    Почему рассказы подобного рода не заканчиваются фразой «И его/ее уволили»?

    1. BarbaricQA

      Потому что не увольняют, видимо.

  2. dzhariy

    У меня к кейсу несколько вопросов:

    При чем тут автоматизация проверок?
    Было ли проведено регрессионное тестирование, или тестировался только новый функционал?
    Это реальная история, или выдумка?

    1. BarbaricQA

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

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

      2. Регрессионное тестирование выполнялось автоматизацией и в ручную, автоматизирована была часть success сценариев. Ручная проверка была только уровня smoke. Почему был выбран такой подход — не знаю.

  3. dzhariy

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

    Тут главное – вынести правильные уроки:

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

    http://www.infoq.com/presentations/narrow-test-java-ruby

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

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

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

    3. И если говорить об автоматизации – то автоматизация – это не только кликать по ссылкам на веб-странице. Очень хорошо работает практика создания собственных инструментов. Сейчас почти на каждом интервью, тестировщика спрашивают о знаниях SQL, в надежде на то, что если знает – то может быть, когда-нибудь будет использовать. Почему бы Вере, не написать вначале несколько полезных SQL запросов, которые бы проверяли внутренности базы данных, в результате, например, импорта. А потом бы не обвернуть эти запросы в программный код, создав инструмент, который бы импортировал данные и проверял результат в базе? Это на самом деле, делается проще, чем звучит. Особенно при достаточном уровне мотивации и любопытства.

    И отвечая на вопросы.

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

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

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

    1. BarbaricQA

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

  4. Анастасия Мокроусова

    Хм, данных вводных маловато…На основе имеющегося, я дала бы такие общие советы:

    1. Возможно Вера поспешила или не совсем удачно автоматизировала регрессионное тестирование.

    2. Вере стоит обратить внимание и на UI (на основе жалоб пользователей (use stories, use case) + представить себя в роли пользователя рядового + посмотреть или разработать свои основные подходящие к их ПО guidelines).

    3. Пересмотреть принципы простановки приоритетов и критичности багов (что-то из отложенного «некритичного» оказалось важным для постоянных пользователей). Здесь — см. совет 2.

    1. BarbaricQA

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

      Да, обратить внимание на UI часть следует, особенно с учетом того, что Вера ими команду «не грузила».

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Вы можете использовать эти теги HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>