• Главная
  • О сайте
  • Архив

Normal testing

From the programmer's worst friend

Feeds:
Записи
Комментарии
« Кто тебя воспитывал?
Agile Gathering VI (Киев) »

Три сита в грамотном тестировании

09.10.2008 Автор: Alexei Lupan

Вечер.

Хочется порассуждать о тестировании глобально, посасывая белое мартини из трубочки. Именно мартини, потому, что «массандровский» херес меня не восхитил, а коньяка в офисе уже мало.

Рассуждать хочу долго и о ситах.

Си́то — устройство для разделения сыпучих масс по величине их составляющих (зёрен, круп, песка и т.п.).

Сперва послушаем историков:

Человеческие жертвоприношения из ряда тестировщиков до и после релиза были распространённым явлением у менеджеров проектов, живших на полуострове Юкатан до нашествия конкистадоров. Тестировщиков приносили в жертву через повешение, утопление, отравление, избивание, а также посредством захоронения заживо в груде документации по проекту.

Наиболее жестоким видом жертвоприношения являлось, как и у девелоперов, вспарывание живота и вырывание из груди ещё бьющегося сердца тестировщика, который пропустил баг.

В жертву приносились как тестировщики, перекупленные в ходе войн представители других племён (корпораций), так и члены собственной группы, в том числе и высший слой, сениоры.

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

Итак, утопление.

В начале ХХ века в центральной Америке было модно заниматься археологическими раскопками в «подземных» озерах. Для тех, кто в эти озера когда-то нырял, это довольно мрачное место. А для археолога ХХ века подобное озеро — кладезь информации. На дне, в многовековых наслоениях грязи, лежат никем не разворованные украшения, кости, черепа и прочие интересные археологические штучки.

Как все это добро достать?

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

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

Выход — использовать насосы с ситами разного калибра. Положим три сита друг на друга. Наверху будет сито с самыми крупными ячейками. В середине — среднее. Снизу — самое мелкоячеистое.

Насос начинает выкачивать грязь из подземного озера. Грязь вываливается на сита, и археологам надо только подставлять свои любопытные руки под это месиво.

  • Все крупные предметы будут лежать на верхнем сите.
  • Самые мелкие тоже не пропадут, потому что их пропустит среднее сито, но задержит самое мелкое.
  • Все бусины буду сосчитаны и уложены в ящики. Если их не пропьют помощники археологов, то позже их можно будет выкрасть из европейских музеев.

В идеальном, грамотном процессе девелопмента применим тот же принцип просеивания тонны грязи софта сквозь три сита. Но, поскольку у нас тут не все как у людей, то порядок расположения сит изменен. Сверху лежит самое мелкоячеистое, потом среднее, и внизу — сито с самой крупноячеистой сеткой.

Сделаем музыкальную паузу.


Прочти, раскрась, запомни:

Тестирование в Agile-way особенно сильно тем, что всё, что можно автоматизировать, автоматизируется до и во время разработки, а не отдельно от неё.


Продолжим сосать мартини и рассуждать.

Каждое «сито» в девелопменте имеет свое имя.

  1. Test Driven Development — сито мелкоячеистое.
  2. Acceptance Test Driven Development — сито среднеячеистое.
  3. Functional Testing — сито крупноячеистое.

Первые два сита — епархия программистов. Сам я существенно разбираюсь только в третьей теме.

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

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

Например, понятие сита — уже абстракция.

Абстрактность тут нужна потому, что большинству людей понятие TDD поначалу не «поддаётся», и неимоверно трудным оказывается процесс понимания всего этого. Но когда во все врубился и вгрыззся, становится странным, что до сих пор все это не использовал…

Unit testing

Внятный пример — LoveUT.

Цитата из статьи:

Тихо мурлыкая под нос, Анна продолжает кодировать свой класс.

Суть «разработки через тестирование» проста:

  • Сначала программист пишет тест для проверки функциональности, которую собирается написать. Этот тест называется «unit-test», потому, что он проверяет только одну единицу функционала.
  • Затем программист пишет функциональность.
  • И постоянно проверяет ее посредством ранее написанного, специально для нее, теста.
  • Как только функционал удовлетворяет требованиям этого теста, разработка функции считается завершенной. Переходим к следующей.
  • Во время разработки других функций, которые связаны с уже существующей, программисту можно и следует запускать юнит-тесты чаще, чем его легкие всасывают в себя один литр воздуха. Если все «горит зеленым» — программист счастлив. Если красное — увы.

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

Особенности юнит-тестов:

  • Неподготовленный человек не может их читать и понимать, не видя код.
  • Уровень абстракции в юнит-тестировании неимоверно нулевой. Тесты обрабатывают определенный код, и будучи отстраненными от кода просто не находят смысла в своем существовании. Цель юнит-тестирования — изолировать отдельные части программы и показать, что по отдельности эти части — работоспособны.
  • Когда функция меняется, юнит-тесты меняются в первую очередь.

Дальше надо сидеть рядом и показывать, как это работает. Этот момент в одиночку вряд ли одолеть, поэтому пропускаем подробности и едем дальше.

Acceptance testing

Внятное описание на английском языке: wikipedia.org.

Акксептанс-тесты — второй шаг после юнит-тестов. Это уже существенный уровень абстрактности от кода.

На предыдущем уровне проверялось и доказывалось, что каждая отдельная часть программы работоспособна. А на этом уровне проверяются взаимосвязи между отдельными частями программы, а также то, что программа выполняет заранее определенные задачи в определенном виде.

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

Особенности акксептанс-тестов:

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

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

Парадкос в том, что подобные проверки хоть и абстрактны, но изрядно привязаны к существующему коду. Ведь абстракции проверяются работающим кодом, не так ли?

Для сочувствующих agile development уточняем: акксептанс-тесты проверяют юзер-сториз. А юзер-сториз — вне кода, вне технологий. Получается, что у нас есть high level tests, которые запускаются нажатиями кнопок.

Пример, пример!

Приводится стандартный пример из учебного проекта, который видит каждый, кто умудряется запустить FitNesse.

В примере проверялась такая юзер-стори:

«User want to perform money operation from my account to another one to pay/receive money to/from another User»

посредством следующего приемочного критерия:

«After money operation one of the accounts is increased and another is decreased by the same amount of money».

Критерии акксептанс-тестов задают (а в идеальном мире — пишут) заказчики софта, а не разработчики. Например, пресловутый заказчик просит* следующего:

  • в базе должны существовать аккаунты разных юзеров.
  • у каждого юзера на счету есть какие-то деньги.
  • после нажатия кнопки «Сделать офигенно», со счета юзера №1 на счет юзера №2 должны передаваться какие-то суммы.
    * имхо, неимоверно удачно выбранный глагол.

Как выглядит такой тест, написанный в wiki-разметке в фреймворке «FitNesse»

FitNesse

Тесты в FitNesse читаемы и понятны

Как эта таблица выглядит в формате wiki:

Make sure that there are no accounts in the bank.

!|ensure|clean accounts|

Create two different accounts.

!|create account for user|Bob|with amount|5|

!|create account for user|John|with amount|7|

и тд

Как это выглядит после прогона теста:

FitNesse рапортует о выполнении задач партии

FitNesse рапортует о выполнении задач партии

Как и почему это работает — не уточним, чтобы не переходить в детали и не разрушать сказки и абстракции.

Но стоит сказать, что написание подобных тестов требует интеллекта и какого-то времени. Все равно, что стихи писать…

Предварительное резюме

Тестирование на уровне юнит-тестов показывает, что кусочки кода по-отдельности работают, как ожидалось.

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

Сравним это с муравьями. Пропустим муравьев через мелкое сито. Если каждый в отдельности муравей не хромает и бодро шевелит своими шестью лапками — это отличный муравей. Но это не гарантирует нам то, что муравейник, большая система взаимоотношений между муравьями, будет работать.

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

Functional testing

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

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

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

Тут мы узнаем, что бывает, если муравьев в системе слишком много или слишком мало.

Это можно делать как всеми органами осязания, воззрения и осмысления, так и заранее документируя свои действия (тест-кейсы).

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

Окончательное прозрение

Если

  1. проект только начинается
  2. разработка ведется в стиле on-going (неизвестны ни конечный результат, ни дата полного финала)
  3. код пишется «с нуля»
  4. заказчик умеет работать в agile-стиле
  5. разработчики умеют работать в agile-стиле
  6. инженеры «болеют» тестированием
  7. все три сита постоянно применяются в процессе разработки

тогда

  1. проект вполне может завершиться выпуском идеального продукта
  2. все риски, которые влечет неполное тестирование, могут быть предупреждены и преодолены
  3. скорость разработки возрастает в неимоверные разы
  4. каждый гребёт свою кучу денег и убегает домой пить пиво и смотреть футбол с любимой женой.

Ваша оценка:

Поделиться ссылкой:

  • Tweet
  • по электронной почте
  • Печать

Понравилось это:

Нравится Загрузка...

Похожее

Опубликовано в Acceptance testing, Agile, Автоматизация, Банальное, Гипотезы, Инструменты, Озарения, Постановка мозгов, Скриншоты, Соображения | Отмечено Сита | 1 комментарий

Один ответ

  1. на 10.10.2008 в 12:14 Аноним

    ниче так…

    расскажи подробнее о FitNesse

    НравитсяНравится



Обсуждение закрыто.

  • Aut bene

    Спiвпрацювальник по підготувальні тестувальників.

    Автор [глоссария] терминологии тестирования (english).

    Неоднократный докладчик [SQA Days], [QA Fest] и других конференций по тестированию ПО.

    Неспешный езжун на «[Волга ГАЗ-21]» 1965 года выпуска.

    Игрун чего-то похожего на тяжелый блюз [на классической гитаре].

    И так [далее].

  • Присоединиться к ещё 1 338 подписчикам

  • Follow Normal testing on WordPress.com
  • Залежи

  • Темы

    • Без рубрики (6)
    • Документация (18)
      • Тест-план (2)
    • Изображения (148)
      • Видео (48)
      • Комиксы (20)
      • Скриншоты (48)
      • Фотографии (46)
    • Инструменты (53)
      • Debian (13)
      • Макросы (1)
      • Трекеры (15)
        • Баг-трекер (8)
        • Тест-трекер (5)
      • LibreOffice (4)
    • Книги (19)
    • Конференции (137)
      • Подкасты (12)
      • Презентации (50)
        • Слайдкасты (10)
      • Семинары (18)
    • Обзоры (1)
    • Постановка мозгов (245)
      • Банальное (168)
        • Не смешно (47)
        • Неприятно (14)
        • Печали (15)
        • Радости (57)
        • Смешно (35)
      • В гостях у психиатра (45)
        • Поросенок v2.0 (3)
        • Странности (12)
        • Удивительные баги (17)
      • Level 80 (2)
    • Соображения (206)
      • Балабольник (10)
      • Гипотезы (11)
      • Озарения (55)
      • Откровения (88)
    • Статьи (23)
      • Интервью (6)
      • Опросы (1)
      • Переводы (11)
    • Управляторское (56)
      • Agile (13)
      • Программисты (23)
      • Рекрутинг (8)
    • Учеба в бою (83)
      • Тренировка (13)
      • Фишки (28)
      • Читерство (9)
    • Testing like… (79)
      • Acceptance testing (5)
      • Business Driven Testing (2)
      • Context-driven testing (2)
      • Defect-based Test Design Technique (1)
      • Автоматизация (37)
        • Performance Testing (5)
      • Рецессионное тестирование (1)
      • Юзероиммитатор (15)
      • Exploratory testing (9)
      • тест-дизайн (8)
      • State Transition testing (1)
      • Unit testing (1)
      • Usability testing (2)
    • To Do (12)
      • Анонсы (7)
  • Тэги

    Calc Excel James Bach Jira Mantis SQA Days SQA Days 7 SQA Days 8 SQA Days 10 Александр Александров Александр Орлов Алексей Баранцев Наталья Руколь Хватит тупить Юля Нечаева
  • Самое читаемое

    • Тестируем поля логин/пароль
    • Группирование данных в Excel
    • Priority & Severity на пальцах обезъянок
    • Как в Excel отображать символ валюты перед цифрами
    • План тестирования должен быть внятным, четким, небольшим
    • Что такое перформанс-тестирование
    • Разница между ошибкой (багом) и дефектом (тоже багом)
    • Ссылки в Confluence. Mazafaka
    • Основные положения тестирования
    • Резюме тестировщика должно быть
  • Комментарии

    • Alexei Lupan к записи Сетап для преподавания в сети
    • Дмитрий к записи Сетап для преподавания в сети
    • Сетап для преподавания в сети | Normal testing к записи Оценка времени на тестирование: неочевидные надводные камни
    • Мария к записи Выделить вкладку страницы в фокусе в Firefox
    • Alexei Lupan к записи Савин, Фолкнер и Нгуен…
    • Тимур Исхаков к записи Савин, Фолкнер и Нгуен…
    • Alexei Lupan к записи Кагбэ собеседования в паблике
  • Блоги о тестировании

    • 1) Блоги тестировщиков на software-testing.ru
    • Про тестинг
    • Selenium IDE — rulezzz!
  • Профессиональное

    • Удобный софт
    • Управление тестированием
    • IT Crowd wikiquotes
    • Testing History

На платформе WordPress.com.

WPThemes.


Отмена
loading Отмена
Сообщение не было отправлено — проверьте адреса электронной почты!
Проверка по электронной почте не удалась, попробуйте еще раз
К сожалению, ваш блог не может делиться ссылками на записи по электронной почте.
Политика конфиденциальности и использования файлов сookie: Этот сайт использует файлы cookie. Продолжая пользоваться сайтом, вы соглашаетесь с их использованием.
Дополнительную информацию, в том числе об управлении файлами cookie, можно найти здесь: Политика использования файлов cookie
%d такие блоггеры, как: