Feeds:
Записи
Комментарии

Posts Tagged ‘Хватит тупить’

Обычно вы делаете это с PowerPoint. На слайде у вас картинка какой-то черной коробки и текст вроде «Тестирование чёрного ящика или поведенческое тестирование — стратегия (метод) тестирования функционального поведения объекта (программы, системы) с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве тестируемого объекта. Под стратегией понимаются систематические методы отбора и создания тестов для тестового набора. Стратегия поведенческого теста исходит из технических требований и их спецификаций». Вы зачитываете этот текст почти дословно (пропуская запятые и интонации, бо дыхания не хватит), и спрашиваете, всё ли понятно.

Пример подобного слайда

Пример подобного слайда (элементарно нагуглено)

Да, говорят вам. Понятно, чоуж.

(далее…)

Read Full Post »

Коллинз - Водить как Стиг

Бен Коллинс — Водить как Стиг

В поезде читал «Водить как Стиг» Бена Коллинса (второе издание, Альпина нон-фикшн, Москва, 2018).

Высокое качество печати и оформления, отличный текст, но все-таки четыре ошибки в тексте нашел, из них две совершенно нелепые. Глаз царапает, ну да ладно.

А вот на стр. 155 разверзлись хляби подземельные, и стало ыыыы:

Санитарное тестирование

Санитарная проверка

Вах-вах-вах, не может же быть же…

Может.

Sanity check

Sanity check

Короче, нет никакого санитарного тестирования.

Само слово Sanity переводится на русский язык проще:

  • вменяемость,
  • здравомыслие,
  • нормальная психика.

Нет там никаких санитаров. То, что вы называете Sanity, по-сути есть Smoke testing.

Я ещё не знаю, когда эти термины появились, но уже давно ясно, что это два разных названия одного и того же феномена. Просто тестировщики называют это Smoke, а программисты называют это Sanity. Так они привыкли, так оно укрепилось в их литературе.

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

Канер в своей книге Testing Computer Software (1988, у меня второе издание, 1999-го) не упоминает ни про smoke, ни про sanity. Самое близкое к ним есть в главе 3 ‘Test types & Software development‘ на стр. 51, и ВНЕЗАПНО оно там называется «Acceptance testing»:

Each time you receive a new version of the program, check whether it’s stable enough to be tested. If it crashes at the slightest provocation, don’t waste your time on it. This first bit of testing is called acceptance or qualification testing.

На стр. 54 та же тема с уточнениями в разделе ‘Final acceptance testing and certification‘:

If your company developed the program on contract, the customer will ran an acceptance test when you deliver it. In small projects, this test may be informal. For most projects, however, test details are agreed to in advance, in writing. Make sure the program passes the test before trying to deliver it to the customer. An acceptance test usually lasts less than a day. It is not a thorough system test. Beizer (1984) describes the preparation and execution of formal customer acceptance tests. Perry (1986) is, in effect, a customer’s guide to creating acceptance tests. Consider using Perry (1986) to structure your negotiations with the customer when you jointly design the acceptance test.

Цитата на books.google.com

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

заранее и письменно согласуйте с заказчиком набор приёмочных тестов. Убедитесь сами в том, что релиз на них не завалится. Ранее об этом писали Бейзер (1984) и Перри (1986).

Это воспринимается странно, бо в наше время «Acceptance testing» объясняется как «Заказчик сам тестирует, как хочет». И да, вероятно, он будет основываться на наших смоук-тестах. Предполагаю, что в наше время этот термин просто истолковывается неверно, но это уже не существенно.

А вот в 2001-ом Канер уже упоминает Smoke testing в «Lessons Learned in Software Testing: A Context-Driven Approach» на страницах xxvi (это предисловие, там сходу заявлены определения ключевых терминов), 41, 121, 162, 163, 169, 141 и 144. И ни разу не упоминается sanity testing.

Рекс Блэк в «Ключевые процессы тестирования» (2004) упоминает эти два термина одновременно. В русскоязычном издании «Лори» 2006-го года они на стр. 532:

Приемочное тестирование, тестирование на исправность (Smoke Test, Sanity Test). Тестирование, проверяющее, насколько стабильная предлагаемая на тестирование версия, чтобы можно было начинать штатное тестирование. Обычно это подмножество всего комплекта тестов, как правило, автоматизированное, затрагивающее все части системы, по крайней мере, поверхностно. Качественные приемочные тесты обычно довольно долго проверяют работу системы, чтобы проявились серьезные проблемы надежности и работоспособности. Термин “smoke test” (тест на задымленность) взят из электротехники: когда инженер включает цепь, первичный тест проверяет, не дымятся ли компоненты.

Википедия

ВНЕЗАПНО сообщает о том, что сэнити — даже не из мира тестирования, термин существует сам по себе, и применим ко всем аспектам человекодеятельности, от сервировки обеденного стола до запуска ядрённой атомной бомбы на головы мирных жапонцев.

In computer science, a sanity test is a very brief run-through of the functionality of a computer program, system, calculation, or other analysis, to assure that part of the system or methodology works roughly as expected. This is often prior to a more exhaustive round of testing.

Огромное, гигантское отличие от smoke test, да?!

ISTQB (скачать файл Glossary all terms 3.1.pdf).

Sanity test объявлен синонимом smoke test (стр. 61).

В канонах ISTQB вы не сомневаетесь, не так ли?!

Толковалка ISTQB

It is a kind of software testing which is done by the testers to ensure that the functionality is working as expected.

Огромная разница со smoke test, да?!

Кто-то сделал почти тот же обзор книг в поисках тех же терминов, что и я: almeln.github.io, и пришел к тем же выводам.

О переводах: «Да, но ведь гугл переводит это слово именно так!»

Google перевод слово Sanity

Google переводит слово Sanity

Гугл переводит так, как считает правильным большинство. Там можно предлагать другие переводы слов, можно даже устроить флешмоб и добиться перевода какого-то слова совершенно по-дурацки, и гуглу будет норм.

И напоследок. Я предполагал, что ебалайтунг с терминологией присущ нашему, русскоязычному сектору. Например, вон чего на protesting.ru пишут:

В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование — это одно и тоже. Мы же полагаем, что эти виды тестирования имеют «вектора движения», направления в разные стороны.

Но он процветает и на английской стороне. Быстро нагуглилась статья на эту тему с сайта h2kinfosys.com — оба термина представлены как нечто обособленное. Понятия не имею, что это за контора из штата Джорджия (США), но о себе они говорят «H2k Infosys provides world class IT Training, Real-time Live Project to gain hands on experience, and IT Staffing services».

Надо ли возражать людям вообще?

Read Full Post »

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

Упоминается Роман Савин, бо совместно листали его книгу «Тестирование дот ком» в попытке узнать, что такое тест-дизайн, и не нашли 😦

Read Full Post »

Таки додумался, почему State Transition testing не вызывает моментального ой-вэй эффекта у большинства увязнувших в тестировании.

State-Transition Testing

Вот это самое «State-Transition Testing»

Трабла уже описана профессором Преображенским в соответствующей литературе в качестве первопричины разрухи.

Тут надо думать «исходное Состояние системыДействиеиное Состояние системы».

А мы с «деццва» учимся продумывать тест-кейсы как «ДействиеРезультат действия».

Вот «кружочки» и не получаются.

А получается что-то вроде ‘Product available in the CartProceed to CheckoutCheckout Page opened‘. Бред-то какой, полюбуйтесь на вашего Полиграфа…

Ну а потом начинается извечная шумерская жалобная песнь для успокоения сердца (просто выберите любимое и добавьте воды):

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

Что надо сделать

  1. определить happy path — их может быть несколько.
  2. определить другие сценарии и ветвления к ним.
  3. выводить в отдельные ветки всё, даже если они подразумевают переход к одному и тому же состоянию (есть множество исключений, но это должно быть основным подходом; впоследствии он сэкономит силы и нервы).
  4. стрелка — действие. Круг — состояние, а не результат действия, как мы привыкли писать в тест-кейсах.
  5. не запихивать всё в один рисунок. Пусть будет много рисунков. Переключайтесь между листами.
  6. если что-то пошло не так и надо перерисовывать — будете материться, а не ерзать ластиком. Проще будет быстро нарисовать правильную последовательность заново, поэтому рисуйте без детальной детализации.

Read Full Post »

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

А загляните в череп опытного заказчика ПО — он требования прописывает сам. Всегда. Да, общепонятно, что через требования он хочет получить хотя бы именно, что было заказано, но засада не в том, что «без ТЗ результат ХЗ» (можно ваять ПО и без предварительного малевания ТЗ). Проблема в коммуникациях. Чем более опытным становится заказчик, тем сильнее он эту проблему осознает и начинает решать.

(далее…)

Read Full Post »

Ок, в последнее время так много людей заявляют «Хочу стать тестировщиком«, что уже пора сказать вслух и грубо: ок, бро. Просишь научить — научим.

Научим всякой туфте, вроде Smoke Testing, Regression Testing, Decision Table Testing, Pairwise Testing, даже State-Transition Testing, или даже, святая святых, не каждому дано — Domain Analysis Testing… Это интересно? Это поможет найти работу?

(далее…)

Read Full Post »

С какого-то времени и в нашей компании бытует регулярный «Performance review». Компания бурно растет, все дела…

Это прекрасная тема для обсуждений и трепа на ДОУ в любом приличном обществе. Каждому понятны плюсы и профиты подобного ревью.

Ведь правда же?

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

(далее…)

Read Full Post »

Такие штуки сложно адекватно сформулировать, но наконец-то я нашел стратегию найма [тестировщиков], с которой я полностью согласен:

  • нанимаем тех парней, которые явно мотивированы к работе в тестировании; тех, которые демонстрируют свои способности и возможность к эффективной работе и развитию своих навыков. Поэтому иногда мы нанимаем тех, кто может учиться быстро, даже если у них нет достаточной технической или практической подготовки, но видна вероятность быстрого внедрения в текущие дела и достижение успешности. Поэтому иногда мы отказываем вроде бы опытным «я шесть лет в тестировании» дамам и господамам.
  • можем нанять тех, кто «не дотягивает», но может помочь быстро «закрыть позицию» на проекте, менеджер которого согласен нанят недостаточно подготовленного работника. Мы выдаем таким работникам большой кредит доверия и рассчитываем на то, что он ощутимо «подтянется» до среднего уровня участников проекта.
  • не нанимаем тех, с кем мы не можем быстро найти общий язык. Отказываем тем, кто вряд ли сможет приспособиться к новому окружению; отказываем тем, кто не приемлет изменений; отказываем тем, кто тупит, даже если у них есть необходимый технический бэкграунд и практический опыт.
  • не нанимаем тех, кто запрашивает существенно больше денег, чем мы решили предложить после проведения личного собеседования. Но можем предложить меньше денег тем, у кого навыков и умений недостаточно для запрашиваемой суммы.

Read Full Post »

Анадысь давеча случилось мне тестировать систему, которая отвечает за обработку товаров на складе.

Система не так, чтобы замороченная, но с нюансами.

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

(далее…)

Read Full Post »

На Гаваях есть клуб сёрферов (катаются на волнах на досках), который называется точно так же, как и основавшая его банда — «Da Hui».

У них есть и сайт — www.dahui.com

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

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

То есть, дальше будет чуть более подробное рассуждение про самокопание и профориентацию нахальных тестировщиков.

Перед прочтением надо запастить мартини (я взял коньяк, тирасполь, восемь лет, подогнали на мой прошедший «ДР!») и наушниками.

Много букв. Текст из разряда «неспешных», быстро прочитать его вряд ли получится.

(далее…)

Read Full Post »

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

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

Однако есть простейший способ для начала работы с требованиями. Вот пример issue:

Summary «Export product list to Excel (csv)»

Description [3:42:34 PM] Маркетинг: а на счет экпортировать репортик?
будет такая возможность?
[3:42:56 PM] Программист: tebe nado exportirovati vse dannie ili postrani4no?
ili konkretnuiu stroku?
[3:44:20 PM] Маркетинг: одной строки не достаточно. мне надо чтоб то что я выберу фильтром (все отфильтрованные продукты) можно было скачать и потом работать с эксель файлом.

Status: Resolved.

И все отлично 🙂

А главный секрет в том, чтобы требования хотя бы как-нибудь хотя бы где-нибудь были записаны в виде БУКВ, а не в виде «Мы созванивались и это дело обсудили«.

Оформлять все это дело можно потом как угодно по какой угодно схеме и методике.

Read Full Post »

Анадысь случилась со мной странность.

Раз в месяц кто-нибудь из внешнего мира спрашивает меня о чём-то, связанным с тестированием.

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

Мне очень интересно общаться в таком стиле. Ментор я, гыгы.

Но одно из обращений недавно закончилось моим провалом в роли ментора.

Эпик фэйл.

Аустерлиц.

Линия Мажино.

Один парень (дефолтный сити) решил оценить свои способности к тестированию посредством тестирования программы «ListBoxer».  Меня он попросил проверить его результаты по найденным ошибкам в том приложении.

Правильный настрой. Правильное стремление.

Но!

(далее…)

Read Full Post »

Бытует мнение о том, что пора перейти к делу, а не тупить над чужими тест-кейсами.

Открыт набор в четвертую группу Алексея Баранцева «Программирование для тестировщиков«.

Для тех, кто в пути, следует напомнить о том, что (цитата из отзывов на предыдущие выпуски):

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

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

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

В целом результат курса сногсшибателен:

«Уже в первую ночь я стал на ночь глядя класть на тумбочку два стакана — один с водой, другой — пустой.

Первый на случай, если я захочу ночью пить,  а второй — если  пить не захочу«.

Вот что делает с человеком волшебная сила искусства программирования тестов.

Яростно рекомендую.

Read Full Post »

Все знают Лизу (Лайзу) Криспин? Это та отличная тётка, которая написала книгу «Testing Extreme Programming» (Boston: Addison-Wesley, 2002), которую ты скачал три года назад, но еще не прочитал оттуда и трети текста.

А недавно она написала «Agile Testing: A Practical Guide for Testers and Agile Teams» (Addison-Wesley, 2009) — тоже надо скачать, пусть тоже лежит…

Еще известно, что Лиза (Лайза) в самом расцвете сил и любит ослов.

А еще она очень оторвана от наших реалий 🙂

(далее…)

Read Full Post »

Был на форуме it4business.ru вопрос про специфику Context-Driven подхода в тестировании. Автор вопроса не понимал, как именно этот подход соотносится с тестированием. А как это объяснить, а? Чем-то напомнило пресловутое «объясните мне эти абстракные вещи на конкретных предметах«. Я такой ответ  сформулировать не смог.

Нашлось достойное объяснение за подписью LeshaL.

Стоит внимательно перечитать на каждом досуге.

(далее…)

Read Full Post »

Older Posts »

%d такие блоггеры, как: