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

Среди этих приспособлений числятся и тест кейсы.

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

Китайские крестьяне стали разводить саранчу на своих подворьях. ©

Было бы смешно (желторотые, дескать, китайцы), но действительно — как задачу поставишь, так белая обезъяна её и выполнит.

И это правило работает даже в случае «сам себе задачу поставлю…«

Дашь задачу «написать тест-кейсы» — тебе их напишут пять сотен, задача будет блестяще выполнена.

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

«И попробуйте возразить» ©

2)

Test case = тестовая ситуация.

Абсолютно все люди, которые сталкиваются с тестированием лбами и прочими мягкими местами, должны НЕМЕДЛЕННО прекратить переводить термин ‘test case‘ как ‘тестовый случай‘.

Тест-кейс — это «тестовая ситуация«, а не как мы привыкли…

Уму тестировщика должно быть однозначно вообразимо, что слово ‘case’ неимоверно емкое и неоднозначное. Оно вот это всё:

1. автоматизированное проектирование систем
2. аккумуляторный ящик
3. аргументация по делу
4. больной
5. версия
6. витрина
7. гильза
8. деликтный иск по конкретным обстоятельствам дела
9. дело
10. доводы
11. доказательства
12. заболевание
13. застекленный стенд
14. изложение требований
15. изложение фактических обстоятельств
16. история болезни
17. казус
18. кассета
19. клиент
20. кожух
21. контейнер
22. коробка
23. корпус
24. корпус компьютера
25. крышка
26. ларец
27. материалы дела
28. меморандум по делу
29. место
30. наборная касса
31. наружная покрышка
32. находящийся под наблюдением
33. обвинение
34. обстоятельство
35. обшивка
36. оператор выбора
37. остов
38. падеж
39. пациент
40. покрышка
41. покрышка шины
42. положение
43. прецедент
44. раненый
45. регистр клавиатуры
46. случай
47. случай в судебной практике
48. спорный вопрос в суде
49. станина
50. судебная практика
51. судебное дело
52. судебное решение по делу
53. судебный прецедент
54. сумка
55. фактические обстоятельства
56. факты
57. футляр
58. чемодан
59. чехол
60. чудак
61. ящик

Отличненько, ага?

Дык вот, ‘case‘ в контексте ‘случай‘ распознается следующими синонимами:

• case,
• event,
• incident,
• occasion,
• instance,
• chance

А собственно ‘test case‘ переводится как «прецедент«:

• precedent,
• case,
• example,
• test case,
• authority.

На, убедись: translate.google.com

А вот что означает ПРЕЦЕДЕНТ:

«Поведение в определенной ситуации, которое рассматривается как образец при аналогичных обстоятельствах» ©

Вместо умного и сложного для наших сознаний слова «прецедент» надо использовать слово «ситуация«.

Дело в том, что слово ‘precedent‘ с румынского переводится как ‘предыдущий‘, что привносит много интересных ‘lost in translation’ моментов…

Дело еще в том, что слово ‘case’ в термине ‘test case’ мало кто понимает даже в густо заселенной тестировщиками Индии (коих там больше, чем самих индусов).

А еще дело в том, что…

3)

Тестовая ситуация всегда создается ИСКУССТВЕННЫМ образом.

Перечень шагов в тест-кейсе необходим вовсе НЕ для того, чтобы посредством их прохождения убеждаться в том, что функционал работает ‘as expected’…

Шаги эти рассказывают о том, как привести software в состояние, которое необходимо для проведения теста.

1. Do blah-blah,
2. Do blah-blah, blah-blah,
3. And check that blah-blah… (и софт приведен в необходимое состояние)
4. (и вот тут — одно-единственное тестовое действие) Click!!!
5. Expected result: blah-blah и blah.

Являются крайне основательными все уточнения о том, что под тест-кейсом подразумевается ситуация, созданная искусственным образом, как овечка Долли.

Репост очень! Перестаньте уже вызывать страдания в среде тестировщиков! Мимими и няняня!!! Твои потуги огорчают нас, %username%!

Впрочем, ладно…

Подвигом будет осознание хотя бы первого пункта.

Для размягчения сознания — притча:

Однажды к Учителю пришёл любопытный паломник.

~ Учитель! – сказал он, – а вы можете лежать на гвоздях?

~ Ну, могу, в принципе… — ответил Учитель.

~ Ой, а покажите! – взмолился паломник.

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

~ Нет, это неправильно, — с упрёком сказал паломник. – Гвозди надо вбить в доску, остриями вверх! И вот на этом лежать!

~ Мужик, ты что, дурак? – вежливо спросил Учитель.

И попробуйте возразить! ©

главный редактор портала Software-Testing.Ru ©

Перевел: Алексей Лупан,

худший друг программистов, TestItQuickly.com ©

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

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

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

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

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

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

[vimeo=https://vimeo.com/5521072]

Уважаемые коллеги!

Я думаю, вы уже поняли, что в agile нет никаких других проблем, кроме как с тестированием. Всё остальное в agile хорошо (кроме вопросов о рефакторинге), а проблемы, так или иначе, связаны с тестированием. Я в первую очередь буду говорить о приёмочном тестировании, но также и о другом тестировании, которое… Впрочем, об этом «которое» мы как раз и поговорим.

Часть I, Психологическая, а местами даже геополитическая

Начнём с основ.

Наверняка в детстве вы видели мультик «Великая битва слона с китом»? Мультик потрясающий.

Там в течение семи минут реально слон бьётся с китом самыми разнообразными способами. Колбасит их там по-страшному, они сплетаются, расплетаются, поглощают друг друга, подавляют, что угодно делают… Сейчас примерно такая же ситуация происходит с двумя парадигмами в разработке программного обеспечения — с agile-направлением и не-agile-направлением. Я даже не знаю, как этот «не-agile» назвать.

Голос из зала: Процессное!

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

Вы знаете, в чём главное отличие agile от не-agile?

Голос из зала: А вы расскажите.

А вдруг кто-нибудь знает?

Голос из зала: Бизнес-ориентированность разработки.

Ну, бизнес-ориентированные тут все…

Голос из зала: Способ организации процесса другой.

А в чём же разница?

Голос из зала: Ну, что там у нас? Итерации и инкрементальность…

Итерации и инкрементальность впервые ввёл RUP, который настолько мощно-процессный, что хуже уже некуда. В чем разница?

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

Это новость для меня, если честно 🙂

Из зала — Александр Александров: Моё мнение может быть кому-то не понравится. Agile это религия, в него надо либо верить, либо нет, а вот в процессы верить не нужно.

Да, очень верное замечание и оно очень близко к тому, что я собираюсь рассказать. Если вы посмотрите на RUP и на SCRUM, то вы увидите, что там довольно много похожих элементов. Там есть итерации, они достаточно короткие (в RUP типичная итерация, как и в agile-процессах – это две недели, иногда меньше), и в этих итерациях точно так же происходит всё — дизайн, разработка, тестирование, выпуск готового продукта. То же самое происходит в agile. Разница между ними по-внешнему виду, если посмотреть на схемы и на то, что за чем происходит, не очень заметна. Разница в чём-то другом. Разница не на уровне буквы, а на уровне духа присутствует.

Люди, которые работают в agile-проектах, ощущают то, как они работают, иначе. Но на самом деле — есть практики, если раздраконить agile на мелкие кусочки, получится целая куча инженерных практик. Что будет, если эти инженерные практики попытаться применить? Вот скажем парное программирование…

Посадить людей парами, заставить их программировать в паре, один пилот, другой штурман, и сказать — «Вы, ребята, работаете по процессу RUP», и они будут прекрасно работать по процессу RUP и программировать в паре. То есть инженерную практику можно внедрить куда угодно.

Stand up meetings. Вот вам типичные stand up митинги в стиле RUP — «Встали! Так, сегодня ты делаешь это, ты — это».

Все получили наряды, все пошли работать. Stand up митинги вполне уместны и в RUP, и в любом другом подходе. Нормальная инженерная практика — не делать длинные совещания. Очень хорошая практика.

Но, конечно, по сути от этого ничего не изменится, если мы все эти инженерные практики затолкаем в RUP – он останется RUP’ом, agile’ом от этого не станет. Дух у него от этого не изменится.

И я собираюсь этот дух продемонстрировать на некоем культурологическом феномене…

Посмотрим на картинку с графическим описанием рабочего процесса в RUP – она демонстрирует, как должны быть организованы все деятельности по тестированию. Расписаны роли, расписано кто что делает, расписаны артефакты, которые являются результатом всех этих деятельностей.

Да, кстати, обратное тоже верно. Смотрите, есть все эти артефакты, все эти деятельности, ведь их можно же в agile выполнять? Никто же не запрещает в agile генерировать test-ideas list. Берем wiki и записываем туда наши идеи по тестированию.

Тест-скрипты делаются? Делаются.

Описание тестовой стратегии? Да, на white-board записали, что тестируем, а что нет — вот вам и тестовая стратегия. Выбор инструмента — это тоже часть тестовой стратегии.

Test environment configuration – а куда от него денешься?

Test automation architecture – когда у вас десяток тестов, то у вас все в порядке. А когда у вас их сотни и тысячи, вам уже приходится аккуратно разрабатывать архитектуру, и будете ли вы ее документировать аккуратно или не будете — так или иначе она существует. То есть, все эти артефакты так или иначе у вас появляются.

Роли тоже. Они могут быть не выделенными — нет человека, у которого висит табличка «тест-аналитик». Ну, нет и нет, сделайте себе таблички, и каждый час их перевешивайте, сейчас я тест-аналитик, через час тест-дизайнер. От этого agile тоже RUP не станет. Буква совершенно не важна, важен дух.

В чем же этот самый дух?

Есть в литературе и в живописи такое течение — стим-панк. Или дизель-панк. Его эстетика базируется на некоторой романтизации викторианской эпохи, когда были первые попытки все механизировать, картина мира представлялась полностью механистической. Были попытки сделать механического человека, появились первые паровые механизмы — паровозы, паровые машины, которые вызывали у людей очень большой энтузиазм. Люди поняли — «О, сейчас мы автоматизируем всё! Всё будут делать механизмы, а люди будут их обслуживать».

Что получилось в результате? Когда эта эстетика развивалась, происходило экстенсивное наращивание. Сложность механизмов росла, росла, росла, механизмы становились очень сложными, и если посмотрите современные картины, сделанные в стиле стим-панк, вы увидите какие-то гигантские дирижабли, с какими-то рычагами… Перехода количества в качество не происходит, просто количество наращивается, и в итоге получается очень сложный механизм.

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

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

Какая от этого выгода?

Сейчас я вам буду рассказывать про отличие процессных подходов в agile и не-agile. В чём между ними самое главное по сути отличие?

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

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

Мы тут недавно ездили в Израиль на конференцию, посвященную разработке и тестированию микропроцессоров, и там услышали совершенно потрясающее заявление одного из гуру в этой области: он сказал, что в микропроцессоре очень много ошибок, огромное количество ошибок. Почему же микропроцессоры при этом работают? Да потому, что 90% всех сбойных сигналов, которые происходят внутри микропроцессора, вообще не доходят никак до выходов, до «ножек», они не оказывают совершенно никакого влияния. Это он сказал про ошибочные сигналы. А какой отсюда ещё следует вывод? Те же 90% процентов полезных сигналов тоже не доходят до выхода. Вот какая избыточность у этой системы, вот какой низкий у неё в результате КПД (коэффициент полезного действия). Но за счёт этого мы можем построить из ненадёжных элементов вполне надёжную систему. За счёт понижения КПД отдельно взятого человека.

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

А в agile-процессах — нет.

Если вы читали книги Демарко, Листера или даже Брукса, вы, наверное, знаете, что они советуют делать, когда у вас остается мало времени и вам надо ускорить разработку. Что надо сделать? Надо уменьшить размер команды. Почему? За счет этого вы повышаете КПД её отдельных элементов, вы позволяете им оказывать большее влияние на общий результат работы системы за счет уменьшения количества связей, которые как раз всё это КПД гасят.

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

Что делать, чтобы повысить надёжность этой системы? Нужно брать более надёжные элементы. То есть — нужны хорошие программисты, нужны хорошие тестировщики, нужны хорошие аналитики. И если мы из них соберём проектную команду и не станем ей мешать, то эта команда сделает хороший продукт.

Голос из зала: У вас в команде все хорошие?

Стараемся…

Голос из зала: Нет, вы скажите — «да» или «нет».

Если я скажу «да» — вы поверите? (смех в зале)

Да, тут возникают риски, с которыми надо бороться, людей надо учить, и чтобы эти хорошие люди действительно выдавали хороший КПД, им нужно дать возможность хорошо работать.

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

Если у вас процесс agile, то вы говорите, людям – «вам будет работаться хорошо». Да, в проекте с agile работать хорошо потому, что там много fun’а. Все эти инженерные практики нацелены на то, чтобы добавить в работу какой-то интерес.

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

Так вот… Что же делать, откуда брать таких людей? Был такой писатель, учитель Филиппа Дика — Теодор Старджон, и как-то его спросили, как он относится к научной фантастике. Это были пятидесятые годы, он писал социальную фантастику, а спросили его о научной. Он сказал, что «по моему убеждению, 80% научной фантастики, которая сейчас пишется, это дерьмо». Потом подумал и сказал: «Но если хорошенько подумать, то вообще 80% того, что делается — это дерьмо».

Да, хороших программистов, в общем-то, мало. Поэтому, если вы сейчас посмотрите в англоязычной литературе, то увидите очень много статей на тему «Почему agile-процессы проваливаются?» Не должны они проваливаться. Вот я, Кент Бек, сделал все по agile, и все классно, все работает. Вот я, Майкл Болтон, тестирую, у меня agile, и все круто тестируется, а вот другие люди делают по agile, и у них не получается. Почему? Потому, что они, когда строят, берут ненадежные элементы. Кент Бек надёжный элемент, Майкл Болтон тоже. Но не все такие гении, к сожалению.

Что делать?

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

И тут мы подходим к такой проблеме: agile придумали программисты для программистов. И они придумали для себя много фановых штучек, практик. Они придумали парное программирование. Тестировщики потом как-то попытались делать парное тестирование — не получилось. А парное программирование работает хорошо.

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

И тут мы переходим к технической части.

Часть II, Техническая

Почему тестировщикам ничего не придумали? Потому что программисты, когда начали придумывать… наверное, самой первой штукой был eXtreme programming, там это зафиксировали, а все остальные практически без изменений унаследовали… Они сказали: «Так, бывают unit testing и acceptance testing. И unit testing мы вообще себе забираем, а вам, тестировщикам, остаётся некий acceptance testing. И вообще, этот acceptance testing может делать сам заказчик, если дать ему подходящие инструменты». И всё, тестировщикам не осталось ни работы, ни развлечения.

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

Тогда программисты сказали: «Так, теперь всем вам будет FIT!» Ну, или FitNesse, более расширенная версия.

Тестировщики попробовали пользоваться FIT – нет, не айс *… Никакого fun нет.

* Тонкий намек на рекламу.

Почему? Оказалось, что у них разной работы гораздо больше. Помимо unit testing и acceptance testing есть еще и интеграционное тестирование, где надо вглубь системы руки по локоть запускать, и FIT туда не влезает. Есть системное тестирование, условно говоря, его можно назвать acceptance testing, но FIT помогает только если у вас веб-приложение. Если вы зайдете на сайт FIT и посмотрите, какие там есть предопределенные, стандартные fuxtures — вы найдете fuxtures для JDBC и для веб-приложений. Всё!

А если у вас какие-то сложные протоколы, а если вам надо SMS обмениваться, если у вас нормальный обычный GUI-интерфейс — что вам делать? Нет, там не работает FIT, он doesn’t fit вообще!

Unit testing

Integration testing

System testing

Performance testing

Reliability testing

Security testing

Usability testing

Portability testing

Acceptance testing

Тестирование производительности, тестирование надежности (когда система у вас сутки работает и при этом не падает), тестирование безопасности — FIT не работает. Тестирование удобства использования, тестирование переносимости, кросс-платформенное, кросс-браузерное, кросс-ещё-не-знаю-чего… на разных архитектурах, на разных процессорах, куда все это запихать?

Программисты сказали: «Мы себе забираем unit testing». А все остальное, по-видимому, следует отнести по их мнению к acceptance testing.

Хорошо. Мы, тестировщики — мы говорим «О’кей! Всё это вот будем считать за acceptance testing, теперь мы будем заниматься всем этим. А куда от этого денешься? Надо — значит надо».

А программисты: «У вас есть только FIT!»

Что мы должны сказать в ответ? Мы должны сказать этому решительное

«НЕТ!»

FIT нам мало. Мы хотим много всего интересного.

Откуда взялся FIT? FIT взялся вот откуда.

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

Но что предлагается Емеле для этого?

Емеля, ты хочешь лежать на печке и играть на балалайке 24-й каприс Паганини? О’кей! Сейчас ты будешь пахать как папа Карло, долго, а потом (может быть – если требования не будут меняться, если то и это не произойдет, если мы интерфейс не поменяем, и все твои тесты будут работать) ты сможешь лежать на печке и играть на балалайке.

Фиг!

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

Более того, что они нам предлагают? «Ну, вы же программировать толком не умеете, да?! Мы вам сделаем убогий язык, на котором вы будете программировать в виде таблички».

Человеку, который умеет программировать, это дико. Программировать в виде таблички – это же неудобно! У нас есть хорошие инструменты, хорошие среды разработки, можно пользоваться сторонними библиотеками, можно писать свои библиотеки, чего только там нет… А нам вместо этого говорят: «Вы будете программировать в виде табличек», которые надо писать на wiki-подобном языке с такими вот палочками, в совершенно нечитаемом формате. И даже WYSISWYG толком нет! И после этого они нам говорят: «А вот потом вы будете лежать на печке. И играть на балалайке…»

Увы.

Увы, не наступает это. Именно поэтому мы говорим решительное «НЕТ!»

Наш ответ на это: «Мы не хотим быть программистами на убогом языке. И вообще, что вы, собственно, ожидаете от тестирования, товарищи разработчики, менеджеры проектов и прочие?

Чего вы хотите?

Чтобы у вас просто были тесты, написанные на FIT, которые постоянно не работают из-за того, что всё меняется?

Или вы хотите получать какую-то обратную связь о том, насколько качественный ваш продукт?

Если вы хотите получать информацию о том, качественный или некачественный продукт — дайте нам, специалистам в этом вопросе, сделать то, что мы хотим, и мы предоставим вам эту обратную связь.

Мы вам расскажем и про производительность, и про безопасность, и про всё остальное, и для этого нам FIT не нужен, нам не надо писать убогие тесты. В крайнем случае, если заказчик хочет, давайте мы ему впарим этот FIT, и пусть он сам пишет эти тесты, а тестировщики будут заниматься своим делом».

Своего дела у них много.

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

Представьте себе, что целый взвод всей толпой приходит в деревню, заходит в один дом и ищет там боевика. А они все в других местах рассредоточились. Зачистка местности предполагает, что мы проходимся по всей этой местности, и всё посмотрели, всё проверили. Конечно, боевики попрятались по подвалам, но мы говорим: «На поверхности боевиков нет!» Они все попрятались, но, по крайней мере, они не ходят внаглую с автоматами по деревне. Мы в первую очередь произвели небольшую зачистку.

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

Дальше мы снова проходим, уже с огнемётами и газовыми гранатами, которые закидываем в подвалы, и если они там были, то теперь их там тоже нет.

Зачистка местности при помощи инструментов автоматизированного тестирования произведена быть не может. Поэтому главный инструмент тестировщика — это голова и руки. Как ни поют дифирамбы автоматизированному тестированию в литературе, в статьях — все это вендорская* пропаганда, они просто хотят продать вам свои инструменты. Они это успешно делают, и иногда эти инструменты полезны, ими можно пользоваться, но зачистку местности с их помощью производить невозможно.

* Вендор — производитель/продавец.

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

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

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

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

Тестирование защищенности примерно такое же — вы тыкаете в разные места, бегаете. Это очень хорошо видно, например, когда человек занимается поиском SQL-injection: он бежит сюда – нет, не получается, сигнал слабый, он заходит с другой стороны, и вот так, методом последовательных приближений, находит уязвимости.

Тестирование удобства использования — это дегустация.

Здесь можно даже вместе с заказчиком собираться, совмещать приятное с полезным. «А вот какую удобную кнопочку мы сделали!», «А вот эту операцию мы выполняли за десять шагов, а теперь можно её за три клика сделать!» – и от этого получаете удовольствие вместе с заказчиком.

Видов тестирования много разных. Не надо зацикливаться на чём-нибудь одном, ни на unit-тестировании, ни на FIT, ни на Selenium, ни ещё на чём-то. Смотрите на мир и на жизнь шире.

Ну и наконец, если у вас тестировщики уже всё протестировали, больше им заняться нечем, остается ещё очень большое поле деятельности, которое не относится напрямую к тестированию. Иногда его называют quality assurance. Возьмите тестировщиков, которые умеют программировать, и чтобы им было весело жить, пустите их читать ваш код. Пусть они занимаются code review. Пусть они тоже повеселятся, читая ваш код.

Единственной метрикой качества кода является количество «WTF?» в минуту 🙂

У вас есть люди, которые по какой-то причине, в силу особенностей характера, или в силу исторических причин не хотят или не склонны к алгоритмической работе, но зато у них очень хороший аналитический потенциал, они явно склонны к аналитической работе, а code review это типично аналитическая работа, а не алгоритмическая. Поэтому заставлять программистов заниматься code review не рационально. Тестировщики, которые умеют по меньшей мере читать код, справляются с этим заметно лучше.

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

Для ясности

По внешним признакам и публичным выступлениям Алексея Баранцева можно типировать так: «Программист, пришедший в тестирование«.

Понятно, почему он так легко  проповедует подход «Тестировщик должен уметь программировать«?

Понятно, почему его предложение wtf-чить код программистов — не праздная выдумка? Тем более, что дух agile к этому подходу даже благоволит (долой роли!).

Некоторых программистов такой подход коробит. Ну, есть в нашем мире определенная кастовость, браминность…

Некоторых тестировщиков от такого подхода колбасит в другую крайность: «Да если бы я умел программировать, разве сидел бы я тут и по кнопкам кликал?!…«

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

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

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

Спасибо.

Иди.

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

Затем тыкать в этот список начнет начальник (очень вероятно — твоим же пальцем). И выяснится, что «это достижение» — не достижение, что «это преимущество» — не преимущество, что «это постоянство» — оказионально, а «это увлечение» — недостижимо, и «влияние этого» — не влиятельно, а на рынке, между прочим, все еще достаточно много аналогично наскиленных оболтусов…

Поэтому, прежде чем ходить и тыкать пальцами, надо как следует подготовить самого себя. Критерии? Например, трое парней из блога thetesteye.com изрядно понаписали таких  вопросов:

• Ты уже запускал/проходил свои тесты на ближайшем доступном билде?
• Все эти тесты были обязательны?
• У тебя все тесты обновлены с учетом всех распоследних изменений в проекте?
• Есть ли у тебя тесты, от которых уже следует избавиться по причине того, что ошибки, которые они ищут, уже не воспроизводятся?

Всё переводить не буду. Иди, работай. Составь свой список вопросов к самому себе.

ЗЫ Я просто уверен, что в слове «баголовец» и всех его вариациях нарочно зашифровано слово «овца».

Testertested.blogspot.com ©

С удовольствием перевел: Алексей Лупан,

худший друг программиста

Testitquickly.com©

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

Я хотел просто перевести ее «в буквы», но по ходу перевода не удержался, и…

Автор в курсе содеянного, и полностью одобрил мой перевод.

Комментарии автора приведены в оригинале, и помечены зеленым цветом.

Исходное видео: утрачено.

Видел я несколько видеокастах о тестировании на ваших Youtube-ах. Их авторы распространяли довольно грубые толкования в сфере тестирования программного обеспечения.

Посредством моей презентации я хочу развенчать хотя бы два, но реально популярных мифа о тестировании.

Миф 1: Тестирование улучшает качество продукта

Многие тестировщики, которых я встречал на моем на жизненном пути, верят в этот миф.

Вот вам история — у меня заболел живот. Я подумал — о, это рак!

Врач направил меня на обследование: анализ крови, мозга, мочевины и так далее. Принес я ему эти анализы, а он и говорит: «Уупс, мужик, у тебя реально рак».

Я подумал: «Блин». Я так и подумал.

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

Ну, и они пришли, и повязали, суки, и ноги, и руки, как падаль по грязи поволокли меня самого в Тихар (это «Владимирский централ» в Индии, крупнейшая тюрьма во всей Азии).

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

Сидя в некрасивой тюрьме я часто видел сны, и вот что кажется мне: что врут все те, кто искренне верит в миф #1 — «тестирование улучшает качество продукта».

Ведь если тестирование действительно улучшает качество, то после 51-го проведенных врачебных тестов мой рак желудка уже должен был излечиться самостоятельно! Почему же это не произошло? Ведь мы же тестировали всё мое тело…

А тут врач решил навестить меня там, где должен был сидеть он сам — в тюрьме. Я спросил врача: «Wtf?» То есть, как же так? Я тестировщик, я всю жизнь учился тому, что тестирование само по себе уже улучшает качество, мы с вами вовсю протестировали мой желудок, а я — тут, света белого не вижу.

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

Гм.

Это был реальный урок.

— Доктор, вы имеете ввиду, что тестирование только снабжает нас информацией о качестве?

— Да, о ты, глупый лягушонок, недостойный сын шакала Табаки, пылинка с хвоста слона Хатхи, о ты, тестировщик программного обеспечения, долбанутый лапой Балу!

— Блин…

То есть, я до сих пор верил множеству идиотов из славной индустрии программного обеспечения в том, что тестирование улучшает качество, а тут белохалатник меня так просто и элегантно вразумил… Баааалин!

Спрошенный о количестве упомянутых «a lot of idiotic people», Прадиип объяснил:

Not having right knowledge for a long time could also mean they are idiotic to have not discovered about it nor taken any action to improve. I don’t know the count but I can definitely say there is one — myself. I can’t be brilliant all times and I interact with myself most of the times.

В чем смысл тестирования?

«Тестирование — это изучение программного продукта с целью его оценки» — James Bach.

Каждый тест, который мы сотворяем с тестируемым софтом, сотворяется только для того, чтобы оценить, как продукт откликается на наши действия. Мы постоянно спрашиваем софт: «А вот я тебя… И что ты мне ответишь? А?»

Кем Кэйнер (для многих — Сэм Канер) сказал: «Тестирование снабжает менеджмент проекта информацией о качестве продукта, для того, чтобы помочь им принимать решения»

Например, я пойду к менеджеру и скажу «Моя нашло 50 некритичного бага-бага, йоу!», и менеджер скажет «Йоу, давай релизать в продакшн!»…

Ну, а если я скажу, что нашел только пять багов, но один из них не позволяет установить продукт… Менеджер скажет: «Oh, yeti russian programmisten, opiati oni ne po spekam kodiat! Мы опять не можем деливерать продакт нашим кастомерам, балин…»

Итак, что мы имеем? Мы имеем менеджеров, которые принимают решение о релизе нашего багософта на основании предоставляемой нами информации. А кто информацию предоставил? А Коробейников, на старости лет не оставил нас в нужде, снабдил ордерами-то…

Вот это и есть работа тестировщиков.

— Прадиип, действительно ли это был рак? И сидел в тюрьме?

— No, it was a made up story. However it definitely hits hard on the fact that testing by itself doesn’t improve quality.

Миф 2: Тест-кейсы находят баги!

Много людей в Индии, и, наверное, в остальных Молдовах, уверены в том, что тест-кейсы находят баги. Вот вам другая реальная история.James Bach, эксперт в тестировании и заумный чувак философ, нанял меня на пару раундов тестирования. Он обещал мне по $10 за каждый баг, который я найду.

И я подумал:

Я написал туеву хучу тест-кейсов, и с их помощью нашел 30 багов.

Я сказал: «Джеймс — гони бабки! Принимаю любой эквивалент — рупии, пиастры, леи, доллары, прекрасные наложницы…»

А он не дал мне ни фига.

Тогда я понаписал еще тест-кейсиков, и нашел еще 32 бага. Короче, я уже намеревался купить свой свечной заводик.

А он снова не дал мне ни фига.

Я сказал: «Yarr! Мужик, ты явно хочешь прогуляться по нок-рее…»

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

Я хотел его убить поблагодарил в лучших традициях «Рамаяны» и «Махабхараты», сказав: «Джеймс, ты преподал мне отличнейший урок о тестировании. Подавись ты моими баксами».

А он добавил: «Но в действительности, баги ищут не тесты, а люди. Тесты лишь помогают людям искать баги». И вернулся в астрал.

Джеймс Бах отличный тестировщик. Он помог мне понять эти простые истины.

Процитируем первоисточник:

…it is not a test that finds a bug but it is a human that finds a bug and a test plays a role in helping the human find it.

Ладно, вам все еще интересно, сколько денег я сколотил с моего тестирования?

Миллион!

Серьезно, шо ли!?

Не, серьезно!

Ну, например, Бах своим миллионы «поднял» именно с тестирования, так что…

Я перестал тратить время на написание тест-кейсов, и стал тратить время на поиск багов.

Если моя миссия в этой жизни — искать баги, и я ограничен во времени (помните, что у нас нет трех или четырех жизней на тестирование продукта?), то я стал экспериментировать и искать баги. И стал находить их намного больше, чем раньше.

— Прадиип, а как же реинкарнация? Ты же можешь вернуться в любой момент…

— I might have a thousand lives but who knows I’d be a tester in all those lives 😉

Минута: 56:20

Есть ли в Google люди, которые проводят мануальное тестирование? То есть, сидят и «кликают»?

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

Но есть и определенное количество ручного труда, конечно.

Вот! А что мотивирует этих людей? Работа зачастую монотонная, такая однородная, и часто — не очень интеллектуальная…

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

Может быть, им интересней, чем в других компаниях потому, что мы выпускаем интересные вещи. То есть, вполне возможно, что если тебе дать потестировать что-нибудь из того, что Google выпустит через три месяца, ты тоже будешь очень excited, потому что это может быть что-то ТАКОЕ, и никто об этом еще не знает…

А может быть, здесь играет свою роль просто фактор рабочей культуры в США — она очень сильно отличается от России. Она какая-то… По российским представлениям она может казаться детской, тупоголовой и дебильной. Но по местным представлениям — здесь ценятся такие вещи как «Я люблю свою работу».

У нас, за редкими исключениями, если ты говоришь «Я очень люблю свою работу и у меня замечательный начальник», на тебя будут смотреть как на идиота. Человек, который любит свою работу, воспринимается как какой-то слабак. Круто — это говорить, что «Ладно, пока работаю на дядю, а потом буду на себя…», или просто быть недовольным своей работой и начальником.

Конечно, в IT-индустрии этого меньше, но в целом у нас гораздо больше цинизма и эгоизма. Человек, который искренне работает на коллектив… Может быть, у нас аллергия к этому выработалась с советским времен, когда все говорили, что коллектив это все, а ты — ничто.

Поэтому все живут так, как будто они — коллектив, и человек, который искренне работает на коллектив, искренне ассоциирует себя с коллективом, рассматривается как дурачок, слабак, сопляк, которого можно как-то использовать…

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

Действительно… Я никогда не задумывался об этом, наверное, это resistance советскому прошлому, ведь действительно, культура командной работы редко встречается…

Может быть. Этой искренней ассоциации с коллективом у нас, в IT-индустрии, больше, ведь чем более интеллектуальная индустрия, тем этого больше… но в целом….

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

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

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

Между кстати

Для полноты картины предлагается все-таки скачать и послушать первоисточник. У меня есть опасение, что будучи в отрыве от контекста, эта часть текста может кого-то убедить в том, что проблему скуки мануального тестирования достаточно просто решить — надо, чтобы тестировщику было интересно то, чем он занимается. Гы-гы 🙂

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

В странах СНГ у начальников есть уверенность в том, что «если не пнешь — не полетит». С таким подходом в Google сложно жить, ибо там РАБОТАЕТ понятие «самоорганизующиеся команды инженеров».

Но подход «Всех вас надо пинать» имеет серьезные истоки, поэтому нельзя вообще его игнорировать или объявлять преступным 🙁

Для ценителей англиканскаго языка сцылка про подробности корпоративной культуры в Google. Вкратце: очень открытая система «внутри», но очень замкнутая «внаружу».

habrahabr → Тестирование → Тестирование ПО: как объяснить руководителю, что 2 х 2=4?

Простой, но внезапный вопрос чуть не поставил в тупик: «Почему тестировать должны тестировщики, а не аналитики, разработчики или пользователи?»

К записи 55 комментариев, и ни одного внятного ответа.

Далее следует мой любительский и очень краткий, буквально тезисный перевод свежей заметки «Top 10 reasons why there are Bugs/Defects in Software!» от 15 дек 2008.

Наверное, это ответ на процитированный вопрос хабрахабравчанина.

Почему в программном обеспечении бывают ошибки?

1. Человеческий фактор

   Софт делают люди. А люди не совершенны.

   Собственно, на этом пункте можно и остановиться, настолько он всеобъемлющ и великолепен…

2. Проблемы в общении

   Расхождение между ожидаемым и фактическим, когда «Мы же думали, что вы имеете ввиду…» и «Имеем мы ввиду то, что вы там думали…»

3. Нереальные сроки разработки

   Недостаток временных ресурсов так же критичен, как и недостаток финансирования.

   Но даже если у девелопера есть вечность на разработку очередного калькулятора, я потом к нему зайду и все равно буду обеспечен работой…

4. Плохой дизайн софта

   В эпоху комплексного программного обеспечения для поиска наилучшего решения постоянно приходится балансировать на гранях предположений, догадок и понимания о том, что, собственно, кодим…

5. Кривые руки кодеров

   Иногда ошибки возникают как следствие плохого кодинга…

6. Плохой контроль версий

   Недостаточный или же поверхностный контроль версий кода — логово багов, которые «вылезают» при регрешне.

   Да, это страшно!

7. Дефекты во внешних приложениях

   Иногда проблема может быть не только в том, что делаем, но и в том, посредством чего делаем.

   Плохому танцору вечно что-то мешает…

8. Низкие навыки тестирования

   Тестировщики в этом не признаются, но будем честны: это бывает.

   Самое время для того, чтобы сказать «Вооот! Нет тестировщиков на проекте, ну и воооот вам…»

9. Изменения «в последнюю минуту»

   Изменения могут быть внесены в последнюю минуту и в требованиях, и в инфраструктуре, и в инструментах девелоперов, и в платформе…

Эй, пацаны, а вы заметили, что я обещал десять пунктов, а написал только девять? Аааа, это же страшный баг! Почему бы вам самим не приписать тут десятый (11-тый, 12-тый…) пункт?

Один из комментариев к переводимому тексту принадлежит сэру Кему Канеру. Суть:

Development groups rely on test groups the way that countries rely on regulators. We trust them to do their work well and we do other things ourselves instead of redoing the work that we know will be done by the testers (regulators). If the testers do their work poorly, problems stay in the product — partially because the testers don’t find them and partially because the testers don’t alert management to more general trends of weakness that cause corrective action in design and programming.

So, I agree, in some contexts, bad testing can certainly lead to lower quality.

Автор блога немедленно распоясался 🙂

@ Dr. Cem Kaner,

You have made me the Happiest tester today by leaving behind your comment on my blog.

It is a privilege and honor to have comment of a testing guru like you on my post, who also happens to be one of the pioneers of Context Driven Community.

It is simply brilliant how you correlated regulators (Security and Exchange Commission) with testers.

Оно и понятно…