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

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

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

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

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

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

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

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

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

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

Может.

Sanity check

Sanity check

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

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

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

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

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

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

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

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

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

Upd по ряду запросов на уточнения:

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, да?!

Википедия

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

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, да?!

Реклама

Read Full Post »

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

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

Read Full Post »

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

State-Transition Testing

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

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

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

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

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

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

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

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

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 »

Older Posts »

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