Home

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

Уверен, все вы слышали о «глобальном крахе IT» в середине июля. Это затронуло, прямо или косвенно, большинство из нас. Я не мог воспользоваться банкоматом, рейс моей жены задержали на несколько часов; это были мелкие неудобства по сравнению с тем, что ощутили остальные. Проблему CrowdStrike нескоро позабудут.

Предполагаю, что CrowdStrike никогда не предполагал, что что-то в этом духе может произойти или произойдет. Я также подозреваю, что их предыдущий опыт выпуска подобного контента не нес особых рисков. Но в этом конкретном случае все пошло не так, не правда ли? В социальных сетях многие говорят «вот что происходит, когда у вас нет тестировщиков», «почему они это не протестировали?», и «QA-вакансий теперь станет в разы больше». Эти утверждения и вопросы, возможно, верны, но несколько односторонни. Я тут не для того, чтобы набрасываться на CrowdStrike. Я хочу обсудить риск.

Зачем мы тестируем? Чтобы убедиться в качестве? Нет; в нем нельзя убедиться. Чтобы найти баги? Нет, хотя поиск и оформление багов – ценный результат тестирования. Мы тестируем, чтобы передать информацию людям, принимающим решения – тем, кто решает, готово ли наше ПО к релизу с приемлемым уровнем риска. Как тестировщики, мы сообщаем, что мы протестировали и, что еще важнее, что мы не тестировали, включая реалистичные конфигурации, которые мы не можем скопировать. Мы также сообщаем о своих впечатлениях в ходе тестирования, включая проблемы, потенциальные проблемы, неожиданные изменения и риски, связанные с качеством нашего ПО.

По своей сути тестирование – это вскрытие риска и передача информации о нем. Все эти баги, дефекты, проблемы – это побочные эффекты. Это ценно, но в самом сердце лежит отчетность о рисках.

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

Вот менее очевидные риски:

• Дебаг и исправление проблем занимают много времени, и в результате страдает релизное расписание и повышаются операционные издержки.
• Мы должны выплачивать одному или нескольким заказчикам финансовые штрафы за каждую «крайне значительную» проблему.
• Мы медленнее конкурентов внедряем новые функциональности, потому что наша тест-автоматизация неустойчива, мы теряем к ней доверие и переделываем кое-что вручную.
• Наше приложение позволило ребенку заказать не соответствующий возрасту товар, и теперь о нас трубят все социальные сети, и далеко не с хвалебными одами.
• О нашей компании не рассказал только ленивый журналист – и это, опять же, не хвалебная ода.

Есть, однако, еще один огромный, но неявный риск: отношение к тестированию и, соответственно, тест-автоматизации, как к подтверждающей деятельности. Вне всякого сомнения, подтверждение – это важно; как минимум, ПО должно выполнять ключевые задачи, для которых оно создано. У тестирования и автоматизации есть, однако, другие аспекты, не имеющие отношения к подтверждению – эти аспекты могут выявить потенциальные проблемы, ставящие компанию под угрозу. Нам нужно тестировать сценарии, где все идет не так или может пойти не так. На этой неделе меня пригласили на «вскрытие умирающего»: давайте обсудим, что может пойти не так. Это отличный источник тест-идей и, я надеюсь, подходящий момент для обсуждения, как нам улучшить тестируемость и автоматизируемость.

Дополнительный риск, который многие из нас берут на себя, но очень редко обсуждают – это переключение на нового внештатного партнера. Для переключения могут быть разумные бизнес-причины. До того, как я стал консультантом, я работал в компании, чей на тот момент партнер не успевал за нашими технологическими требованиями; у него просто не было внутренних компетенций, и ему трудно было их приобретать. Мы обсудили наши варианты, описали видимые риски и решили, что более подходящим решением будет переключение. Мы снизили риск, выбрав партнера, с которым наш лидер уже работал – то есть мы что-то о нем знали. Этот партнер специализировался в той же отрасли, что и мы, что снижало риски для нашего расписания – ему понадобится меньше времени, чтобы войти в курс дела. Хотя решениями многих компаний о переключении на новых партнеров, продавцов, инструменты руководят издержки, но в нашем случае решением руководили возможности нашего предыдущего партнера; мы в результате платили консультантам из новой компании чуть больше, но эта разница в издержках позволила нам работать с людьми, обладающими необходимым опытом, что снизило риск дефектов. Я видел, как компании переключаются только из соображений экономии, и им это не сильно помогло – они не озаботились внятным описанием рисков переключения и их снижением.

Итак, что же тут имеет отношение к автоматизации? Автоматизация создана, чтобы помочь тестировщиком быть эффективнее и результативнее. Так как задача тестирования – выявление рисков и сообщение о них, автоматизация помогает тестировщиком выявить эти риски и сообщить о них быстрее, детальнее, учитывая все аспекты приложения. Для получения такой выгоды нам, однако, нужно доверять автоматизации, и в ней должно быть хорошее логирование и отчетность, чтобы снизить время обратной связи.

Риск принимает множество форм. Конкретный риск может быть огромным для одной компании, но низким, приемлемым для другой. Нам нужно выявить максимум рисков, чтобы релизные решения были обоснованными. Полагаю, всем нам хочется, чтобы СМИ трубили о нашей компании только хвалебные оды.

Обсудить в форуме