?

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 05:27 (UTC) (Link)
Кстати, вот ещё интересный вопрос. Да, все изложенное о документации соответствует действительности. Вот что тогда интересно:

Вот есть скажем какая-то система. Ну она там жила своей жизнью, предположим есть какая-то документация типа такой:

1) Где развернута система (live, test, preprod окружения)
2) Что в целом делает система (очень вверхнеуровнево)
3) Какие-то контакты пользователей или разработчиков других систем, связанный с нашей.

И это ещё очень хорошо, если такая документация есть. Ну есть комменты к коммитам, хотя не все из того, что накоммичено ушло в релиз, но это как-то было обговорено.

Ну и потом какой-то хрен с горы решает передать эту систему на саппорт и развитие ну скажем в другую компанию.

Окей. В другой компании получают это шикарное наследство и начинают постепенно осваиваться. Делают сперва какие-нибудь мелкие фиксы при почти полном отсутствии опыта с этой системой...

Потом клиент говорит: что-то релизы какие-то с багами у вас. Давайте наймем тестеров. Внимание вопрос: это вообще сработает? Что это должны быть за люди, которые подхватят этот софт, поймут его, разработают процедуры приемки и в итоге _повысят_ качество релизов, а не просто будут просто всем трахать мозг, говоря, что для работы им не хватает того, этого, пятого-десятого и вообще что за хуйня, как мы это тестить должны? Где документация? :))
Unshaven and Drunk
rlabs at 2011-06-19 09:21 (UTC) (Link)
сработает, если а) это будут достаточно опытные тестировщики, а не QA, и б) качество релизов будут поднимать разработчики.
Lost In Paradox
localstorm at 2011-06-19 10:01 (UTC) (Link)
Объясните как вы понимаете разницу между QA и тестировщиками в таком случае.
Gaperton
gaperton at 2011-06-19 10:39 (UTC) (Link)
Одно по английски, другое - по русски :).
Unshaven and Drunk
rlabs at 2011-06-19 10:53 (UTC) (Link)
привычка путать QA и тестирование приводит к неоправданным ожиданиям, вроде того, что "у нас низкое качество - давайте наймем больше тестеров" или к перевешиванию ответственности за качество на тестировщиков.

нужно понимать, что сколько бы у вас не было тестировщиков, они не правят баги, не оптимизируют процесс, не принимают решение о выпуске. Задача тестирования - предоставить информацию о том, насколько все плохо. Задача команды - сделать, чтобы было хорошо. Задача QA - сделать, чтобы в следующий раз было лучше.
Gaperton
gaperton at 2011-06-19 11:12 (UTC) (Link)
Здесь речь идет о тестерах и QA Engineer-ах, а не о тестировании и понятии Quality Assurance.

И если человек не склонен относить Software Development Process целиком к QA, как например - я, то это, поверьте, ровным счетом ничего не значит. :) QA, тестирование - это не более чем названия. Научить их употреблять можно даже осла, понимание процесса разработки ПО у него от этого не появится.
Unshaven and Drunk
rlabs at 2011-06-19 10:44 (UTC) (Link)
прозвучит банально, но http://www.google.com/search?q=qa+vs+testing

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

Тестирование - это QC (контроль качества) плюс разведка (оценка качества). Тестировщики не управляют процессом, и напрямую не влияют на качество. У вас может быть отличная команда тестеров, и 100500 обнаруженных, но неисправленных багов.
Gaperton
gaperton at 2011-06-19 10:58 (UTC) (Link)
Разумеется они тестируют. :)
"The QA engineer is a test engineer, but he/she does more than just testing. The good QA engineer understands the entire software development process... blah-blah-blah...".

С тем же успехом можно дать поиск по "software engineering vs coding". Software Engineer не перестанет после этого быть программистом, а программист не станет кодером, который тока код пишет, и ничего вокруг не знает и не понимает.

Это если коротко. А если вдаваться в частности - то в разработке ПО предотвратить дефекты можно только применением языков программирования и тулов, которые физически не позволяют определенный класс ошибок вносить. Скажем - в Java нет адресной арифметики, и нет связанного класса ошибок. Это - предотвращение, и к QA разработка подобных средств никак не относится, по крайней мере, в терминологии, принятой в нашей индустрии и в микроэлектронике.

Во всех остальных случаях можно только стараться находить ошибки пораньше, "предотвратить" их появление невозможно.
Lost In Paradox
localstorm at 2011-06-19 11:14 (UTC) (Link)
>Теоретически, построив хороший процесс, можно вообще обойтись без тестирования как выделенной активности.

Нет, это невозможно. По крайней мере никому в этом мире ещё не удавалось.

>Тестировщики не управляют процессом, и напрямую не влияют на качество. У вас может быть отличная команда тестеров, и 100500 обнаруженных, но неисправленных багов.

Ну исправление багов -- это конечно задача разработчиков.

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

Также бессмысленно наличие только людей которые не тестируют, но точат процесс тестирования.

В этой связи нужны и те и те. Что опять-таки приводит к практическому смешению обязанностей. В этом случае более жизнеспособна форма, когда есть QA Lead, который с одной стороны может и процесс подогнуть и посмотреть как люди тестируют и им в чем-то помочь. С другой стороны есть просто QA, на которых лежит рутина по тестированию и его автоматизации.
Gaperton
gaperton at 2011-06-19 09:58 (UTC) (Link)
> Потом клиент говорит: что-то релизы какие-то с багами у вас. Давайте наймем тестеров. Внимание вопрос: это вообще сработает?

Все сильно зависит от ситуации, но высоки шансы, что либо не сработает, либо "сработает", но никому результат не понравится.

Во-первых, здесь речь идет о ручном регрессионном тесте. Один прогон такого теста - это достаточно долго. Чтобы выпустить релиз - необходимо вводить code freeze, то есть, регрессионных прогонов должно быть несколько, и новой функциональности + новых исправлений ошибок добавлять между ними нельзя.

Это приведет к тому, что периодичность выпуска релизов сильно замедлится. Заказчик это вполне осознает? Часто - нет. Особенно, если это было внутренней разработкой - он привык, что исправления появляются часто и быстро.

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

В результате, Заказчик будет, скорее всего, недоволен.

Что вовсе не означает, что нельзя ничего сделать. Я бы сказал, что в подобных ситуациях будут оправданы автоматические регрессионные тесты, которые должны писаться программистами.

Они вполне в состоянии повысить стабильность релизов до приемлемого уровня (т.е. будет заметно лучше), и при этом - не сильно замедлить цикл выпуска релиза. Ибо - автомат тестирует быстрее человека, и делает это бесплатно.

Автоматические регрессионные тесты можно навешивать и на гуй. Продвинутые QA это делать умеют.

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

В целом, это решение должно приниматься с участием руководителя QA в компании-исполнителе. С участием, но не им лично - так как вопрос качества - это комплексный вопрос, который определяется всеми звеньями процесса разработки ПО.
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)
Это верно. Только количество кейсов невероятно велико. И какие из них имеет смысл проверять, а какие аналогичны по своей сути -- это сказать сложно.

Иногда, например, очевидно, что программа сломается при определенных условиях, но на практике они не возникают, а может и возникают, но свидетельств нет. В общем, только глядя на код, крайне сложно провести регресс.
миххон
mihhon at 2011-06-19 13:21 (UTC) (Link)
не user-facing компонент, и отвечает он за какую-нибудь интеграцию двух больших систем описывается автоматическим тестом, который прогоняется вместе со всеми тестами перед коммитом
Lost In Paradox
localstorm at 2011-06-19 13:26 (UTC) (Link)
Ага. Это очень грамотное замечание, только вот оно описывает конечное состояние внедренного автоматизированного тестирования, которого в наличии пока нет.
Previous Entry  Next Entry