Subject:

Грустная сказка о тестировщике, которая не скажу как закончилась

Issue ID #112 

Reported at 04.09.2013

Reported byNatalya Rukol

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

Severity Major 

Tags ,

Жил да был один тестировщик, и звали его не скажу как, а тестировал он сайт покупки билетов, который назывался http://censoredsite.ru.

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

Как-то раз к нему пришёл тест-менеджер, и сказал: «Нескажукак! Тебе надо писать тесты, чтобы точно описать, что именно нужно проверить, и не пропускать их».

Нескажукак был в шоке. Он хорошо выполнял свою работу, зачем ему эта лишняя бюрократия?

Тест-менеджер, далёкий от жизни нормальных тестировщиков, начал выдумывать всякие странности:

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

Нескажукак был на грани истерики: «Нам нужно работать, а не все эти ваши дурацкие тесты писать!»

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

А потом началось тестирование. Он проверял как любил, он был в потоке, баги сыпались рекой, и все были счастливы. Когда ошибки были исправлены, он ответил «ДА» на священный вопрос: он сказал «да, можно выпускать наш продукт пользователям!».

А потом был релиз. И были пользователи, которые пытались использовать censoredsite. В первый день в техподдержку обратилось 40 человек из 200 посетителей. Оказалось, что при смене адреса после сохранения, неправильно отображались реквизиты. А при вводе слишком длинного емейла, падал весь сайт. И время в одном из полей, о существовании которого Нескажукак даже не знал, отображалось не в правильной часовой зоне…

Все эти ошибки казались сущими пустяками! Но руководство было в ярости, клиенты в шоке, пользователи недовольны.

К депрессирующему Нескажукаку пришёл тест-менеджер. И открыл список тестов. И нашёл там все эти мелкие проверки, которые казались такими неважными, потому и были пропущены.

Для начала, они вместе выпили. И только после этого тестировщик смог признаться: да, поток — это хорошо. Творчество в работе — тоже. Но нужно ещё что-то!

Что?

  • Аноним

    >> Что?

    Автоматизация этих мелких проверок совместно с тестированием данных в базе!

    Потому, что:

    1. Неизвестно, когда появился этот баг и email и реквизитами. А может быть, его внесли в последний момент перед релизом?

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

    Кстати, если такие проверки считались мелко приоритетными, такими, что на них внимание даже никто не обращал, то может быть что-то не так с приоритезацией ? Ну, конечно же, как же мы можем узнать, что важно пользователю, а что нет… а можем!

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

    Ситечко, например, так делает.

    Кстати, там ошибка 404 при отправке лога. Не скажу, как воспроизвести :)

    http://i.imgur.com/ZUt0Pxd.png

  • http://adzynia.com/ Andrii Dzynia

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

  • Марина Селиванова

    По-моему, история немного о другом. Немного порядка при тестировании еще никому не мешало :)

    • pasha wizle

      +1

  • I am

    Как-то не стыкуется история.
    «Использовал шаблон, предоставленный ТМом, описывал стандартные проверки для каждого поля.
    А потом началось тестирование. Он проверял как любил, он был в потоке, баги сыпались рекой, и все были счастливы. Когда ошибки были исправлены, он ответил «ДА» на священный вопрос: он сказал «да, можно выпускать наш продукт пользователям!».»

    Почему менеджер пришел и сказал «писать тесты, чтобы не пропускать ошибки. » Ведь тесты мало написать, по ним надо пройти., т.е. провести тестирование
    Если тесты были написаны , и » там все эти мелкие проверки, которые казались такими неважными», то почему инженер не делал их, эти проверки?
    Если менеджер такой умный и прозорливый, что предлагал шаблоны и метрики, то перед релизом его устроил ответ «да, можно выпускать наш продукт пользователям!» , вместо отчета о тестировании с покрытием ? Т,е. почему менеджер не отследил, что было проверено, а что — нет, до релиза?

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

    P.S. Имхо, инженеру в этой ситуации не хватило понимания целей.

  • http://barbaricqa.com/ BarbaricQA

    Сказка закончилась: «Они поженились.» ?:-)
    Тестировщику, судя по всему, ничего не нужно, ему и так неплохо, да страдает, но неплохо живется.

  • Аноним

    Что?

    А-а-аа.. я понял!

    Чеклисты!… Риски?… Цели?… Ну что же?

  • Andrey Myasnikov

    >да, поток — это хорошо. Творчество в работе — тоже. Но нужно ещё что-то!

    >Что?

    Те-о-ри-я.

  • bаrmaglot

    Взаимопонимание?

    Если нужно одно слово, то я выберу это.

    Оно емкое, в него много всего помещается. Кроме этого оно как бы взывает к миру во всем мире, и на работе в том числе. :)

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

    … а чуть поглубже …
    > Когда ошибки были исправлены, он ответил «ДА» на священный вопрос: он сказал «да, можно выпускать наш продукт пользователям!»
    Вот это «ДА» каждый понял по своему:
    - директор решил, что раз опытный тестировщик тестировал под присмотром системно мыслящего тест-менеджера, то в продукте не осталось сколь-нибудь значительных баг. И сказал «ГОТОВО» клиентам.
    - клиенты решили, что сайт полностью готов и так понравится пользователям, что те мигом перейдут к ним от конкурентов. И дали «ДОБРО» публикации на живой.
    - а пользователи увидев, новую версию сайта, сначала были просто не очень довольны, что им сейчас придется изменять привычные способ покупки билетов. Но решив, что, в конечном счете, он должен стать более удобным, еще сильнее расстроились напоровшись пусть даже не на очень критические ошибки, и засыпали суппорт клиента своими жалобами.

    и покатилась волна недовольства назад …

    А тестировщик, своим «ДА», скорее всего хотел сказать что: «Да, я проделал большую работу, нашел кучу ошибок, и они поправлены. Я думаю, там могли, конечно, остаться незначительные проблемы, но, мне кажется, они особо никого не потревожат».

    (Кстати, а где был в это время тест-менеджер? Или это секрет?)

    ——————————

    Поэтому тестировщику обычно не рекомендуют отвечать на вопрос «можно выпускать наш продукт пользователям?» столь односложно.

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

    Именно для более четкого ответа на этот вопрос и нужны все эти тест-менеджерские прибамбасы.

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

    PS: Правда, это нифига не застрахует нас от недовольства некоторых пользователей. ;)

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

  • Pingback: pengacara jakarta

Social Widgets powered by AB-WebLog.com.