5

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

Теперь про анализ. У меня такое замечание/дополнение по процедуре анализа ошибок найденных исследовательским тестированием, да и другими методами тестирования тоже. Я очень понимаю желание проанализировать ошибку до нахождения точных границ фейла ("когда ввожу число 500  - работает, 501 - уже нет"), но со временем пришел к выводу, что обычно этого делать не надо. Достаточно зафиксировать входные параметры, при которых ошибка возникает ("ввел число 650 - не работает") и продолжать поиск других ошибок.

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

13

"Наш проект огромен, проверять нужно немерянное количество вещей, вручную это занимает очень много времени, да и в принципе то не всегда возможно проверить всё вручную, поэтому мы решили внедрять автоматизацию" (с) одна из первых реплик доклада

Очень распространённая при продаже и абсолютно неправильная формулировка. Если это сложно и огромно, то автоматизирование займет несравнимо больше времени и приведёт к худшему результату, чем ручное тестирование.

Впрочем дальше в докладе становится понятно, что имелось ввиду совсем другое. Автоматизация внедрялась, потому что в проекте очень много частых релизов и разветвлений, для которых повторяют базовые тесты (регрессию). Заметьте- что "сложный большой продукт" и "частые релизы, большое количество версий" - совсем не синонимы.

Надеюсь, всегда запоминается последняя фраза ;-).

Хочу поделиться фразами про качество и сделать их вольный перевод.
"You can't test quality into a software project; it must be built in."
"Quality must be built in, it cannot be added on."
Не нашел первоисточников, последние корни увели в сторону Тойоты второй половины прошлого века.

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

Наконец опубликовано видео с моего доклада на SQA Days 16. Хотите сделать ваше ручное тестирование быстрее и гибче? Обязательно посмотрите 🙂

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

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

Видео:

Слайды:

...читать далее No-Test-Cases: избавьтесь от тест-кейсов в ручном тестировании

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

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

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

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

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

Знакомо?

1

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