OpenQuality.ru
Качество программного обеспечения
C момента публикации знаменитой статьи “Top Five (Wrong) Reasons You Don’t Have Testers” (Joel Spolsky) прошло 8 лет. Как явствует из названия, Joel назвал пять причин, которые выдвигались в оправдание отсутствия тестировщиков при разработке программных продуктов. В вольном переводе:
Развенчав эти мнимые причины, Joel завершает свою статью так:
Skimping on testers is such an outrageous false economy that I’m simply blown away that more people don’t recognize it.
Иными словами, скупой платит дважды. Хм, а не изменилась ли ситуация сейчас, в 2008 году? Уменьшилась ли потребность в тестировщиках в связи с выходом на первый план TDD и успехов на ниве автоматизации тестирования? Обратимся к опыту Microsoft. В своей статье Joel пишет:
My first real software job was at Microsoft; a company that is not exactly famous for its high quality code, but which does nonetheless hire a large number of software testers. So I had sort of assumed that every software operation had testers.
Качество кода, по словам Spolsky, оставляло желать лучшего, но, как бы то ни было, в компании Microsoft в те годы работало большое количество тестировщиков, вносивших существенный вклад в разработку продуктов. Позиции Microsoft были сильны. Windows 2000 и Windows XP считались довольно зрелыми платформами и успешно отражали стрелы, выпущенные из стана Novell и Unix. Гигант и сейчас жив, крепко стоит на ногах, но Windows Vista справедливо вызывает множество нареканий. Возможно, одной из причин неудачного старта OS Vista стала политика Microsoft в отношении тестирования программных продуктов. Косвенным (возможно, субъективным) cвидетельством смены курса может служить блог Microsoft’s JobsBlog, в котором давно не встречается рассказов про тестировщиков. Исключением является нечастое упоминание аббревиатуры SDET (Software Developer in Test), но вот что о них говорит сотрудник Microsoft:
Most SDETs don’t do unit-test type work—developers would do that sort of stuff. SDETs work on a higher level, creating automation that may programmatically operate a user interface or that may put stress on a server or web service. The work complements unit testing in creating automation for customer scenarios that may not necessarily be covered in the unit testing scenarios.
Итак, SDET ни в коем случае не пишет unit-тесты, он автоматизирует сценарии работы пользователя на более высоком уровне. На самом деле, такая работа заслуживает всяческого уважения, и о несомненной пользе автотестов мы уже говорили. Но вот достаточно ли автоматизировать проверку конечного числа сценариев, чтобы обеспечить usability и надежность операционной системы? Хочется надеяться, что вдумчивому тестированию продуктов в Microsoft уделяется достаточно внимания, а ситуация с Vista - лишь досадное стечение обстоятельств. Вот добрый знак: James Whittaker, Software Architect в Microsoft, ратует за более глубокое вовлечение тестировщиков в процесс дизайна приложений. В компании есть светлые головы, - считает James, - важно лишь заботиться о качестве программного обеспечения с самого начала его разработки.
Теперь попробуем ответить на вопрос, поставленный в начале статьи. Изменилась ли потребность в тестировщиках за последние 8 лет? Да, потому что (наряду с появлением TDD и мощных инструментов для автоматизации) программные системы стали сложнее. Да, потому что еще больше необходим острый критический взгляд на создаваемые продукты. Потребность в тестировщиках как минимум не уменьшилась, но должен измениться сам тестировщик. Для острого критического взгляда нужно время, и это время нежелательно тратить на регрессионные проверки. Навыки написания автотестов сослужат хорошую службу и тестировщику, и продукту.
Закончить статью хочется словами одного из основоположников контекст-ориентированного подхода в тестировании. James Bach создавал продукты в Apple и Borland, и потому его мнение как разработчика достаточно интересно. Вот три выдержки из его комментариев к статье “What is Test Automation?”:
Different people may test for different reasons. Testing may have a variety of missions. For my projects it’s usually this: testing is the headlights of the project. We want test because we need to know the status of the product as it travels the “highway” of the project and into the wider world.
…
Asking me why I test is like asking me why I stare out the windshield while driving my car. I don’t want to hit stuff. That’s why.
…
It’s not wind protection I was thinking of, dude. It’s the seeing. Try driving without having any idea where you are or what you are going to run into, eh? That’s my point. In general systems terms, a software project is a cybernetic system. Although it’s possible in principle to produce good software without looking at it, it’s not practical (try and see).
Лучше и не скажешь. Оставайтесь с нами.
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
Pingback : OpenQuality.ru | Автотесты: мифы и реальность | October 17, 2008
[…] Миф: Автотесты способны полностью заменить ручное тестирование. Реальность: Оснований верить такому утверждению ровно столько же, сколько верить в существование серебряной пули. Автотесты не могут быть панацеей (и профилактикой) от всех багов, живущих в программном продукте. Верите ли вы в то, что напичканный электроникой робот способен определить все недомогания в человеческом организме и оперативно от них избавить? Вот было бы здорово. Но на самом деле интуицию, опыт, мышление врача такой робот не заменит. Зато он способен избавить эскулапа от выполнения рутинных действий, которые можно четко обозначить и регламентировать. То же самое в тестировании. […]
Pingback : OpenQuality.ru | Мастерство тестировщика: перепросмотр | October 1, 2009
[…] интеллектуальный сервис, без которого зачастую не обойтись. Но это производный сервис, надстройка над базисом. […]
Pingback : OpenQuality.ru | Качество программного обеспечения | April 1, 2012
[…] и нужная деятельность, о чем мы говорили не раз и не два (три, четыре, пять). Ведущие эксперты отрасли […]