ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 368
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Приемочное тестирование
141
вроде русского или английского для написания спецификаций с требованиями .
Увидев, что клиенты ни в какую не хотят писать приемочные тесты, программисты решили исправить положение, и в надежде на то, что клиенты хотя бы прочитают документы, написанные формальным языком, уже сами написали для них тесты . Но и это не сработало, ведь клиенты терпеть не могут формальные языки .
Они предпочтут посмотреть на работающую программу или в луч- шем случае доверят тестирование QA-специалистам .
Разработка через поведение
С наступлением нового тысячелетия Дэн Норт начал работу по пересмотру разработки через тестирование . Получившуюся ме- тодологию он назвал разработкой через поведение . Он поставил себе цель избавиться от жаргона технарей в тестах, чтобы тесты больше напоминали спецификации с требованиями, которые так любят клиенты .
Сначала это было еще одной попыткой формализации языка тести- рования, в этом случае применялось три ключевых слова: «дано»,
«когда» и «тогда» . Было создано или модифицировано несколько инструментов для поддержки этого языка . В их числе JBehave,
Cucumber и FitNesse . Но с течением времени упор стал делаться не на инструменты и тесты, а на требования и спецификации .
Сторонники разработки через поведение предполагают, что кли- енты могут извлечь большую пользу, указывая требования к своим программам на формальном, основанном на сценариях языке вроде того, который использует ключевые слова «дано», «когда» и «тог-
Глава 3. Методы взаимодействия с клиентами
142
да», независимо от того, автоматизированы ли в действительности такие требования в виде тестов .
Это избавляет клиентов от соответствия техническим требовани- ям, которые налагает написание действительно исполняемых те- стов, в то же время позволяя быть тестам формальными и точными .
Как показывает практика…
Несмотря на всю противоречивость и запутанность, которые мы увидели выше, в приемочном тестировании нет ничего сложного .
Клиенты пишут формальные тесты, которые содержат описание каждой пользовательской истории, а разработчики эти тесты ав- томатизируют .
Эти тесты пишутся бизнес-аналитиками и QA-специалистами до завершения первой половины итерации, когда должны разрабаты- ваться истории, которые впоследствии будут проходить эти тесты .
Разработчики объединяют эти тесты в непрерывную сборку . Такие тесты соответствуют критериям готовности для историй, разра- ботанных во время итерации . Требования к истории не считаются указанными, пока для нее не написан приемочный тест . История не считается завершенной, пока не пройдено приемочное тести- рование .
Бизнес-анализ и контроль качества
Приемочные тесты — результат совместной работы бизнес-анали- тиков, QA-специалистов и разработчиков . Бизнес-аналитики ука- зывают, что должно происходить в лучшем случае . Они являются связующим звеном между заинтересованными сторонами и про- граммистами и выражают их желание получить хороший продукт .
Приемочное тестирование
143
Специалисты по контролю качества, напротив, обрисовывают наихудший исход . Сейчас способов получить такой исход намного больше, чем раньше . QA-специалисты зарабатывают на хлеб тем, что вычисляют уязвимости программы . Технари до мозга костей, они способны предвидеть все финты и фокусы, которые может выкинуть программа . Они также знают, как мыслят программисты и как определить халтуру .
И, конечно, не обойтись без самих разработчиков . Они, работая со специалистами по качеству и бизнес-аналитиками, обеспечивают гарантии того, что тесты будут иметь смысл с технической точки зрения .
Контроль качества
Здесь, конечно, QA-специалисты играют уже более важную роль .
Если сначала они выполняют тыловую работу тестировщиков, то теперь выходят на первый план, находясь на передовой линии проекта . В начале работ они дают обратную связь после написа- ния кода, указывая на ошибки и упущения, а потом занимаются предотвращением этих ошибок, заблаговременно предоставляя необходимые данные разработчикам .
Нагрузка на специалистов по качеству многократно возрастает .
Контроль качества теперь должен проходить в начале каждой итерации, а не выявлять недостатки и несоответствие на финаль- ной стадии . Однако в любом случае важность контроля качества не преуменьшается — именно инженеры по качеству определяют, можно ли развернуть систему .
Тесты в конце бесполезны
Проведение контроля качества и автоматизация тестирования решают еще одну важную задачу . Когда специалист по контролю
1 ... 6 7 8 9 10 11 12 13 ... 20
Глава 3. Методы взаимодействия с клиентами
144
качества проводит тестирование в конце, да еще и вручную, он по- падает в щекотливое положение .
Работа должны быть выполнена до развертывания программного обеспечения . Но менеджерам и заинтересованным сторонам про- сто не терпится скорее начать развертывание, и они наседают на
QA-инженеров .
Когда контроль качества переносится на финал проекта, весь удар берут на себя специалисты по качеству . А если разработчики отдадут продукт на проверку с опозданием, будет тогда перенос сроков? Часто сроки определяются очень важными деловыми причинами, поэтому перенос будет дорого стоить или даже в кор- не расстроит планы клиента . В итоге козлом отпущения остаются
QA-специалисты .
Как специалистам по качеству тестировать программу, если на это не остается времени в графике работ? Как им выполнить работу быстрее? Очень просто: пропустить некоторые тесты . Протестиро- вать только то, что изменилось . Провести анализ воздействия на функции, которые появились недавно или претерпели изменения, а потом протестировать уязвимости . Не тратить время на тестиро- вание того, что не изменилось .
Так пропускаются необходимые тесты . Под давлением сроков QA- специалисты пропускают все регрессионные тесты, надеясь, что проведут их в следующий раз . Но чаще всего «следующий раз» не наступает .
Болезнь контроля качества
Все перечисленное выше не самое худшее, что происходит с кон- тролем качества на финише . Если контроль качества проводится
Приемочное тестирование
145
в конце, как клиенты узнают, хорошо ли выполняется работа?
Естественно, по количеству выявленных недочетов . Если специ- алисты обнаруживают тонну ошибок, то они явно не просто так получают зарплату . QA-специалисты могут завышать количество таких ошибок, чтобы показать, как замечательно справляются со своими задачами .
И считается, что раз что-то найдено, значит, все хорошо .
Кому еще выгодны недочеты? Среди старых программистов есть такая присказка: «Уложусь-то я в любые сроки, а как оно будет работать — это уже другой разговор» . Так кто еще выигрывает от найденных недочетов?
Разработчики, которым нужно уложиться в сроки .
И здесь не нужны слова . Не требуется никаких договоренностей .
Обе стороны понимают, что только выиграют . Начинается черная торговля недочетами . Эта болезнь свойственна многим компаниям, она не то чтобы смертельна, но весьма изматывает .
Разработчики в роли тестировщиков
Эти проблемы лечатся методом приемочного тестирования . QA- cпециалисты пишут приемочные тесты для историй, выполнен- ных за итерацию . Но само тестирование проводят не они . Не QA- специалисты должны проводить тестирование программы . Тогда кто? Программисты, конечно!
Это работа программистов . Разработчики ответственны за под- тверждение того, что их код проходит все тесты . Поэтому проведе- ние тестирования, безусловно, работа программистов . Проведение тестов — единственный способ проверить, выполнены ли истории .
Глава 3. Методы взаимодействия с клиентами
146
Непрерывная сборка
А будет так, что программисты автоматизируют тестирование
1
, установив сервер непрерывной сборки . Каждый раз, когда про- граммист запускает проверку какого-нибудь модуля, сервер будет запускать необходимые программы, с помощью которых будут проводиться тесты, в том числе все модульные и приемочные . Под- робнее о непрерывной интеграции далее в этой книге .
ОДНА КОМАНДА
В экстремальном программировании практика «одна коман- да» изначально называлась «заказчик всегда рядом» (On-Site
Customer) . Идея заключалась в том, что чем меньше дистанция между пользователями и программистами, тем лучше коммуни- кация, и разработка таким образом становится быстрее и точнее .
Заказчик был метафорой кого-то или группы людей, которые понимали потребности пользователей и были рядом с командой разработчиков . В идеале клиент сидел в одной комнате с коман- дой .
В Scrum заказчик называется «владелец продукта» . Это человек или группа, которые выбирают истории, ставят приоритеты и дают своевременную обратную связь .
Метод переименовали в «одна команда», чтобы стало ясно, что команда разработчиков — это не дуэт «заказчик — программист» .
В команде разработчиков вклад вносят все, в том числе руково- дители, тестировщики, разработчики технической документации и т . д . Цель этого метода — в наибольшей степени улучшить кон-
1
Потому что автоматизация — это работа программистов!
Одна команда
147
такт между всеми участниками . В идеале все участники должны сидеть в одной комнате .
Вряд ли вызывает сомнения, что нахождение всей команды в од- ном пространстве увеличивает ее эффективность . Команда может общаться быстро и с минимум формальностей . Ответ на вопрос можно получить за несколько секунд . Рядом всегда есть опытные товарищи, которые могут подсказать .
Более того, это повышает вероятность непреднамеренных инту- итивных открытий . Представитель заказчика всегда может по- смотреть в экран программиста или тестировщика и заметить, что происходит что-то не так . Тестировщик может случайно услышать, например, что программисты, работающие в паре, обсуждают тре- бования, и понять, что они пришли к неверному выводу . Такой си- нергетический эффект нельзя недооценивать . Когда одна команда работает в одном пространстве, происходят чудеса .
Обратите внимание, что этот метод относится к методам взаи- модействия с клиентом, а не к методам взаимодействия внутри команды . Основные выгоды от метода «одна команда» получает клиент .
Когда команда находится в одном пространстве, дело идет сла- женнее .
В одном пространстве
В начале 2000-х я помогал некоторым организациям внедрить методы Agile . Во время предварительных визитов, до того как начинать активный коучинг, мы попросили наших клиентов под- готовить пространство и расположить в нем всех членов команды .
Заказчик неоднократно сообщал, что эффективность команд за-
Глава 3. Методы взаимодействия с клиентами
148
метно возросла просто потому, что ее члены находились в одном пространстве .
Размещение другим способом
В 1990-х интернет открыл широкие возможности использования труда программистов в странах с очень низкой стоимостью рабо- чей силы . Искушение воспользоваться этой возможностью было бешеным . Бухгалтеры делали расчеты и с горящими глазами пред- ставляли, сколько средств можно было сэкономить .
Но мечта мечтой, а действительность опустила всех с небес на землю . Оказалось, что рассылать мегабиты исходного кода по всему миру не совсем то же самое, что расположить в одном про- странстве команду из клиентов и программистов . Была огромная разница как в расстоянии, так и в часовых поясах, языке и куль- туре .
Несогласованность зашкаливала . Качество оставляло желать луч- шего . Нужно было много переделывать
1
. В последующие годы технологии в какой-то мере стали совершеннее . В наши дни ско- рость передачи данных позволяет регулярно связываться по видео и передавать изображение на экране . Два разработчика в разных концах света теперь могут работать в паре над тем же кодом почти так же, как если бы сидели за одним столом . Конечно, такой про- гресс не решает проблему разных часовых поясов, культурных и языковых различий, но электронное написание кода лицом к лицу несомненно предпочтительнее, чем пересылка исходного кода туда-обратно по электронной почте .
1
Это мои личные впечатления, основанные на разговорах с ребятами, кото- рые напрямую сталкивались с подобными проблемами . Сейчас у меня нет актуальных данных . Действуйте на свой страх и риск .
Одна команда
149
Можно ли так работать по методам Agile? Я слышал, что можно .
Но сам никогда не видел, чтобы это хорошо удавалось . Может быть, вы видели .
Удаленная работа из дома
Повышение пропускной способности интернет-соединения су- щественно облегчило людям возможность работы из дома . В этом случае различия в языке, культуре и часовом поясе не составля- ют существенной проблемы . Кроме того, не нужно передавать данные через океаны, нет сбоев . Совещания команды могут про- ходить почти так же, как если бы ее члены находились в одном помещении .
Не поймите меня неправильно . Когда члены команды работают из дома, есть значительная нехватка невербального общения . Раз- говоры, приводящие к случайным открытиям, происходят гораздо реже . Неважно, насколько хороша связь посредством электроники, члены команды все равно физически не в одном пространстве .
Поэтому люди, работающие из дома, находятся в невыгодном по- ложении . Они всегда пропускают какие-нибудь разговоры или им- провизированные встречи . Несмотря на широкополосный доступ, они будто смотрят через глазок по сравнению с теми, кто находится рядом друг с другом .
Если в своем большинстве команда находится в одном простран- стве, но один-два члена команды пару дней в неделю работают из дома, скорее всего, никаких трудностей не возникнет, особенно если используются средства связи с хорошей пропускной способ- ностью . С другой стороны, если члены команды почти все работают из дома, такая команда никогда не сработается так же хорошо, как если бы была вместе .