Нашел интересную мысль в книге Голдратта "Теория ограничений".
Голдратт в книжке описывает производство и свою TOC (theory of constraints), но мне кажется модель узнаваема и применима для IT-компаний и других методов улучшения процессов.

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

Вы - начальник отдела Тестирования (или любого другого), и решили начать с того, чтобы автономно внедрить методы ТОС (ну или другого метода улучшения процесса) в тестировании, чтобы показать их эффективность и убедить другие подразделения тоже его применить. Допустим, у вас это получилось, и в Тестировании не осталось критических ограничений, которые тормозят общий результат. Теперь, если вам удалось убедить остальных (Программирование и Продажи), то все хорошо :-). А если они тем не менее отказываются попробовать ваш метод (причин для этого может быть тысячи, многие понимают о чем я), то получается любопытная ситуация. Ограничения лежат теперь в других подразделениях, что значит, что они пашут по полной программе, чтобы получить максимально возможную прибыль. Ваше тестирование оптимизировалось так, что у тестировщиков стало больше свободного времени при том же результате на выходе (например тестировщики еще быстрее успевают протестировать все, что написали программисты, и продажи не успевают найти достаточно новых проектов).

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

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

Знакомо?

1

Интервью 2-летней давности о профессии тестировщика. Не со всем я согласен, но в целом неплохие ответы.
Кстати особенно несогласен с заголовком и с суггестивными вопросами ведущей 🙂

(история фиктивная, совпадение в цифрах и диалогах случайное).

Как вы думаете, выгоднее заплатить за работу 5.000,- € и ждать неделю или заплатить 7.500,- € и ждать 2 недели?

Не угадали!

Звонят рекрутеры, клиенту нужно срочно сделать Feasibility Study для тест автоматизации, клиент дает 2 недели времени. Предлагаю сделать за неделю и 5.000,- €. Отказ. "Слишком дорого, клиент готов платить не более 750,- € за день".

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

Интернет пишет вот, что любой хотел бы. Лично я не хотел бы, что я делаю не так? 🙂

Мне кажется не стоит путать роли тест-менеджера и надсмотрщика. А вам?

П.С. контекст цитаты - session-based testing.

1

Обезьянки против роботов от Максима Дорофеева из далекого 2009-ого года. #нея5летназад
В трех частях более чем наглядное сравнение автоматизации тестирование с ручным. Осторожно, юмор.
Обезьянками нас обозвал, правда. Ну хотя б не земляным червяком 🙂


8

А еще программисты, иногда отклоняют баги с абсурдным пояснением "works as designed", что в принципе означает, что программа работает таки да, так, как они её запрограммировали. Я могу понять "works as intended", "works as specified", "works as required", но вот "works as designed" определенно режет мозг.

3

Немного наболело мне за понятие Quality Assurance (оно же Qualitätssicherung (нем.), оно же обеспечение качества (рус.)) в области разработки ПО.

Очень жалко, что это название досталось нам по наследству, от промышленного производства, понимается многими айтишниками на автомате буквально и из-за этого делаются опасные и иногда даже вредные выводы.
Давайте вспомним, что же делали работники Quality Assurance в дософтварную эпоху. На начальном этапе наши "тестировщики" брали готовые (или промежуточные) детали и измеряли их например штангенциркулем или скажем весами, на предмет соответствия ожидаемым значениям. Конечно со временем деталей стало производиться много, и "тестировщики" задействовали математико-статистический аппарат - измеряли из миллиона "одинаковых" деталей 200 случайных и оценивали количество ошибок математическими методами. Так или иначе, долгое время тестировались объекты, которые можно было объективно измерить и сравнить результат с эталоном.

И вот к нам пришло ПО (программное обеспечение). Особенность ПО по сравнению с большинством продуктов производства из прошлого, что "ошибки измерения" в ПО не лежат на поверхности. Более того, они там спрятаны настолько хорошо, что на данные момент  не существует практических методов доказательства того, что в софте отсутствуют ошибки, доказать можно только их наличие. Про это писали многие современные гуру тестирования (Болтон, Бах и другие), самое раннее упоминание в литературе, что я нашел от http://en.wikiquote.org/wiki/Edsger_W._Dijkstra в 1969 году. (Testing shows the presence, not the absence of bugs).

В результате мы приходим к тому, что никоим образом не может quality assurance assure the quality (Qualität sichern, обеспечивать качество), если речь идет о программном обеспечении. Повторюсь, QA может и должно искать и находить проблемы, но не доказывать или тем более гарантировать их отсутствие.

У меня всё.

"Тестировщик - это который по сайту кликает?".
"Ты тестировщик? То есть ты знаешь программирование? И ищешь в исходниках ошибки, да?"
Студенты-стартаперы. Обоих обратил в правильную веру, день прожит не зря.

МТС обогатил мой словарный запас словосочетанием "нечисловые символы".И еще они прислали SMS о том, что ответ на запрос придёт по SMS. Нет, вы не подумайте, действительно пришёл.