Курс Основы тестирования программного обеспечения от mail.ru

На этой неделе закончил на универсариуме курс по тестированию от mail.ru

Итоги коротко:
Площадка универсариума - твердая пятерка. Удобно, понятно. Я ее не замечал во время прохождения курса, именно так и нужно делать площадки.

Лектор и оформление лекций. Вел курс директор по качеству мейлрушной почты Алексей Борисович Петров.
Аналогично, все сделано на крайне высоком уровне - материалы в pdf, голос, прозрачная доска, на которой он пишет текст, монтаж - наглядно, без нареканий. От смысла не отвлекался совершенно.
Кстати, Алексей на прозрачной доске пишет справа налево и его почерк не страдает. Респект.

Содержание, кратко: четыре с плюсом. Из двадцати пяти лекций я не нашел к чему придраться в десяти, тем не менее, серьезных и принципиальных разногласий с содержимым у меня нет. У меня серьезные подозрения о приемлемом качестве и объеме автоматизации и уровне бюрократии, но тут без личного досмотра отдела Алексея судить нельзя.
Для быстрого старта на первых месяцах работы тестировщиком - очень полезно.

Рекомендую.

А теперь о деталях, которые я отметил для себя в ходе просмотра. Просто заметки к лекциям.

- Говорится о цене исправления ошибки, но нигде не говорится о цене поиска, а уж тем более, о цене сопровождения. А это важно.

- Расстраивает пренебрежительное отношение к терминам. Во-первых, у ПО нет "функционала", есть функциональность. Во-вторых, прилагательное полуавтоматизированный является тавтологией. Есть цепочка: автоматический - автоматизированный - ручной. Термин полуавтоматизированный не имеет смысла.

- План тестирования и стратегия тестирования - все же отдельные артефакты.

- План в начале тестирования в реальном мире является не столько инструкцией и руководством к действию, сколько контрактом с заказчиком - он говорит о том, что и как я буду проверять, и, что не менее важно, что я проверять не буду.

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

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

- Арифметическая ошибка в подсчетах. 600 всего, 40 починено, 200 выпущено, 100 найдено пользователями. Если бы было починено 480, то были бы исправлены не 80% дефектов с которыми столкнулись пользователи, а 40. Вы почему-то считаете, что все те 80 дополнительных дефектов, которые предлагали починить входят в сто, которые нашли пользователи. А они входят в 200 которые вы выпустили. Надеюсь Алексей при общении с руководством более аккуратен с цифрами и не удваивает ключевые показатели.

- "Автоматизация неэффективна при частых изменениях" - все с точностью до наоборот и мне кажется странным, что специалист такого опыта и уровня позволяет себе так говорить. Автоматизация крайне эффективна ИМЕННО при частых изменениях. Причины называются в соседних пунктах. В случае редких изменений неплохо себя покажет обычный ручник, а там где нужен быстрый отклик - там и помогут роботы.

- Автоматизация не экономит ресурсы, это распространенное заблуждение. Автоматизация ускоряет отклик, увеличивает покрытие. Ну либо в mail.ru реально увольняют ручников, когда напишут автотесты, во что я не верю.

- Вызывает некоторое сомнение высокая точность измерения вовлеченности сотрудников по проектам. Плюс минус 10%? На какой период времени рассчитывается процент? Также кажется странным управление через ресурсы времени, да еще с такой степенью детализации, а не через вехи, цели и дедлайны. Неужели столь низко доверие к своим сотрудникам? Это нормально для бадишопа на аутсорс, но у мейлру же собственная разработка.

- Модель результативности не совсем корректна. У тестировщика на продукте есть верхняя граница количества багов которые он может найти. Если подать на вход в два раза больше багов, он найдет в полтора раза больше. Если утроить баги на входе - тестировщик не будет находить больше определенного количества. Зависимость совсем не линейная. Метрика слишком неоднозначна, чтоб ей эффективно пользоваться.