Feeds:
Posts
Comments

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

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

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

[Скачать в mp3]

Advertisements

Read Full Post »

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

State-Transition Testing

Вот это самое “State-Transition Testing”

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

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

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

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

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

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

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

Read Full Post »

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

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

(more…)

Read Full Post »

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

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

(more…)

Read Full Post »

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

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

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

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

(more…)

Read Full Post »

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

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

Read Full Post »

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

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

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

(more…)

Read Full Post »

Older Posts »

%d bloggers like this: