?

Log in

No account? Create an account
November 2016   01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
cartoon

Миф о документации, продолжение

Posted on 2011.06.18 at 23:06

Comments:


Lost In Paradox
localstorm at 2011-06-19 11:50 (UTC) (Link)
Это верно. Только количество кейсов невероятно велико. И какие из них имеет смысл проверять, а какие аналогичны по своей сути -- это сказать сложно.

Иногда, например, очевидно, что программа сломается при определенных условиях, но на практике они не возникают, а может и возникают, но свидетельств нет. В общем, только глядя на код, крайне сложно провести регресс.
Lost In Paradox
localstorm at 2011-06-19 11:59 (UTC) (Link)
Это ещё при том, что некоторые QA/QC и прочие тестеры отказываются/не способны смотреть и анализировать код.
Gaperton
gaperton at 2011-06-19 12:04 (UTC) (Link)
Если поставить цель накрыть ошибки с высоким Severity, это не так сложно. То есть:

1) Не должно быть крешей, и прочих ситуаций с полным отказом сервиса. Проверяется просто. (System Failure)
2) Не должно быть полного отказа подсистем (Feature Failure).

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

Далее, составляем фичлист (это проще, чем анализировать сценарии и юзкейсы), и делим фичи на три класса - Critical, Important, и все остальные.

Для Critical-фич ловим уже Feature Impairment, вдаваясь в логику, или же тупо сверяя результат (промежуточные данные) с предыдущей версией.

Еще добавляем правило, что для каких-то классов ошибок программистом пишется юнит тест, проверяющий, что их нет. Он добавляется в регрессию. Это нас спасает от повторных ошибок.

Остается сгенерировать покрытие. Здесь надо творческий подход применить.

Затратно, но не особо сложно, и должно окупиться.
Lost In Paradox
localstorm at 2011-06-19 12:12 (UTC) (Link)
Да, это умно. Надо мне подумать об этом, авось смогу что-то в этом мире изменить.

Как кстати считаешь, QA должны уметь читать код? Я считаю, что для эффективной работы это необходимо. Не могу я быть их глазами все время.
Gaperton
gaperton at 2011-06-19 12:23 (UTC) (Link)
> Как кстати считаешь, QA должны уметь читать код? Я считаю, что для эффективной работы это необходимо. Не могу я быть их глазами все время.

От области зависит, я думаю. В общем случае - я бы предпочел, чтобы они в проблемах, решаемых софтиной получше разбирались, в предметной области, предназначении программы, и в вопросах юзабилити. И умели составлять программы и методики испытаний.
Gaperton
gaperton at 2011-06-19 12:28 (UTC) (Link)
> Да, это умно. Надо мне подумать об этом, авось смогу что-то в этом мире изменить.

Единственный реально работающий способ сделать что-то быстрее и/или дешевле - не делать лишней работы ;)
Lost In Paradox
localstorm at 2011-06-19 12:31 (UTC) (Link)
Это-то понятно. Просто у меня есть на проекте пригоршня QA, пользы от которых я до сих пор не ощутил, как Dev Lead. А хочется. Зря что ли мы им платим? А если не получится получить пользу, то разогнать их нахрен всех.
Gaperton
gaperton at 2011-06-19 12:34 (UTC) (Link)
Либо придумать, как изменить их подход к работе, чтобы от них была польза.

Например, их обязанности можно попробовать "склеить" с технической поддержкой. Это неплохое сочетание.
Lost In Paradox
localstorm at 2011-06-19 12:36 (UTC) (Link)
Знаю, такой опыт есть. Пока не получается, ибо смотреть в код не хотят. А зачастую -- это единственный способ ответить на вопрос "почему".
Gaperton
gaperton at 2011-06-19 12:44 (UTC) (Link)
В таких случаях техподдержка открывает на разработку в трекере тикет типа "исследование" или "вопрос", который связан с тикетом, соответствующим вопросу пользователя. В котором внятно формулирует вопрос. Не надо ей уметь код читать.

Использование трекера радикально упрощает горизонтальное взаимодействие разных команд.
Gaperton
gaperton at 2011-06-19 12:49 (UTC) (Link)
Такая практика, вообще, нормальна. У поддержки должно быть несколько уровней. Смысл первого уровня в том, чтобы фильтровать простые и типовые вопросы. Смысл последнего уровня - разбирать совсем ацкие вещи, которые никто не смог решить, обычно это лучшие разработчики или архитектора.

Если какой-то уровень не в состоянии обработать запрос - он запрашивает следующий уровень.

К примеру, наша техподдержка первой линии не умеет читать код, что не мешает ей обрабатывать 75-80% всех обращений пользователей самостоятельно.
Lost In Paradox
localstorm at 2011-06-19 12:53 (UTC) (Link)
Да, это понятно. Но это идеал. Куда как проще свалить все на разработчика. И если нет инициативы со стороны самой команды саппорта в том, чтобы действительно прошарить и приносить пользу, то сдвинуть ситуацию с мертвой точки со стороны разработчиков бывает трудно.

Если же перед третьим уровнем саппорта (собственно девелоперы), воткнуть ещё QA, то либо они действительно должны делать классно эту работу, либо к разработчику будет приходить проблема за проблемой, а время ответа пользователю увеличится. Потому что на каждом уровне есть свой пайплайн, свои приоритеты, свои нехватки по ресурсам.
Lost In Paradox
localstorm at 2011-06-19 12:49 (UTC) (Link)
Теоретически -- все так. На практике у меня есть две саппорт команды первого и второго уровня, которые сами практически ничего не делают, кроме эскалации до девелопмента. Это при том, что мы им написали очень подробное руководство по эксплуатации, написали как исследовать логи, написали FAQ, написали примеры алёртов и что они значат... Но вот хрен бы там, часто все равно проваливается на нас то, что они сами могут делать.

Это просто в качестве иллюстрации, что саппорт -- это тоже нетривиально и просто так каких-то людей на него не посадишь. В т.ч. QA. Как, например, они будут работать под давлением со стороны бизнеса, мне не очень понятно.
Gaperton
gaperton at 2011-06-19 12:57 (UTC) (Link)
> На практике у меня есть две саппорт команды первого и второго уровня, которые сами практически ничего не делают, кроме эскалации до девелопмента.

Они не консультируют пользователя по непонятным вопросам?

Они не пытаются воспроизводить ошибки, которые появились у пользователя, чтобы их локализовать, и не задают пользователю допвопросов?

Они не умеют отличать Severity, и прописывать его в переданную ошибку?

Они не тестируют исправления ошибок и доработки, которые они передали в разработку?

Они не сообщают пользователю, что все ок, и он может проверять?

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

Если делают - то это уже немало, на самом деле.

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

Ну так можно на это посмотреть. :)
Gaperton
gaperton at 2011-06-19 12:06 (UTC) (Link)
Даже если в минимально степени реализовать приведенную программу - станет гораздо лучше, чем совсем без регрессии.
Previous Entry  Next Entry