?

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:41 (UTC) (Link)
>Которых очень затратно в этом случае обучать - чтобы составить регрессионный тестплан, придется провести ревизию всех сценариев использования системы

Самое обидное, что это порой крайне трудная задача, особенно, если это не user-facing компонент, и отвечает он за какую-нибудь интеграцию двух больших систем, которыми пользуются разные бизнес-линии.

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

В качестве примера можно привести некое мое приложение, с которым я уже полгода работаю и вот совершенно недавно вылезли совершенно новые люди, которых мы импактнули своим релизом. Посмотрел по иерархии в компании-клиенте -- это совершенно параллельный мир, они даже не знакомы с другими пользователями системы, которые тоже активно изменения в ней заказывают.
Gaperton
gaperton at 2011-06-19 11:45 (UTC) (Link)
> Самое обидное, что это порой крайне трудная задача, особенно, если это не user-facing компонент, и отвечает он за какую-нибудь интеграцию двух больших систем, которыми пользуются разные бизнес-линии.

Но это для регрессионного теста в общем случае не обязательно.

Для регрессии достаточно проверить, что поведение бизнес-логики не изменилось (там, где не должно было), а вовсе не то, что она вся "правильная". Это очень большая практическая разница, которую можно творчески использовать в автоматической регрессии.
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:06 (UTC) (Link)
Даже если в минимально степени реализовать приведенную программу - станет гораздо лучше, чем совсем без регрессии.
миххон
mihhon at 2011-06-19 13:21 (UTC) (Link)
не user-facing компонент, и отвечает он за какую-нибудь интеграцию двух больших систем описывается автоматическим тестом, который прогоняется вместе со всеми тестами перед коммитом
Lost In Paradox
localstorm at 2011-06-19 13:26 (UTC) (Link)
Ага. Это очень грамотное замечание, только вот оно описывает конечное состояние внедренного автоматизированного тестирования, которого в наличии пока нет.
миххон
mihhon at 2011-06-19 14:01 (UTC) (Link)
а кто, по вашему мнению, должен писать такой тест: разработчик, тестер, QA ?

и как он должен быть написан: 1) на том же языке программиррования, что и софт, 2) на утилите, используемой QA типа Fitnesse
Lost In Paradox
localstorm at 2011-06-19 14:12 (UTC) (Link)
Это вопрос, который не имеет универсального ответа.

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

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

Тест могут сообща в определенные сроки написать разработчики, но нужно понимать, что это означает чем-то пожертвовать в плане разработки. Понятно, что может быть это потом окупится и т.п., но даже если так, то опять-таки будет вопрос: а зачем нам тогда тестировщики/QA? В чем их роль?

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

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

Приходит "крутой QA/тестер (да хоть как назови)", говорит: "вот я вам тут через полгода нафигачу крутой процесс, все будет автоматически". А на деле полгода он делает что-то, что сложно предъявить в качестве результата (либо этот результат неотделим от самого QA, то бишь без автора оно не работает), изучает тулы и т.п. а потом увольняется и переходит в другую компанию. А мы в результате как были в дерьме, так и остались.
миххон
mihhon at 2011-06-19 14:29 (UTC) (Link)
я наслышан/что-то сам видел по Fitnesse : один программер пишет хуки и 15 непрограммеров пишут сценарии, это реально работает

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

1. в QA, тестеров, сапорт набирают тех, кто дешёв и не умеет программировать, иначе бы они пошли работать программерами, что оплачивается лучше

2. проще всего подобные тесты писать на том же языке, что и софт, т.е. быстрее всего и качественнее всего их напишет программер. на это не требуется уйма времени: на первый тест требуется 2-5 дней, на следующие 50 ещё столько же. Аргументы типа "программер не знает/не должен знать того, как используется софт" оставляем манагерам, только вчера закончившим ясли

3. вопрос: а зачем нам тогда тестировщики/QA? В чем их роль? можно перефразировать "зачем нам куча низкоквалифицированного низкооплачиваемого сброда, который отнимает время у разработчиков и сваливает из конторы как только квалификация пересекает нулевую отметку?"
Previous Entry  Next Entry