?

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 04:55 (UTC) (Link)
Привет, как обычно насладился зарядом здравого смысла.. :)

Есть вопрос, на который бы я хотел узнать твой взгляд, gaperton. Вопрос такой. Какие последствия это влечет для активности, называемой QA?

Другими словами смотри что происходит:

1) Есть первоначальный большой договор, когда люди договорились (а не то пиздец). QA-пипл берут "изделие" и сверяют с тем, что было утверждено в договоре. Ну там ещё какие-нибудь стандартные вещи проверяют типа ввод недопустимых значений, краевые всякие случаи и т.п. Все вроде хорошо.
2) Переходим к этапу сопровождения и поддержки, ну и развития. Большие договоры по реинженирингу системы уже очень редки, слава богу на предыдущем этапе сделали все хорошо. Есть некие тикеты в JIRA на мелкие изменения. Ну там штук по 10 в месяц. Ну некоторые тикеты по-больше, некоторые поменьше. В результате требования к системе как таковые начинают эволюционировать и в каждый момент времени это тот изначальный договор + сумма тикетов которые были приняты к разработке. В итоге, понятное дело, некоторые тикеты меняют исходный договор до неузнаваемости.

Внимание, вопросы:

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

1) QA проверяет конкретное изменение, плюс к этому, конечно, нужен регрессионный тест ("все остальное не изменилось"). Регрессионный тест может быть автоматизирован.
2) В случае, если регрессионный тест проводится вручную QA, им нужен тест-план, по которому они должны идти. Тест план в этом случае обновляется силами QA. Это достаточно дорогой подход к тестированию - но он практически возможен.
3) "...и проанализировать влияние изменения на систему в целом..." - это в общем случае могут только программисты сделать.

Нормальные QA в природе существуют, но в голове держать тест-план для регрессионной проверки - методологически неправильно, даже если у них феноменальная память. Здесь нужна аккуратность, а человек не робот. Поэтому, нужны чеклисты (контрольные списки) для проверок, чтобы ничего не забыть. Их надо составлять до тестирования, и это, в общем, некий вариант тестплана.
Previous Entry  Next Entry