Feeds:
Posts
Comments

Archive for the ‘Acceptance testing’ Category

Автор: Алексей Баранцев,
главный редактор портала Software-Testing.Ru ©

Перевел: Алексей Лупан,
худший друг программистов, TestItQuickly.com ©

barancev1Момент истины

Прошёл уже почти год после конференции AgileDays и уже слегка подзабылись те мысли, которые ворошились у меня в голове, когда я готовился выступать на ней. Поэтому когда я редактировал сейчас этот текст, я испытывал смешанные чувства. Местами я думал – да это же практически гениально, как же я сам до этого не догадался! И только потом вспоминал, что это же мои собственные слова.

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

Надо также помнить, что это живая речь, поэтому местами изложение не очень структурированное (если не сказать сильнее), а кое-где весьма эмоциональное. Надеюсь, что текст сможет передать мои эмоции.

А если нет – посмотрите видеозапись…

Алексей Баранцев

(more…)

Read Full Post »

Вечер.

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

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

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

(more…)

Read Full Post »

По танку вдарила болванка

По танку вдарила болванка

Read Full Post »

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

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

Пытается программист уточнить, зачем эта труба клиенту нужна. Умудренный знает, что клиенту этой информацией делиться нафиг не нужно. Что ему труба нужна. Или пирожок 🙂 Но пытается.

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

How to test software with dynamic requirements?” – достаточно вменяемая статья на тему нестандартных труб, исходя из всей доступной “широты” этого вопроса.

Решение в этому случае достаточно взвешенное, хотя и местами рисковое – чек-лист.

Кто незамутненно уверен в том, что чек-лист – стопроцентная панацея в работе тестировщика, тот дурак. Зависит от проекта и уровня образования тестировщика. Например, без понимания софта тестировать в таком режиме почти невозможно. А вот по тест-кейсам может тестировать любой товарищ, даже не понимающий, что именно оне изволят-с тестировать и зачем. Доказательство.

Или MindMap.

Вот пример карты в MindMap (required Flash). В примере я показал часть того, что должно было быть сделано программистом в отношении гипотетической задачи “ER-678”.

Это все было расписано не в требованиях, а размазано в комментариях к задаче. Занести все это в MindMap и как следует раскидать по логикам вещей – 7 минут. Проще, чем просить письмо с однозначными требованиями и громко предпочитать работать в гетеросексуальном коллективе.

Сколько времени занимает само тестирование – уже не так важно, it’s depends… Важно то, что если какое-то требование будет изменено через час, его изменение займет в этой карте минимальное время, и все равно будет понятно, что и как надо делать. А если будет добавлено что-то новое, то и в карту его добавить несложно.

Интереснее всего то, что будет видно потом. Видно, что в пункте “all the other checkboxes should be unchecked and greyed out” возникли какие-то проблемы… И в комментарии указано, что по этому поводу открыт новый баг в баг-трекере.

MindMap позволяет очень и очень грамотно и гибко сортировать топики по разным признакам – пользуемся Queries.

Read Full Post »

Прослушал отличный семинар Николая Алименкова про Acceptance Test Driven Development.

Выводы: это ж совсем не то, что мне до сих пор понималось! 😦

Еще не совсем ясно, как это будет касаться меня впредь. Подобные прогоны подобных тестов – это мир ХР. Это сила, но она касается именно момента “владения кодом”:

  1. овладел кодом,
  2. сделал в нем изменение,
  3. прогнал тесты,
  4. увидел “зеленое” – с довольной рожей продолжил править код;
  5. а если увидел “красное” – быстро поправил код, прогнал все заново, и с довольной рожей продолжил кодировать свои абстрактные абстракции в нечто более осязаемое, но тоже абстрактное.

Школа “функционального” тестирования гласит о следующем:

  1. исследовал софтину,
  2. прогнал тесты,
  3. увидел “красное” – сообщил программисту. Что и как он будет дальше делать – он не скажет.

То есть, вообще другим воздухом дышим.

Еще я дам доллар тому, кто покажет мне заказчика, который “умеет писать акксептанс критериа”, и с удовольствием этим занимается.

Или не дам.

ЗЫ Fitnesse (wiki-надстройка над Framework for Integrated Tests) – это вещь…

Бонус №1: рассуждения Алименкова на тему ATDD:

На мой взгляд, современные средства для acceptance тестирования позволяют достаточно легко писать тесты наперед. Это помогает разработчикам повысить уверенность в законченности своей работы и правильности (полноте) требуемого функционала без постоянного взаимодействия с QA. Таким образом команда становится более целостной и помогает друг другу достигнуть единой цели – разработки качественного продукта.

Команда становится более целостной без постоянного взаимодействия с тестировщиками…

Бонус №2: презентация Дмитрия Лобасева “Разработка через приемочное тестирование с FIT“. Материалы с выступления на SQA2008”.

Read Full Post »

%d bloggers like this: