IT Jam 2009

На выходных была на IT Jam. То, что конференция была бесплатной привлекло громное количество участников, что впечатлило, но не скажу что в этом большой плюс. Наверняка из почти 600 человек были те, которые пришли посидеть в интернете, поспамить твиттер и поесть пирожков. Так что небольшая плата за участие сработала бы как фильтр для заинтересованных людей.

Я поняла, что тяжело бывает не только спикерам, но и слушателям. Непрерывные доклады с 11 до 17 часов в 6 секциях - это не легко. Очень сложно решить, что же слушать. В первой половине дня все шло живенько. Мне понравились доклады Alexander Dymo "Ruby: Beauty or the Beast?" и Mikalay Alimenkou "Kanban vs Scrum", к сожалению не удалось послушать Тимофея Евграшина на тему Scrum. А вот после обеда... то ли я не те доклады выбирала, то ли просто устала, но иногда было сложно не то что вникнуть, но даже просто высидеть.

Из полезного вынесла для себя: Kanban, как оказалось мой проект ведется по похожей методологии, которую раньше мы никак не могли классифицировать, и знакомство с несколькоми интересными людьми, в частности Дмитрием Братиной из Infopulse и Сашей Орловым, который заглянул на огонек уже на after-party.

Из пожеланий на будущее: все-таки качество должно быть важнее количества, отбор докладов и ограничение числа слушателей возможно помогли бы более эффективному проведению мероприятия, но видимо это и есть формат IT Jam; и мне конечно не хватало тем о тестировании ;)

Право на ошибку

Разработчикам свойственно ошибаться (в силу несовершенной человеческой природы и бла-бла-бла...). Для борьбы с этим было созданно тестирование как средство противодействия влиянию этих ошибок. А как на счет ошибок самих тестировщиков? Кто проследит за ними? Они же тоже люди... Имеют ли они право на ошибку?

Вот например:

Volvo отзывает почти 10 000 автомобилей XC60. Неисправность состоит в возможности "залипания" ремня безопасности к сидению. При этом XC60 является одной из самых безопасных машин на сегодняшний день.

Похожая, но более критическая, ошибка совсем недавно была обнаружена у Toyota - коврик под сидением водителя мог повлиять на ход педали газа. По этой причине отзываются около 4 млн машин, в том числе автомобили высокого ценового сегмента: Avalon, Lexus IS и ES.

Можно только представить во сколько обходятся эти мероприятия компаниям.

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

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

Конечно нельзя перебрать все возможные и невозможные случаи, ничего не упустить и поручиться за протестированную систему на 100%, но все-таки мое мнение, что права на ошибку у тестировщиков нет (по крайней мере так должен считать сам тестировщик), иначе для чего они нужны? ;)

7 напастей тестирования

На днях, благодаря Юлии Нечаевой, перечитала серию постов

The 7 Plagues of Software Testing By James A. Whittaker

Для себя и для тех, кому лень читать - основной смысл:

" 7 напастей тестирования "

1. Бесцельность (тестируем, потому что должны, автоматизируем, потому что умеем, - так принято, а не потому что это говорит нам разум)

2. Повторяемость (прогоняя старые тесты, не замечаем, что они больше не выявляют дефекты)

3. Амнезия (командная - повторяем старые ошибки, не делимся опытом; амнезия индустрии - изобретаем велосипеды)

4. Бездомность (система - как дом, в котором нужно жить, чтобы обнаружить его особенности и проблемы, т.е. проводить тестирование в реальных условиях экстплуатации, чем раньше - тем лучше)

5. Слепота (ПО - невидимо, нам не известно, где ошибка, каково покрытие тестами, какие части были затронуты изменениями)

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

7. и даже больше...

- метрики (искажают цели)

- семантика (часто и неправильно используем термины)

- бесконечность (набор тестов не перестает расти)

- недопонимание (с разработчиками)

- негибкость (привязанность к плану и устоявшимся процессам)

- Энтропия (хаос постоянно растет с нахождением новых ошибок и их исправлением)

С этим всем мы сталкиваемся каждый день, но редко осознаем, еще реже принимаем меры. Давайте объединять усилия в борьбе с заразой ;)