Lesson 176

А я добыл для тестеров вот такой вот артефакт:

Альбом: office

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

Где б рынду добыть, чтоб на обед звать, хм...


С переводом какая-то беда сегодня.
Слово Канеру

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

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

Советы, подобные этому, звучат и звучали удручающе часто последние лет 20. Мы считаем, что в такое случае более вероятно будет подорвано доверие к тест-менеджеру или он будет уволен, чем улучшатся процессы в компании.

Let's note and then set aside the religious question: Are documentation- heavy approaches that resist late changes (like the waterfall) really the only ones that qualify as "good engineering?" That's the assumption (often stated explicitly) behind this type of advice.

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

We suggest that you work with programmers as they are. Salespeople and drive-by consultants, who have no stake in your success and face no consequences from your failures, are poor authorities on the proper responsibilities of programmers in your company.


bret pettichord, cem kaner, chapter 8, james bach, lessons learned in software testing, лекции