?

Log in

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:


миххон
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? В чем их роль? можно перефразировать "зачем нам куча низкоквалифицированного низкооплачиваемого сброда, который отнимает время у разработчиков и сваливает из конторы как только квалификация пересекает нулевую отметку?"
Gaperton
gaperton at 2011-06-19 14:37 (UTC) (Link)
Этот Фитнес, кстати, прикольная штука, спасибо что напомнили. Надо глянуть его еще раз.
Lost In Paradox
localstorm at 2011-06-19 14:41 (UTC) (Link)
Спасибо, нужно будет посмотреть на Fitnesse.

1) К сожалению, это так. Поэтому найти толкового QA, который построит процесс, изучит систему без доков, кого надо запнет, кого надо из бизнеса спросит и вообще предъявит реалистичный план собственных действий и скажет что конкретно и в каких количествах ему нужно -- это жуткая редкость. Я бы за такое платил больше, чем программерам. Я бы на самом деле сам бы это попробовал, если бы было адекватное предложение со стороны работодателя.

2) Это согласуется со здравым смыслом, ясно. Насчет оставим манагеров в яслях и прочего. Манагеры такие какие есть. Мне с этим жить. Манагеры сами порой не знают, как все это используется, им тоже это все передали "на держи -- теперь это твоё, а то все что-то уволились" и "вот на сдачу тебе ещё пара мелких приложух, ну мы не в курсе, что за херь, но они у нас тут в списке -- поспрошай саппорт, может они что знают".

3) Дело не в нулевой квалификации. Ищем хороших людей. Но их крайне мало. Гораздо больше людей с нулевой квалификацией, которых приходится сразу заворачивать и средний уровень очень-очень низок. К сожалению. При этом люди могут уходить по разным причинам. Это сложная бюрократическая система, не каждый сможет приспособиться.
миххон
mihhon at 2011-06-19 17:13 (UTC) (Link)
а теперт правильный ответ на вопрос а зачем нам тогда тестировщики/QA? В чем их роль?

1. любая программа содержит ошибки
2. закон распределения времени до выявления ошибки должен напоминать закон Пуассона http://swsys.ru/index.php?page=article&id=958 , http://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D1%81%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D0%9F%D1%83%D0%B0%D1%81%D1%81%D0%BE%D0%BD%D0%B0
3. так что даже полусознательно тыкая по кнопкам, тестеры выявляют некую долю дефектов (и чем лучше план тестов, тем больше они их выявят)

так что правильный ответ: они снижают персональные инвестиции манагеров в вазелин посредством увеличения корпоративных инвестиций в QA
Lost In Paradox
localstorm at 2011-06-19 17:19 (UTC) (Link)
Не факт, что игра стоит свеч, но даже если все действительно так, что чтобы натренировать их нужно аллоцировать разработчиков, потому что у них сосредоточено знание. А это значит пролонгация сроков деливери. А это значит увеличение персональных инвестиций в вазелин :)
Gaperton
gaperton at 2011-06-19 17:32 (UTC) (Link)
Пункт 2, к сожалению, ошибочен.

У ошибок разных классов сильно разное респределение времени их обнаружения, зависящее от процесса разработки.

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

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

Статья датирована 99 годом, и не ссылается на исследования Carnegie-Mellon SEI, в результате которых были экспериментально установлены упомянутые мной закономерности. Ключевые слова - PSP/TSP, Watts Humphrey.
миххон
mihhon at 2011-06-19 17:47 (UTC) (Link)
хорошо

и на что похожа кривая плотности вероятности суммарного количества выявленных ошибок от времени согласно PSP/TSP, Watts Humphrey ?

программа, как и, скажем, телевизор, представляет из себя сложную систему

количество отказов (всех типов) в партии телевизоров на единицу времени подчиняется закону Пуассона

чем должен отличаться принципиально закон распределения количества найденных ошибок в программе на единицу времени?
Gaperton
gaperton at 2011-06-19 17:53 (UTC) (Link)
> и на что похожа кривая плотности вероятности суммарного количества выявленных ошибок от времени согласно PSP/TSP, Watts Humphrey ?

Понятия не имею. Так как ответ на этот вопрос не несет практической пользы, и из него полезных выводов не делается, PSP/TSP его не рассматривает. Там вместо этого корреляции ищутся между объемом кода, количеством ошибок, и потраченным на работу временем. На основе этого строится система мониторинга и предсказания качества ПО и сроков разработки. И она работает.
миххон
mihhon at 2011-06-19 18:06 (UTC) (Link)
почему же не несёт? как раз несёт

всё тестирование внутри контор, публичное бета-тестрирование как раз является выявлением дефектов, количество которых подчиняется закону Пуассона : наибольшее количество дефектов выявляется в начале
Gaperton
gaperton at 2011-06-19 18:11 (UTC) (Link)
Ок, допустим. Тока есть нюанс - дефекты имеют неодинаковую цену исправления. Нас что на самом деле интересует - их количество, или распределение совокупных затраты на их исправление?
миххон
mihhon at 2011-06-19 18:19 (UTC) (Link)
изначально это было ответом на вопрос, заданный здесь http://gaperton.livejournal.com/60632.html?thread=1621720#t1621720 : каково обоснование существования низкоквалифицированного низкооплачиваемого QA/тестировщика?

в том, что даже полусознательно тыкая по кнопкам, он выявит большое количество дефектов

так как он "низкоквалифицированный низкооплачиваемый" , то это уже хорошо

выявление более затратных в выявлении (и исправлении) дефектов переносится на пользователя :)

либо, если есть здравый смысл у руководства, наймом более квалифицированных разработчиков и т.д.
Gaperton
gaperton at 2011-06-19 18:22 (UTC) (Link)
Да вот не факт. Случайно тыкать по кнопкам и программа может. Причем, такие программы есть. Нанять одного нормального QA и задействовать такую программу будет дешевле.
hedgeov
hedgeov at 2011-06-19 18:40 (UTC) (Link)
Очевидно природой ошибок. Отказ какого-то компонента телевизора сильно отличается от ошибки в программе хотя бы тем, что на другом телевизоре этот компонент не откажет, а программа сто пудов в этом же месте упадет.
миххон
mihhon at 2011-06-19 18:43 (UTC) (Link)
сто пудов в этом же месте упадет

неправда: вы писали многопоточный код с ошибками ? он падает в разных местах :)
hedgeov
hedgeov at 2011-06-19 18:44 (UTC) (Link)
Каюсь -- не писал. :)
Previous Entry  Next Entry