OpenQuality.ru
Качество программного обеспечения
Добрый день.
Карлос Кастанеда устами Дона Хуана утверждал, что мир, который мы считаем единственным и абсолютным, является лишь одним из множества параллельных миров наподобие слоев в луковице. Он уверял, что все эти сферы иного бытия так же реальны, уникальны и абсолютны, как и наш мир. В древние времена маги разработали систему практических методов, призванных сдвинуть наше восприятие действительности. Сдвиг и закрепление точки сборки позволял увидеть невидимое, услышать неслышимое и прочувствовать реалии других миров.
Попробуем и мы сдвинуть точку сборки и взглянуть на тестирование ПО непредвзятым взглядом.
Нет никакого сомнения в том, что тестирование ПО является важнейшей составляющей процесса создания продукта. Это архиинтересная и нужная деятельность, о чем мы говорили не раз и не два (три, четыре, пять). Ведущие эксперты отрасли подчеркивают важность наличия тестировщиков в команде проекта и несомненную пользу от их присутствия (шесть, семь, восемь, девять, десять).
Все замечательно, но наличие тестировщиков не отменяет одну простую вещь: Quality Assurance Is Not Responsible For Quality. Основатели школы контекст-ориентированного тестирования Кaner, Bach & Pettichord в книге “Lessons Learned in Software Testing” пишут: “You don’t create quality, and you don’t take it away. You may talk as if you “break the product”; the truth is it came to you already broken… Your test results and bug reports provide information that facilitates the assurance of quality on the project, but that assurance results from the effort of the entire team”. Иными словами, вот здесь у вас баги, получите, распишитесь. Потом мы снова проверим и может быть еще что-нибудь найдем. Такой подход нравится не всем.
К примеру, аналитик Mike Gualtieri предлагает полностью отказаться от QA-команды: “I recently spoke with a client who swears that software quality improved once they got rid of the QA team”. Как же так? Какая от этого польза (кроме сокращения расходов)? “The client said that this works because the developers know that they have 100% responsibility for the application. If it doesn’t work, the developers can’t say that “QA didn’t catch the problem.” There is no QA team to blame. The buck stops with the application development team. They better get it right, or heads will roll.”
Ну хорошо, разработчики жили-не тужили, их код проверяли тестировщики, а тут раз – и тестировщиков нет. Самим себя проверять? Мартин Фаулер, один из создателей методологии TDD, спешит на помощь. Мартин полагает, что тесты пишут до исходного кода, и впоследствии эти тесты обеспечивают регрессионную проверку функциональности. У модульных тестов есть свои плюсы и минусы, но в целом они способны более эффективно решать часть задач по обеспечению качества, которые обычно возложены на тестировщиков. Мартина не удержать: “Manual scripted testing should be a human rights violation.”
И дело не столько в наличии/отсутствии модульных тестов, сколько в принципиально ином подходе к разработке и качеству кода. Uncle Bob пишет: “But it has generally not been business that has demanded crappy code. Rather it has been developers who mistakenly thought that the business’ need for speed meant that they had to produce crappy code. Once we, as professional developers, realize that the only way to go fast is to create clean and well designed code, then we will see the business’ need for speed as a demand for high quality code.”
Да что эти разработчики и аналитики понимают? Мы же не идем к сапожнику, когда у нас ухо болит. Богу – богово, кесарю – кесарево. Что о тестировании ПО думают сами тестировщики?
Catherine Powell, начинавшая свою карьеру тестировщиком и добившаяся серьезных успехов в теории и практике тестирования, не нанимает тестировщиков вот уже пять лет: “Increasingly, I have other people who are embracing the tasks that used to be reserved for a dedicated tester: developers have survived while writing test automation; product owners have been eager to use the product in a structured way; customer service reps and implementation managers have been able to provide additional context about application usage and behavior; improved monitoring points out problems in dev, QA and production, and makes the patterns behind them apparent so debugging is a lot easier.” И далее “Now, for some applications I’d still hire a tester. I’d make that hire when I needed that kind of specialized knowledge. But that knowledge is becoming less and less specialized as more people start listening to the mantra that “quality is everyone’s responsibility”. We’re seeing more people who test, even as I’m around fewer testers.”
Michael Kelly, рассуждая об инструментах тестирования ПО, пишет: “We do track test cases and defects, instead of coverage and risk, because they are easier to track with the tools we have.” Семь раз отмерь, один раз отрежь. А то резать, мерять, резать, мерять…
Ну что тут взять с теоретиков, блоггеров, перевертышей? Волну гонят. Как обстоят дела в индустрии?
Вот информация о Facebook: “Facebook has revealed that it does not have a QA team to test its software including user interface designs for privacy issues and usability before setting it loose on the great unwashed.” Код покрыт автотестами (PHPUnit, Watir), создание которых – неотъемлемая задача разработчика.
В Google есть Test Engineers, но даже они пишут код. Более того, в Google практикуется вероятностный подход к обнаружению багов: “Bug prediction uses machine-learning and statistical analysis to try to guess whether a piece of code is potentially buggy or not, usually within some confidence range.” Если баг пройдет сквозь сито модульных тестов, то попадется в сети алгоритма Рахмана (Rahman algorithm). Или в лапы благодарных пользователей :)
В Etsy разработчики несут полную ответственность за свой код: “At Etsy, development make production changes themselves, and this has the effect of bringing them closer to production, which enables having an operability mindset. This is opposed to having a ship-to-QA-and-consider-it-done mindset. Developers deploying their own code also brings accountability, responsibility, and the requisite authority to influence production.”
Максим Крамаренко, руководитель команды разработчиков TrackStudio, подчеркивает: “У нас нет своей команды тестировщиков. Перед выпуском бета-версии мы инсталлируем новую версию системы на свой сервер и активно используем несколько недель. Параллельно разработчики занимаются тестированием с применением средств покрытия кода (code coverage), мы устраиваем соревнования «кто быстрее достигнет заданного уровня покрытия».”
За каждым программным продуктом стоят заказчики, аналитики, разработчики, продажники. Да, они хотят качественный продукт, но таким они его хотят видеть сразу. И снова Uncle Bob: “I see software developers working together to create a discipline of craftsmanship, professionalism, and quality similar to the way that doctors, lawyers, architects, and many other professionals and artisans have done.” Безусловно, значительная часть проектов – инновационные. Более того, видение продукта в финальной стадии цикла разработки может кардинально отличаться от первоначальных требований. И в то же время разработчики продукта хотят отрезать один раз (как врачи, адвокаты и архитекторы в цитате Боба) и постепенно готовят для этого соответствующую инфраструктуру, позволяющую добиваться приемлемого качества даже в условиях меняющихся условий задачи и сжатых сроков.
В китайской медицине принято, что пациент платит врачу когда он абсолютно здоров и не платит в период плохого самочувствия. Врач не наживается на пациенте, избавляя его от хворей, а старается их предотвратить. Нам это кажется странным? Но для китайцев это естественный уклад жизни.
Нужны ли тестировщики сегодня? Нужны. Будут ли они нужны завтра? Будут. Изменится ли что-либо в их функциональных обязанностях? Изменится. Какие знания и навыки будут наиболее востребованы? Об этом мы поговорим в другой раз. Первое апреля – не лучший день для разговоров о будущем :)
Что такое качество программного обеспечения и как его улучшить: теория и практика, задачи и решения, подводные камни и обходные пути.
Автор комментария : Алексей Лупан | April 2, 2012
Тут один феномен подменяется другим феноменом.
Нет тестировщиков как выделенной группы узкоспециализированных людей, но есть тестирование как процесс и как работа, которую в любом случае надо выполнять.
Иногда эту работу делают все участники проекта, и этого бывает достаточно.
Иногда эту работу делают пользователи.
Сказать “У меня в команде нет выделенных тестировщиков, и у меня все хорошо” - это как сказать “Я не пью пива, поэтому у меня все хорошо, я потребляю героин, поэтому мой вам совет - не пейте пива”.
PS Разве comedia пишется с двумя ‘m’?
[Ответить]
Автор комментария : Капитан | April 2, 2012
Алексей, спасибо за комментарий.
Не совсем понятно, кому из процитированных персонажей можно однозначно приписать эти строки: “У меня в команде нет выделенных тестировщиков, и у меня все хорошо”. Возможно, никому, а возможно и всем. Да, такой подход вполне имеет право на жизнь. Да, у кого-то может не быть выделенных тестировщиков, а продукт успешен, все счастливы. Вот и хочется заглянуть чуть-чуть вперед, чтобы понять насколько сильна эта тенденция, и какие изменения могут ожидать тестировщиков.
Commedia – да, с двумя “m” в итальянском языке.
[Ответить]
Автор комментария : Алексей Лупан | April 3, 2012
Да нет финиты у этой комедии :) Тенденция - не тенденция, это один из аспектов, которые интересно обсуждать “промежду прочим”, не более.
ЗЫ
Не получаю ответ на емайл на тутошние комментарии. Надо ли это дело исправить?
Итальянский - да, ок.
[Ответить]
Капитан отвечает:
April 7th, 2012 в 2:17 pm
Надеюсь, этот комментарий достигнет адресата. Как говорится, лучше позже чем никогда.
[Ответить]
Автор комментария : Капитан | April 4, 2012
Алексей,
На самом деле, тенденции, аспекты, феномены – это все такие buzzwords, в которые каждый вкладывает свой смысл. И я в том числе. Мне эта тенденция кажется важной – каждый ее аспект и феномен :)
[Ответить]
Автор комментария : Ochir | April 4, 2012
Знаете, в целом я с Вами согласен, хотя, не согласен, с тем, что некоторые из вышеперечисленных компаний поступают правильно.
Ожидаю в будущем, что большая часть тестирования будет выполняться во время разработки, будет улучшаться статический и динамический анализ кода, языки станут более устойчивыми к ошибкам, среды разработки и компилятры будут детектить большее количество багов во время написания кода,
и количество времени на тестирование будет уменьшаться.
Мне кажется, что требования к QA инженерам будут меняться, много автоматизации, особенно веб, большее внимание будет уделяться методам по выявлению багов и скорости их устранения, сбору и анализу метрик от пользователей, деплойменту.
[Ответить]
Автор комментария : Капитан | April 4, 2012
Ochir, спасибо за комментарий.
Вполне с вами согласен.
[Ответить]
Автор комментария : Алексей Лупан | April 9, 2012
да, этот комментарий достиг адресата :)
[Ответить]