Что представляет собой тестирование
Тестирование программного обеспечения — это проверка соответствия реальных и ожидаемых результатов поведения программы, осуществляемая на конечном наборе тестов, выбранном определенным образом.
Говоря более широко, тестирование — это одна из техник контроля качества, которая включает активности по планированию работ, проектированию тестов, выполнению тестирования и анализу полученных результатов.
Тестировщик — специалист, который занимается тестированием. В его обязанности входит поиск возможных ошибок и сбоев в функционале тестирования объекта (например, приложения)
Тестировщик моделирует ситуации, вероятные при использовании тестируемого объекта, чтобы потом разработчики могли устранить обнаруженные неполадки.
Инженер-тестировщик — это человек, решающий проблемы технического характера, связанные с разработкой ПО. Он и пользователь, и эксперт в одном лице: он должен быть способен как воспроизвести действия пользователя, так и проанализировать с точки зрения инженера поведение программы, входные параметры и результаты на выходе.
Очевидно, что если продукт не тестировать, в нем будут ошибки. Что будет, если сэкономить на тестировании ?
- Пользователи будут недовольны.
Если сервис не решает задачи пользователей, они будут злится. - Сервис потеряет аудиторию.
Пользователь уйдет к конкурентам, если приложение работает плохо. - Бизнес потеряет репутацию и деньги.
Никто не захочет инвестировать в плохой бизнес.
Интересный факт
Наглядный пример, когда дефект привел к потере 125 млн долларов: в 1999 году спутник «Mars Climate Orbiter» распался в атмосфере. Оказалось, что разработчики забыли перевести английские единицы измерения в метрические.
Основные «эпохи тестирования»
В 50-60-х годах процесс тестирования был предельно формализован, отделен от процесса непосредственной разработки ПО и «математизирован». Фактически тестирование представляло собой скорее отладку программ (debugging). Существовала концепция «исчерпывающего тестирования (exhaustive testing)» — проверки всех возможных путей выполнения кода со всеми возможными входными данными. Очень скоро было выяснено, что исчерпывающее тестирование невозможно, т.к. количество возможных путей и входных данных очень велико, а также при таком подходе сложно найти проблемы в документации.
В 70-х годах фактически родились две фундаментальные идеи тестирования: тестирование сначала рассматривалось как процесс доказательства работоспособности программы в некоторых заданных условиях (positive testing), а затем — строго наоборот: как процесс доказательства неработоспособности программы в некоторых заданных условиях (negative testing). Это внутреннее противоречие не только не исчезло со временем, но и в наши дни многими авторами совершенно справедливо отмечается как две взаимодополняющие цели тестирования.
• Тестирование позволяет удостоверится, что программа соответствует требованиям;
• Тестирование позволяет определить условия, при которых программа ведет себя некорректно.
В 80-х годах произошло ключевое изменение места тестирования в разработке ПО: вместо одной из финальных стадий создания проекта. Тестирование стало применяться на протяжении всего цикла разработки, что позволило в очень многих случаях не только быстро обнаруживать и устранять проблемы, но даже предсказывать и предотвращать их появление. В этот же период времени отмечено бурное развитие и формализация методологий тестирования и появление первых элементарных попыток автоматизировать тестирование.
В 90-х годах произошел переход от тестирования как такового к более всеобъемлющему процессу, который называется «обеспечение качества (quality assurance)», охватывает весь цикл разработки ПО и затрагивает процессы планирования, проектирования, создания и выполнения тест-кейсов и тестовых окружений.
Тестирование вышло на качественно новый уровень, который естественным образом привел к дальнейшему развитию методологий, появлению достаточно мощных инструментов управления процессом тестирования, уже вполне похожих на своих нынешних потомков.
В нулевые годы развитие тестирования продолжалось в контексте поиска все новых и новых путей, методологий, техник и подходов к обеспечению качества.
Серьезное влияние на понимание тестирования оказало появление гибких методологий разработки и таких подходов, как «разработка под управлением тестированием (test-driven development, TDD)».
Автоматизация тестирования уже воспринималась как обычная неотъемлемая часть большинства проектов, а также стали популярны идеи о том, что во главу процесса тестирования следует ставить не соответствие программным требованиям, а её способность предоставить конечному пользователю возможность эффективно решать свои задачи.
О современном этапе развития тестирования стоит отметить основные характеристики: гибкие методологии и гибкое тестирование, глубокая интеграция с процессом разработки, широкое использование автоматизации, колоссальный набор технологий и инструментальных средств, кроссфункциональность команды (когда тестировщик и программист во многом могут выполнять работу друг друга).
Цель тестирования
Цель тестирования — это проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Обнаружение и исправление ошибок составляет 40-80% общей стоимости разработки ПО. Такие большие средства тратятся на поиск и устранение ошибок, которые есть в любом продукте
Цель тестировщика — найти максимально возможное количество ошибок, и чем серьезнее обнаруженные проблемы — тем лучше. В итоге, максимум ошибок исправляется, и качество ПО повышается.
Баг
9 сентября 1945 года Грейс Мюррей Хоппер проверяла первый компьютер Mark на неисправности. Оказалось, что внутри застрял мотылёк.
В этот момент в комнату вошел сослуживец и поинтересовался, чем занимается Грей.
Она ответила, что очищает компьютер от насекомых (англ. bug — насекомое, debugging — избавление от насекомых).
Насекомое было извлечено и вклеено в дневник с сопроводительной подписью «Первый реальный случай обнаружения бага». От этого случая и пошло слово bug, а этот день стал днём бага (и заодно днём тестировщика).
Баг — это несоответствие ожидаемого и фактического результатов проверок сервиса.
Ожидаемый результат (ОР) — то, как сервис должен работать согласно требованиям.
Фактический результат (ФР) — то как сервис работает на самом деле
Дальше материал в данном уроке можете не конспектировать, рекомендуется к прочтению
Крупные баги в истории
Y2K — проблемы тысячелетия
Проблема Y2K ещё известна как «проблема 2000 года». Разработчики ПО в XX веке часто использовали для обозначения года в датах две последние цифры вместо привычных четырёх. Например, 7 апреля 1994 года представлялось как «07.04.94».
Так информация хранилась более эффективно — ведь в то время каждый байт был на счету, а базы данных могли хранить тысячи дат. В таком случае сокращение было разумным решением. Или нет?
1 января 2000 по всему миру начали происходить локальные конфликты и сбои в системах. В некоторых городах даже начало пропадать электричество, отопление, часть вычислительных центров просто зависала. Всё это произошло из-за сокращения формата года. После 1999 года наступил 2000, но для машин этот год воспринимался как 1900 (у некоторых даже как 19100). Такая ошибка послужила причиной зависаний во многих системах.
Однако никакой масштабной мировой катастрофы не произошло благодаря тому, что разработчики начали задумываться об этой проблеме заранее. По некоторым оценкам, на подготовку к 2000 году общие мировые затраты составили 300 млрд. долларов.
Торговля — трудное ремесло
В самом начале на Amazon можно было заказать отрицательное количество товара. В таком случае при покупке деньги не списывались, а зачислялись на карту клиента. Такая глупая ошибка случилась из-за того, что разработчик магазина Джефф Безос старался как можно чаще выпускать обновления для своего сервиса и у него не хватало времени на его отладку.
Как отмечает сам разработчик, это одна из его любимых ошибок: «Мы переводили покупателям деньги и, соответственно, ждали, когда этот товар доставят нам».
Примитивные баги в программах случались и в других интернет-магазинах. Иногда можно было выставить в поле «Количество товара» значение 0,01 и тем самым получить скидку на товар в 99%. А в некоторых сервисах персональные данные хранились в файлах cookie. Можно было изменять ID покупателя и совершать покупки от другого лица.
Падение телефонной линии A&T
Один из 114 коммутаторов AT&T был механически повреждён. Он отправил сообщение о поломке другим АТС, а те, в свою очередь, соседним. Запустилась цепная реакция, которая положила телефонную сеть на 9 часов, из-за чего 60 тыс. человек остались без связи.
Причина была в недавнем обновлении ПО для АТС. Теперь, если ломался один из коммутаторов, он посылал об этом сообщения соседним коммутаторам, чтобы те перехватывали его трафик. Тогда другие коммутаторы должны были перезагружаться в новый режим работы и периодически проверять, не заработал ли первый.
Однако из-за бага в коде неисправный коммутатор высылал по два сообщения. Второе сообщение достигало других коммутаторов прямо во время их перезагрузки. Из-за этого они начинали думать, что сами неисправны и рассылали сообщение дальше по цепи. Таким образом, словно домино, упала целая сеть. Общие потери компании составили примерно 60 млн. долларов.
Взрыв ракеты Ariane 5 из-за переполнения переменной
Авария ракеты-носителя «Ариан-5» произошла 4 июня 1996 г. Ракета разрушилась на 40-й секунде полёта из-за неверной работы бортового ПО. Этот баг в системе — самый дорогостоящий в нашем топе багов и вообще в мире — его ущерб оценивается от 360 до 500 млн. долларов. В результате аварии были также потеряны 4 спутника Cluster.
Во время разработки бортового программного обеспечения некоторые фрагменты кода были взяты из ПО предыдущей удачной Ariane 4. Однако софт так и не протестировали в новом окружении. После старта ракеты её модуль попытался просчитать определённое значение, исходя из горизонтальной скорости ракеты. Так как эта скорость у Ariane 5 была намного выше, чем у предыдущей версии, это вызвало переполнение переменной, что, в свою очередь, повлекло ошибки. На борту была запасная система управления, но т. к. в ней было идентичное ПО, ошибка повторилась.
Работы над строительством ракеты велись на протяжении 10 лет, а на разработку было потрачено 7 млрд. долларов.