воскресенье, 6 июля 2014 г.

А что конкретно ждет от тестирования Заказчик?

Я сейчас читаю "Закон малинового варенья", в котором напоминается простая истина - "если у вас есть только молоток, вы будете решать им все проблемы". Если мы постоянно работаем с Заказчиками, которые считают, что от тестировщиков нужны баги, много багов (N штук в день, иначе они просто балду там пинают), то мы можем начать думать, что это стандарт и любому Заказчику только такие результаты и нужны.


Я сейчас как раз рассталась с дизайнером именно из-за несоответствия наших мышлений из серии "это же очевидно!".

Одна знакомая нанимала дизайнеров и была очень ими довольна. Ей не пришлось познавать все многообразие цветов, плиток итд итп. Достаточно было сказать "мне нравится минимализм" и накидать картинок, которые ей нравились.

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

Я задала своему вопрос "Вот Вы нарисовали "тут шкафчик, там кровать таких-то размеров", а дальше что? По магазинам я буду кататься и искать эти вещи? А обои, ламинат - этого в картинках не будет, надо будет "по образу" подбирать?"

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

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

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

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

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

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

А Заказчик опять недоволен. Потому что вы не прислали ему подробный отчет о проделанном, а значит, ничего и не делали. Или прислали отчет, но краткий "протестирован модуль **, критичные ошибки исправлены, заведены доработки такие-то", а ему нужен 5-страничная официальная бумажка. Или он видит в баг-трекере всего 3 задачи и считает, что вы ничего не делали. И плевать, что еще 25 ошибок было исправлено без заведения.

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

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

Но не вам в таком случае решать, как правильно, ведь Заказчик всегда прав! Просто можно было заранее выяснить, а чего, собственно говоря, от вас ждут? Также сразу уточнить, нужна ли дополнительная бюрократия или можно обойтись без нее? В общем, обсудить все заранее или потом не жаловаться Smile :)

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

2 комментария:

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

    Значит они не критичные. Их важность была оценена неправильно.

    > А он, возможно, строит какие-то отчеты по баг-трекеру и занимается анализом возникающих проблем.

    Где таких заказчиков дают? Дайте двоих.

    ОтветитьУдалить
    Ответы
    1. Это просто примеры :)
      Хотя мы вот отчеты строим и в роли Заказчиков бывали :)

      Удалить