Так объясняют про тестирование в компании Edison.
Недавно я участвовал в профориентационном лагере для школьников. Меня попросили рассказать про Хабр и про то, какие есть ИТ-специальности и что будет в будущем.
Как школьнику рассказать, кто такой тестировщик и зачем нужен процесс тестирования?Я как-то выкрутился, но чувство незавершенности осталось и по сей день.
На Хабре шикарно умеют объяснять почему трава зеленая или почему программист это супергерой. Если бы вы объясняли 10-класснику, кто такой тестировщик, как бы вы описали этот процесс?
(Есть замечательная книга Сеймура Пейперта «Переворот в сознании: Дети, компьютеры и плодотворные идеи», где рассказывается о том, как сформировать в мышлении детей хорошие стратегии отладки, но эта книга достойна отдельной статьи ->)
«Пугать надо» — посоветовали мне бывалые. Ну что ж, сделал подбоку самых сочных программистских ошибок.
Ошибка №1
22 июля 1962 Года. Неудача при запуске первого американского спутника к Венере «Mariner 1» случилась из-за ошибки в программе на языке Фортран – в операторе цикла вместо запятой программист поставил точку:
правильный оператор DO 50 I = 12,525
оператор с ошибкой DO 50 I = 12.525
«Умный» компилятор не выдал ошибку, а интерпретировал данную конструкцию как оператор присваивания. В результате, станция массой 202,8 кг при взлете спустя 293 сек ракета отклонилась от курса и произошла авария.
Но это ложь.
Есть легенда (впрочем, неподтвержденная), что подобная ошибка была в одной из программ НАСА для вычисления орбиты, однако это программа использовалась в проекте Меркурий, а не Маринер, и эта ошибка была исправлена до запуска корабля.
На самом деле Nasa заявило:
Ошибка появилась при ручном переводе символа в спецификации программы наведения. Писавший пропустил макрон или надчёркивание в
что значит «n-ое сглаживание значения производной радиуса R по времени». Без функции сглаживания, обозначаемой макроном, программа воспринимала нормальные небольшие изменения скорости как очень серьёзные, что вызывало лишние поправки, сбивавшие ракету с курса. Затем ракета была уничтожена офицером курсовой безопасности. Но и это (возможно) ложь. [пруф — «Самый дорогой дефис в истории»]
Кто виноват? Тестировщики недосмотрели.
- Советский «Космос-419» был в мае 1971 г. выведен на орбиту Земли, откуда он должен был стартовать к Марсу, однако в бортовой компьютер было введено ошибочное значение времени запуска двигателя — в формате не минут, а часов, что привело к потере аппарата. Буквально через неделю произошло второе ЧП — бортовая система отечественной станции «Марс 2» в момент отстыковки от корабля-матки, расположившегося на орбите Красной планеты, получила ошибочные данные о параметрах приземления и не смогла выполнить задание.
- В 1985–87 гг. 6 человек получили смертельную дозу облучения во время сеансов радиационной терапии с применением медицинского ускорителя Therac-25. Расследование показало, что непосредственной причиной инцидентов была программная ошибка, однако основные ошибки были сделаны на стадии проектирования оборудования и системы автоматизации.
- 2 сентября 1988 года Потеря связи с советской космической станцией «Фобос-1» на трассе Земля-Марс произошла из-за ошибочной команды, переданной с Земли на бортовой компьютер.
- 1988 год, причиной осложнений, возникших при возвращении на Землю из космической экспедиции советско-афганского (29 августа — 21 декабря 1988) и советско-французского (26 ноября — 27 апреля 1988) экипажей, явились ошибки, допущенные в программном обеспечении бортовых компьютеров.
- В 1991 г. ракетная установка MIM-104 Patriot не заметила вражескую ракету Scud, которая уничтожила в казарме г. Дахрен (Судовская Аравия) 28 американских солдат. Бортовая система Patriot работает с накапливаемой ошибкой в системных часах, и в процессе длительного нахождения на боевом дежурстве погрешность достигла 0,3 с, что привело к пропуску быстро двигавшейся ракеты.
- В 1994 г. погибло 29 человек в результате аварии английского военного вертолета Chinook, который разбился из-за сбоя в бортовой навигационной системе, неверно определившей высоту полета.
- 4 июня 1996 г Первый запуск ракеты-носителя Ariane 5 – детища и гордости Европейского Сообщества закончился взрывом через неполные 40 сек. полета. Автоподрыв 50-метровой ракеты произошел в районе ее запуска с космодрома во Французской Гвиане. Расследование показало, что причиной аварии стала допущенная (и не выявленная при тестировании) программная ошибка, связанная с некорректным повторным использованием программного обеспечения и отсутствием точной спецификации повторно-используемого модуля.
- 1999 год, Аппарат для исследования Марса Mars Climate Orbiter был запущен 11 декабря 1998 года. Следом за ним был также запущен Mars Polar Lander — 3 января 1999. Оба аппарата были потеряны вскоре после того, как они достигли красной планеты. Эти два космических корабля стоили NASA около 327,6 миллиона долларов, потраченных на их создание и функционирование. Причина аварии Mars Polar Lander осталась невыясненной. Причина потери Mars Climate Orbiter заключается в программно-человеческой ошибке, которая привела к тому, что одно подразделение участвовавшее в проекте считало «в дюймах», а другое — «в метрах», причем выяснилось это уже после потери аппарата.
- Запуск ракеты-носителя «Зенит» 12 марта 2000 года по программе «Морской старт» (Sea Launch) закончился он аварией. Через несколько минут после старта ракета «Зенит» отклонилась от курса и не смогла вывести на заданную орбиту первый спутник для системы сотовой телефонной связи ICO Global Communications. После аварии участники консорциума Sea Launch образовали несколько комиссий для расследования ее причины. В опубликованных выводах экспертов компании Боинг причиной сбоя называется программная ошибка. Из-за этой ошибки не был закрыт клапан в пневматической системе второй ступени ракеты. Эта система ответственна за выполнение нескольких операций, в том числе за работу рулевого двигателя этой ступени. Из-за того, что клапан не был закрыт, давление в пневматической системе упало больше, чем на 60% от заданного. Поэтому двигатель не смог развить необходимую тягу, а ракета, соответственно, не смогла выйти на заданную орбиту.
- На заводе по переработке урана в Западной Австралии в конце декабря 2001 года произошел выброс радиоактивного вещества. Расследование инцидента показало, что произошел он из-за «логической ошибки» в программном обеспечении компьютеров, установленных на заводе. Разработчиком этого ПО является компания Amec Engineering. Как сообщается, из-за этой ошибки во время проведения регламентных работ произошло отключение питания системы жидкостного охлаждения. В этой ситуации должны были автоматически отключиться насосы, качающих охлаждающую жидкость, но этого не произошло. Прежде чем персонал успел сделать это вручную, давление в трубопроводах возросло, и один из них не выдержал. По заявлению компании Heathgate Resources, обслуживающей завод, софтверная фирма Amec исправила ошибку в ПО и вновь проверила работу всей компьютерной системы завода. Название программного продукта, в котором была обнаружена ошибка, не сообщается.
- Американский аппарату Mars Global Surveyor, прибыл к Красной планете в 1997 г. Аппарат прекратил функционирование в ноябре 2006 г.: из-за ошибка адресации бортового ПО произошел перегрев батареи с последующим отказом других устройств.
- 11 февраля 2007 г. 12 истребителей-«невидимок» F-22 перелетали с военной базы США на Гавайях в Японию. В момент пересечения международной временной границы на всех машинах из-за программной ошибки отказали бортовые компьютеры. Известны также случаи, когда вследствие программной ошибки истребители F-16 в режиме автопилотирования переворачивались «вверх ногами» при преодолении экватора.
- 5 декабря 2010 года: Три спутника, критически важные для завершения составления группировки российской навигационной системы ГЛОНАСС — конкурента американской GPS — упали в Тихий океан недалеко от Гавайских островов вскоре после их запуска ракетой «Протон-М». Финансовые потери оцениваются в 4 миллиарда рублей (138 миллионов долларов). В результате расследования виной аварии была признана ошибка в программировании, которая привела к тому, что в ракету залили неправильное количество топлива.
Еще про ошибки интересно и подробно написано в этой книге:
В сети есть Глава 2
Основная трудность со школьниками в том, что у них нет своих эпик фэйлов и непросто апеллировать к их личному опыту, остается лишь прибегнуть к чужим историям или рассказам, а потом направлять обсуждение темы тестирования.
Олдскульный рассказ про прирожденного тестировщика
Идеальный тестер
Любой сотрудник некрупной IT-компании подтвердит, что четверг – самый скучный день недели. В самом деле — в понедельник все разгребают пришедшую за выходные почту, ругаются с поставщиками кофе и воды для кулера, и курят на лестнице, рассказывая друг другу анекдоты для борьбы со сном и похмельем. Во вторник задачи розданы, силы свежи, и код пишется на одном дыхании. В среду количество полезной работы за единицу времени достигает своего апогея… Пятница, естественно, проходит под знаком ожидания чьего-нибудь дня рождения или просто пивной вечеринки, поэтому квака начинается с самого утра, и большинство народу даже не делает вид, что работает. Те немногие, кто затрудняется имитацией деятельности, держат Экслера или RSDN открытым в пятом окне эксплорера, чтобы в таскбаре не было видно адреса.
А вот четверг – это момент кризиса. Переход от работы к удовольствию. Начинать читать обзоры фильмов еще рановато, а работать не дают мысли о завтрашней пятнице.
Этот четверг ничем не отличался от обычных. Часов с 12 я начал испытывать просто нестерпимое желание найти повод поотлынивать. Поэтому когда в аське всплыл вопрос шефа «Не хочешь пособеседовать тестеров?», я долго не думал.
Напрягаться я не собирался, благо «собеседников» и без меня было вполне достаточно – технический директор, директор по маркетингу и главный (он же единственный) сисадмин.
Заливая четвертую за сегодня кружку Nescafe Gold водой из кулера (наш народ зовет эту жидкость смолой, за цвет, вкус и консистенцию), я пообщался с директорами и выяснил, что, во-первых, место у нас одно, а во-вторых, кандидатов двое. Такой высокий конкурс директор по маркетингу объяснял грамотным проведением рекрутинговой кампании (он сам составлял макет объявления для нашего сайта), а технический директор – замедлением падения курса доллара. Поскольку мы работаем на заказчиков, не говорящих по-русски, за курсом доллара наши сотрудники следят пристальнее, чем ребята из Редмонда за курсом акций Microsoft.
Налив себе кофе, мы переместились в конференц-зал.
Первым кандидатом оказалась симпатичная девушка в джинсах и свитере. Я пропустил мимо ушей ее резюме, обратив внимание лишь на упоминание какого-то сертификата Quality Assurance Engineer. Во время собеседования девушка вела себя довольно-таки уверенно, то и дело поминала Transition Phase, CMM, ISO9000 и трехлетний опыт работы. Все это время я смотрел в окно и думал о том, что сидеть она будет в комнате через коридор, и что я не смогу использовать обычный лексикон при объяснении тонких моментов тест-плана.
Вторым был парень-студент, во взгляде которого читалась острейшая нужда в денежных средствах. На этот раз я принял участие в собеседовании и узнал, что он – гениальный программист и веб-дизайнер, что у него даже есть свой сайт, и что он сейчас пишет IDE для PHP на MAC. Я бы выяснил, почему он предпочитает MAC, но поймал взгляд технического директора и свернул беседу.
После ухода кандидатов мы несколько минут поспорили о проблемах девушек в чисто мужских коллективах и проблемах излишней амбициозности читателей журнала ксакеп, и сошлись на том, что «теперь хоть матов будет меньше», — девушка была очевидным выбором. Мы уже направились к выходу, когда у технического зазвонил мобильник. Обменявшись парой реплик со своим собеседником, технический зажал микрофон рукой и шепотом известил нас о том, что у входа в офис ждет еще один кандидат. Мы переглянулись. Решение было уже принято, но как-то неудобно было давать от ворот поворот человеку, не поленившемуся притащиться к нам на окраину. Технический велел охране впустить, и мы вернулись в конференц-зал.
Третий кандидат выглядел немного моложе моих лет. Улыбнувшись, он представился и сел в кресло, бросив папку на стол. Маркетинговый директор порылся у себя в бумагах и спросил:
— Извините, я что-то не вижу вашего резюме. Вы не присылали его нам?
— Присылал, — ответил кандидат, с интересом оглядываясь вокруг, — Но у вас почтовый сервер глючит.
Это было не очень хорошее начало. Мы все-таки IT-компания, и достаточно тщательно следим за тем, чтобы у нас все работало. Если у него нет резюме – пусть так и скажет и не тратит наше время. Технический директор с некоторой даже обидой спросил:
— Может быть, проблема все же не в сервере? Со связью что-нибудь, или почтовый клиент не сработал? Вы, кстати, не с мейл.ру отправляли?
— Нет, — ответил кандидат, продолжая оглядываться. Его внимание привлекла настольная лампа. Щелкнув пару раз выключателем, он сказал: «Смотрите-ка!» – и полез под стол. Лампа вспыхнула и перегорела. Кандидат вылез из-под стола и продолжил:
— Если оставить выключатель в промежуточном положении, а потом включить шнур в розетку, лампа перегорит!
— Спасибо. Может быть, вы принесли резюме с собой? — поинтересовался я.
— Да, конечно, вот оно, — он подал лист А4, — а вот это — распечатка ответа вашего почтового сервера, — он подал еще один лист.
Сисадмин с интересом взял его из моих рук и пробежал глазами:
— Но!.. А как?.. Странно… Я сейчас! — с этими словами он почти выбежал из комнаты.
Директора тем временем изучали резюме. Я смотрел на кандидата. Он повернулся назад, и что-то настраивал в кресле. Это было обычное пятилапое офисное чудовище на колесиках, распространитель сколиоза и отложения солей. Наконец в кресле что-то щелкнуло, и потенциальный тестер оказался на полу. Это, казалось, ничуть его не расстроило:
— Я так и знал! Дефект в системе регулировки пневматического амортизатора. Если отогнуть ручку вверх, а потом вбок…
— Принеси ему стул, — попросил меня технический директор, и я вышел из комнаты.
В коридоре я встретил сисадмина. На его лице было такое выражение, как если бы он обнаружил пиво в одной из бутылей для кулера.
— Что там с почтовиком? — спросил я.
— Ты будешь смеяться. В его письме MIME-boundary нарушает RFC 2046. Ничего страшного, но наш сервер падает при приеме такого текста! Измени хотя бы один символ – все пройдет нормально. Я посмотрел в логи – сервер падал четыре раза в понедельник. Судя по всему, именно из-за этого товарища.
Вернувшись, мы застали технического директора за попытками задвинуть жалюзи. Кандидат увлеченно объяснял, каким именно способом он сумел их заклинить. Маркетинговый директор смотрел на него уже почти с ненавистью. За какие-то пять минут это чудо сумело сломать лампу, кресло, жалюзи и продемонстрировать багу в нашем почтовике.
— А вот стол у вас хороший, основательный! — сказал кандидат. Как говорил Оззи Осборн, «я начал понимать, что приходит время прощаться».
— Мы с вами свяжемся, до свидания.
— Можно, я от вас позвоню? — спросил этот демон разрушения.
— НЕТ! — ответил технический директор таким голосом, что кандидат мгновенно исчез.
Налив себе еще немного кофе, мы обсудили результаты собеседования. Увы, девушка не прошла.
Сертификат QA Engineer не заменит природного таланта — с таким парнем в команде нам просто не удастся сдать софт, если в нем будет хотя бы один баг.
Завтра пятница, значит – знакомство с новым членом коллектива. Пиво и бильярд в Потерянном Кластере. Пожалуй, я лучше пойду в Пива.NET — пусть попса, но мало ли что он захочет протестировать в баре…
Любой сотрудник некрупной IT-компании подтвердит, что четверг – самый скучный день недели. В самом деле — в понедельник все разгребают пришедшую за выходные почту, ругаются с поставщиками кофе и воды для кулера, и курят на лестнице, рассказывая друг другу анекдоты для борьбы со сном и похмельем. Во вторник задачи розданы, силы свежи, и код пишется на одном дыхании. В среду количество полезной работы за единицу времени достигает своего апогея… Пятница, естественно, проходит под знаком ожидания чьего-нибудь дня рождения или просто пивной вечеринки, поэтому квака начинается с самого утра, и большинство народу даже не делает вид, что работает. Те немногие, кто затрудняется имитацией деятельности, держат Экслера или RSDN открытым в пятом окне эксплорера, чтобы в таскбаре не было видно адреса.
А вот четверг – это момент кризиса. Переход от работы к удовольствию. Начинать читать обзоры фильмов еще рановато, а работать не дают мысли о завтрашней пятнице.
Этот четверг ничем не отличался от обычных. Часов с 12 я начал испытывать просто нестерпимое желание найти повод поотлынивать. Поэтому когда в аське всплыл вопрос шефа «Не хочешь пособеседовать тестеров?», я долго не думал.
Напрягаться я не собирался, благо «собеседников» и без меня было вполне достаточно – технический директор, директор по маркетингу и главный (он же единственный) сисадмин.
Заливая четвертую за сегодня кружку Nescafe Gold водой из кулера (наш народ зовет эту жидкость смолой, за цвет, вкус и консистенцию), я пообщался с директорами и выяснил, что, во-первых, место у нас одно, а во-вторых, кандидатов двое. Такой высокий конкурс директор по маркетингу объяснял грамотным проведением рекрутинговой кампании (он сам составлял макет объявления для нашего сайта), а технический директор – замедлением падения курса доллара. Поскольку мы работаем на заказчиков, не говорящих по-русски, за курсом доллара наши сотрудники следят пристальнее, чем ребята из Редмонда за курсом акций Microsoft.
Налив себе кофе, мы переместились в конференц-зал.
Первым кандидатом оказалась симпатичная девушка в джинсах и свитере. Я пропустил мимо ушей ее резюме, обратив внимание лишь на упоминание какого-то сертификата Quality Assurance Engineer. Во время собеседования девушка вела себя довольно-таки уверенно, то и дело поминала Transition Phase, CMM, ISO9000 и трехлетний опыт работы. Все это время я смотрел в окно и думал о том, что сидеть она будет в комнате через коридор, и что я не смогу использовать обычный лексикон при объяснении тонких моментов тест-плана.
Вторым был парень-студент, во взгляде которого читалась острейшая нужда в денежных средствах. На этот раз я принял участие в собеседовании и узнал, что он – гениальный программист и веб-дизайнер, что у него даже есть свой сайт, и что он сейчас пишет IDE для PHP на MAC. Я бы выяснил, почему он предпочитает MAC, но поймал взгляд технического директора и свернул беседу.
После ухода кандидатов мы несколько минут поспорили о проблемах девушек в чисто мужских коллективах и проблемах излишней амбициозности читателей журнала ксакеп, и сошлись на том, что «теперь хоть матов будет меньше», — девушка была очевидным выбором. Мы уже направились к выходу, когда у технического зазвонил мобильник. Обменявшись парой реплик со своим собеседником, технический зажал микрофон рукой и шепотом известил нас о том, что у входа в офис ждет еще один кандидат. Мы переглянулись. Решение было уже принято, но как-то неудобно было давать от ворот поворот человеку, не поленившемуся притащиться к нам на окраину. Технический велел охране впустить, и мы вернулись в конференц-зал.
Третий кандидат выглядел немного моложе моих лет. Улыбнувшись, он представился и сел в кресло, бросив папку на стол. Маркетинговый директор порылся у себя в бумагах и спросил:
— Извините, я что-то не вижу вашего резюме. Вы не присылали его нам?
— Присылал, — ответил кандидат, с интересом оглядываясь вокруг, — Но у вас почтовый сервер глючит.
Это было не очень хорошее начало. Мы все-таки IT-компания, и достаточно тщательно следим за тем, чтобы у нас все работало. Если у него нет резюме – пусть так и скажет и не тратит наше время. Технический директор с некоторой даже обидой спросил:
— Может быть, проблема все же не в сервере? Со связью что-нибудь, или почтовый клиент не сработал? Вы, кстати, не с мейл.ру отправляли?
— Нет, — ответил кандидат, продолжая оглядываться. Его внимание привлекла настольная лампа. Щелкнув пару раз выключателем, он сказал: «Смотрите-ка!» – и полез под стол. Лампа вспыхнула и перегорела. Кандидат вылез из-под стола и продолжил:
— Если оставить выключатель в промежуточном положении, а потом включить шнур в розетку, лампа перегорит!
— Спасибо. Может быть, вы принесли резюме с собой? — поинтересовался я.
— Да, конечно, вот оно, — он подал лист А4, — а вот это — распечатка ответа вашего почтового сервера, — он подал еще один лист.
Сисадмин с интересом взял его из моих рук и пробежал глазами:
— Но!.. А как?.. Странно… Я сейчас! — с этими словами он почти выбежал из комнаты.
Директора тем временем изучали резюме. Я смотрел на кандидата. Он повернулся назад, и что-то настраивал в кресле. Это было обычное пятилапое офисное чудовище на колесиках, распространитель сколиоза и отложения солей. Наконец в кресле что-то щелкнуло, и потенциальный тестер оказался на полу. Это, казалось, ничуть его не расстроило:
— Я так и знал! Дефект в системе регулировки пневматического амортизатора. Если отогнуть ручку вверх, а потом вбок…
— Принеси ему стул, — попросил меня технический директор, и я вышел из комнаты.
В коридоре я встретил сисадмина. На его лице было такое выражение, как если бы он обнаружил пиво в одной из бутылей для кулера.
— Что там с почтовиком? — спросил я.
— Ты будешь смеяться. В его письме MIME-boundary нарушает RFC 2046. Ничего страшного, но наш сервер падает при приеме такого текста! Измени хотя бы один символ – все пройдет нормально. Я посмотрел в логи – сервер падал четыре раза в понедельник. Судя по всему, именно из-за этого товарища.
Вернувшись, мы застали технического директора за попытками задвинуть жалюзи. Кандидат увлеченно объяснял, каким именно способом он сумел их заклинить. Маркетинговый директор смотрел на него уже почти с ненавистью. За какие-то пять минут это чудо сумело сломать лампу, кресло, жалюзи и продемонстрировать багу в нашем почтовике.
— А вот стол у вас хороший, основательный! — сказал кандидат. Как говорил Оззи Осборн, «я начал понимать, что приходит время прощаться».
— Мы с вами свяжемся, до свидания.
— Можно, я от вас позвоню? — спросил этот демон разрушения.
— НЕТ! — ответил технический директор таким голосом, что кандидат мгновенно исчез.
Налив себе еще немного кофе, мы обсудили результаты собеседования. Увы, девушка не прошла.
Сертификат QA Engineer не заменит природного таланта — с таким парнем в команде нам просто не удастся сдать софт, если в нем будет хотя бы один баг.
Завтра пятница, значит – знакомство с новым членом коллектива. Пиво и бильярд в Потерянном Кластере. Пожалуй, я лучше пойду в Пива.NET — пусть попса, но мало ли что он захочет протестировать в баре…
Слайды и текст о процессе тестирования от Edison
Разработка программного обеспечения, как правило, начинается со сбора требований и подготовки технического задания. Тут стоимость исправлений минимальна. Гораздо проще изменить пару абзацев, чем переписывать часть системы во время эксплуатации. Исключая переделки, приводящие к срыву сдачи, тестирование требований окупается уже на старте.
Проектирование
Техническое задание отвечает на вопрос «что тестируем?». На этапе проектирования тестов сначала готовится абстрактный тест-план, задающий стратегию: применимые виды тестирования; когда, как и в каком окружении оно будет проходить; условие подключения инженера по качеству. Затем описываются конкретные кейсы и сценарии, изящно выявляющие сбои в системе.
Стенд
Выделенный тестовый стенд необходим при длительной разработке, требующей бесперебойного функционирования последней стабильной версии. Изменения порождают следующую, нестабильную, пользоваться которой без тщательной проверки не получится. Для сложных проектов нужны несколько стендов: главный — сервер для продуктивной системы, второй — для командной доработки, третий — окружение для прогона тестов, четвертый — для демонстрации промежуточных результатов.
Прогон
Когда появляется первая (или альфа-) версия, начинаются прогоны заготовленных тестов. Эта версия уже может быть передана потенциальным пользователям с целью получения замечаний. В итоге у системы появляются новые функции, а ошибки тщательно документируются и отправляются инженерам.
Чтобы вносимые изменения не повлияли на работоспособность приложения, проверка проводится снова.
Если ручное тестирование отвлекает слишком много ресурсов, имеет смысл его автоматизировать. Это потребует дополнительных вложений, зато потом рутина будет выполняться многократно, в нерабочее время и совершенно бесплатно.
Результаты
Результаты внутреннего тестирования обсуждаются с ключевыми сотрудниками. Решается, какие ошибки нужно исправить немедленно, а какие — к следующему релизу.
Впоследствии описанные этапы проверки могут повторяться. Это называется циклом тестирования.
Предварительная или бета-версия еще не считается готовым продуктом, но уже допускается к опытной эксплуатации. Как правило, в это время реализовано минимум 95% функциональности. После завершения приемочного или финального тестирования выпускается окончательная версия.
Выбор
Выбирая отдельные виды тестирования, важно понимать последствия отказа от других.
Минимальный пакет
Тестирование требований можем заменить привлечением наиболее опытного архитектора в самом начале проекта. Без внутреннего тестирования на приемке окажется «сырой» или нерабочий продукт, поэтому оно необходимо. Полный отказ от минимального пакета приведет к фатальной потере качества.
Достаточный пакет
Дополняя предыдущий пакет, нагрузочное тестирование подтвердит рамки, в которых система производительна. Здесь определяем необходимое число сЕрверов в облаке, проверяем пиковое количество запросов к одному серверу и базе данных, нагрузку на жесткий диск, оперативную память и прочее.
Тестирование безопасности выполняем во избежание хакерских атак, таких как заражение вирусами, кража денег, паролей и персональных данных.
Тестирование интерфейса и удобства эксплуатации исключит уход вашей аудитории к конкурентам.
Полный пакет
Если требуется обеспечение повышенной надежности, к достаточному пакету добавляем автоматическое и «дымовОе» тестирование. Чтобы осуществить ежедневные прогоны, создаем программные тесты каждого модуля системы. Качество кода особенно важно, когда разные специалисты работают с одним файлом. Регулярно проверяем исходники и проводим рефАкторинг, чтобы код был понятен новому члену команды.
Разработка программного обеспечения, как правило, начинается со сбора требований и подготовки технического задания. Тут стоимость исправлений минимальна. Гораздо проще изменить пару абзацев, чем переписывать часть системы во время эксплуатации. Исключая переделки, приводящие к срыву сдачи, тестирование требований окупается уже на старте.
Проектирование
Техническое задание отвечает на вопрос «что тестируем?». На этапе проектирования тестов сначала готовится абстрактный тест-план, задающий стратегию: применимые виды тестирования; когда, как и в каком окружении оно будет проходить; условие подключения инженера по качеству. Затем описываются конкретные кейсы и сценарии, изящно выявляющие сбои в системе.
Стенд
Выделенный тестовый стенд необходим при длительной разработке, требующей бесперебойного функционирования последней стабильной версии. Изменения порождают следующую, нестабильную, пользоваться которой без тщательной проверки не получится. Для сложных проектов нужны несколько стендов: главный — сервер для продуктивной системы, второй — для командной доработки, третий — окружение для прогона тестов, четвертый — для демонстрации промежуточных результатов.
Прогон
Когда появляется первая (или альфа-) версия, начинаются прогоны заготовленных тестов. Эта версия уже может быть передана потенциальным пользователям с целью получения замечаний. В итоге у системы появляются новые функции, а ошибки тщательно документируются и отправляются инженерам.
Чтобы вносимые изменения не повлияли на работоспособность приложения, проверка проводится снова.
Если ручное тестирование отвлекает слишком много ресурсов, имеет смысл его автоматизировать. Это потребует дополнительных вложений, зато потом рутина будет выполняться многократно, в нерабочее время и совершенно бесплатно.
Результаты
Результаты внутреннего тестирования обсуждаются с ключевыми сотрудниками. Решается, какие ошибки нужно исправить немедленно, а какие — к следующему релизу.
Впоследствии описанные этапы проверки могут повторяться. Это называется циклом тестирования.
Предварительная или бета-версия еще не считается готовым продуктом, но уже допускается к опытной эксплуатации. Как правило, в это время реализовано минимум 95% функциональности. После завершения приемочного или финального тестирования выпускается окончательная версия.
Выбор
Выбирая отдельные виды тестирования, важно понимать последствия отказа от других.
Минимальный пакет
Тестирование требований можем заменить привлечением наиболее опытного архитектора в самом начале проекта. Без внутреннего тестирования на приемке окажется «сырой» или нерабочий продукт, поэтому оно необходимо. Полный отказ от минимального пакета приведет к фатальной потере качества.
Достаточный пакет
Дополняя предыдущий пакет, нагрузочное тестирование подтвердит рамки, в которых система производительна. Здесь определяем необходимое число сЕрверов в облаке, проверяем пиковое количество запросов к одному серверу и базе данных, нагрузку на жесткий диск, оперативную память и прочее.
Тестирование безопасности выполняем во избежание хакерских атак, таких как заражение вирусами, кража денег, паролей и персональных данных.
Тестирование интерфейса и удобства эксплуатации исключит уход вашей аудитории к конкурентам.
Полный пакет
Если требуется обеспечение повышенной надежности, к достаточному пакету добавляем автоматическое и «дымовОе» тестирование. Чтобы осуществить ежедневные прогоны, создаем программные тесты каждого модуля системы. Качество кода особенно важно, когда разные специалисты работают с одним файлом. Регулярно проверяем исходники и проводим рефАкторинг, чтобы код был понятен новому члену команды.
Еще мне на ум приходит рассказ Проект Genesis после которого можно запустить обсуждение со школьниками важности и роли грамотной разработки и тестирования.
Проект Genesis
Юрий Нестеренко
Проект Genesis
(из корпоративной переписки)
(Этот рассказ переведен на английский и болгарский)
Генеральному директору Иегове
от начальника маркетингового отдела Гавриила
Исследования, проведенные нашим отделом в рамках проекта Genesis,
показали, что наилучшие перспективы на рынке имеют системы следующей
конфигурации:
Планета: 1 шт.
Радиус: 3000 км
Сила тяжести: 0.5g
Соотношение суша/вода: 1:1
Температура: +24
Атмосфера: кислород
Моря: пресн. вода
Реки: молоко, мед
Фауна: травоядная
Периферия:
светила 2 шт. (дн./ночн.), скорость: 0.0007 RPM (1 об/сут)
«Направить в отдел стратегического планирования для подготовки ТЗ — Иегова»
Генеральному директору Иегове
от начальника отдела стратегического планирования Михаила
В целях снижения себестоимости системы предлагаю запитать оба светила
от одного источника энергии, а кислород заменить азотом.
«Хотя бы 50% кислорода надо оставить, а то пользователь задохнется —
нач. отд. тестирования и техподдержки Рафаил»
«Хватит и 25% — Иегова»
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
В ходе работ по проекту Genesis (стадия «Да будет свет») выявлены
следующие трудности: у нас отсутствует компактный источник
бесперебойного свечения с распределителем на два светила. Предлагаю
воспользоваться стандартным источником типа «красный карлик», а в
качестве ночного светила применить зеркало.
«Лучше „желтый карлик“. По себестоимости это не намного больше,
а смотрится куда более внушительно — нач. маркет. отдела Гавриил»
«Это же серверный источник. Зачем он нужен пользователю одиночной
планеты? — Люцифер»
«Что пользователю нужно, а что нет, ему объяснит отдел рекламы — Гавриил»
«Люцифер, занимайтесь вопросами вашей компетенции. Утверждаю
»желтый карлик" — Иегова"
«Кстати, при той яркости, что дает желтый карлик, можно вместо
зеркала поставить обычный планетоид — Михаил»
«Согласен — Иегова»
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
После внесения изменений в ТЗ возникли следующие трудности:
масса источника бесперебойного свечения намного превосходит массу
планеты, вследствие чего источник отказывается вращаться вокруг
планеты. Вместо этого планета вращается вокруг источника. Кроме
того, из-за мощности источника наблюдается устойчивое превышение
температуры над указанным в ТЗ (примерно на 2 порядка). Если увеличить
расстояние до источника, существенно возрастут габариты системы.
«Габариты — это даже престижно, а вот вращение планеты вокруг
периферийного устройства может вызвать у пользователя ощущение
неполноценности. Может, поменяем гравитационную постоянную? — Гавриил»
«Если менять гравитационную постоянную, возникнут проблемы с
совместимостью — Михаил»
«Да какая пользователю разница, что вокруг чего крутится? Пусть
отдел рекламы придумает какую-нибудь теорию относительности — Иегова»
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
После увеличения радиуса орбиты попытки разогнать планету до указанной
в ТЗ скорости приводят к краху системы (планета улетает в космос).
Кстати, с ночным светилом та же история.
«Неважно, что происходит в системе — важно, что видит пользователь.
Почему бы не заставить планету вращаться вокруг своей оси? Тогда
пользователю будет казаться, что солнце и луна обращаются вокруг
нее с указанной в ТЗ частотой — Гавриил»
«А пользователь нас не раскусит? — Иегова»
«Если и раскусит, проект к тому времени будет давно уже сдан — Гавриил»
«Согласен — Иегова»
Генеральному директору Иегове
от начальника отдела тестирования и техподдержки Рафаила
Первичное тестирование системы выявило следующие дефекты:
1) Наблюдается устойчивый перегрев
2) Ось вращения отклонилась на 23 град. от вертикали, вследствие
чего возникли цикличные температурные аномалии
3) Пропускная способность рек не соответствует проектной
4) Травоядная фауна отсутствует
5) Орбита нестабильна, планета имеет тенденцию к падению на солнце
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
1) А что вы хотели при таком соотношении суша/вода? Для оптимального
охлаждения нужно где-то 1:3 — 1:4.
2) Мы работаем над этим
3) Потому что молоко скисает, а мед засахаривается
4) Травоядной фауне трава нужна, а она не растет при такой жаре и
без воды. Предлагаю пустить по рекам воду, это заодно поможет решить
проблему 3.
5) В качестве гравитационного противовеса мы выведем на внешнюю
орбиту еще одну планету.
«Сушу ужимать некуда, значит, придется увеличивать площадь морей. А
это — рост объема и силы тяжести. Да еще лишняя планета… — Михаил»
«Ничего, пользователь стерпит. Лишнюю планету оформим, как фичу. А вот
молоко и мед мы уже анонсировали. Хотя бы в самых заметных реках надо
оставить — Гавриил»
«Напоминаю, что сроки поджимают, а у вас еще конь не валялся. Кстати,
дизайнеры до сих пор не представили проект коня, все с динозаврами
возятся. Кому нужны эти динозавры? — Иегова»
«Вообще-то пользователь динозавров любит — Гавриил»
«Ладно, но и конь чтоб был — Иегова»
Генеральному директору Иегове
от начальника отдела тестирования и техподдержки Рафаила
1) Помимо нерешенных проблем с осью, планета теперь имеет тенденцию
к улету в космос.
2) Травоядной фауны опять нет.
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
1) Сделаем еще один противовес, теперь на внутренней орбите.
2) А фауна размножилась, сожрала всю траву и передохла
«Сколько всего противовесов вам надо? — Михаил»
«В общем, после калибровочных работ удалось стабилизировать систему
на девяти — Люцифер»
«Я правильно понял? Вместо одной планеты пользователь получит 9?! — Иегова»
«Ну и что? 8 из них все равно непригодны для жизни — Люцифер»
«А размеры системы? — Иегова»
«А пользователю их и знать необязательно. Половину этих планет без
телескопа и не увидишь. Предлагаю дополнить Руководство пользователя
11-й заповедью: „Не изобретай телескоп“ — Гавриил»
«Не надо. Тогда они его точно изобретут — Иегова»
«Кстати, после увеличения радиуса орбиты яркость ночного светила
упала ниже проектного минимума. Предлагаю инсталлировать вместо
него зеркало — Рафаил»
«А где вы раньше были? Мы только-только уравновесили систему! Хотите
все перенастраивать заново?! — Люцифер»
«Никаких заново! До сдачи проекта осталось шесть дней. Люцифер, или
вы заставите все это работать, или я вас переведу с понижением! — Иегова»
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
А я виноват, что мне сразу не дали нормального ТЗ? В общем, так.
Наклон оси придется оставить, как есть. По крайней мере, в Эдемском
саду +24 будет, а если пользователь полезет куда-то еще, это его
проблемы. Динозавров мы доделать не успеваем, но коней сделаем.
С молоком и медом ничего не вышло, пустили по рекам воду, правда,
она выносит в море соль. Чтобы травоядные не отжирали все ресурсы, мы
выпустили патч в виде хищников, но поставить им программу отличения
пользователя от добычи уже не успеваем. Ну а в общем, как-то работать
будет.
«И это хорошо — Иегова»
(С) YuN, 2002
yun.complife.info
Проект Genesis
(из корпоративной переписки)
(Этот рассказ переведен на английский и болгарский)
Генеральному директору Иегове
от начальника маркетингового отдела Гавриила
Исследования, проведенные нашим отделом в рамках проекта Genesis,
показали, что наилучшие перспективы на рынке имеют системы следующей
конфигурации:
Планета: 1 шт.
Радиус: 3000 км
Сила тяжести: 0.5g
Соотношение суша/вода: 1:1
Температура: +24
Атмосфера: кислород
Моря: пресн. вода
Реки: молоко, мед
Фауна: травоядная
Периферия:
светила 2 шт. (дн./ночн.), скорость: 0.0007 RPM (1 об/сут)
«Направить в отдел стратегического планирования для подготовки ТЗ — Иегова»
Генеральному директору Иегове
от начальника отдела стратегического планирования Михаила
В целях снижения себестоимости системы предлагаю запитать оба светила
от одного источника энергии, а кислород заменить азотом.
«Хотя бы 50% кислорода надо оставить, а то пользователь задохнется —
нач. отд. тестирования и техподдержки Рафаил»
«Хватит и 25% — Иегова»
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
В ходе работ по проекту Genesis (стадия «Да будет свет») выявлены
следующие трудности: у нас отсутствует компактный источник
бесперебойного свечения с распределителем на два светила. Предлагаю
воспользоваться стандартным источником типа «красный карлик», а в
качестве ночного светила применить зеркало.
«Лучше „желтый карлик“. По себестоимости это не намного больше,
а смотрится куда более внушительно — нач. маркет. отдела Гавриил»
«Это же серверный источник. Зачем он нужен пользователю одиночной
планеты? — Люцифер»
«Что пользователю нужно, а что нет, ему объяснит отдел рекламы — Гавриил»
«Люцифер, занимайтесь вопросами вашей компетенции. Утверждаю
»желтый карлик" — Иегова"
«Кстати, при той яркости, что дает желтый карлик, можно вместо
зеркала поставить обычный планетоид — Михаил»
«Согласен — Иегова»
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
После внесения изменений в ТЗ возникли следующие трудности:
масса источника бесперебойного свечения намного превосходит массу
планеты, вследствие чего источник отказывается вращаться вокруг
планеты. Вместо этого планета вращается вокруг источника. Кроме
того, из-за мощности источника наблюдается устойчивое превышение
температуры над указанным в ТЗ (примерно на 2 порядка). Если увеличить
расстояние до источника, существенно возрастут габариты системы.
«Габариты — это даже престижно, а вот вращение планеты вокруг
периферийного устройства может вызвать у пользователя ощущение
неполноценности. Может, поменяем гравитационную постоянную? — Гавриил»
«Если менять гравитационную постоянную, возникнут проблемы с
совместимостью — Михаил»
«Да какая пользователю разница, что вокруг чего крутится? Пусть
отдел рекламы придумает какую-нибудь теорию относительности — Иегова»
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
После увеличения радиуса орбиты попытки разогнать планету до указанной
в ТЗ скорости приводят к краху системы (планета улетает в космос).
Кстати, с ночным светилом та же история.
«Неважно, что происходит в системе — важно, что видит пользователь.
Почему бы не заставить планету вращаться вокруг своей оси? Тогда
пользователю будет казаться, что солнце и луна обращаются вокруг
нее с указанной в ТЗ частотой — Гавриил»
«А пользователь нас не раскусит? — Иегова»
«Если и раскусит, проект к тому времени будет давно уже сдан — Гавриил»
«Согласен — Иегова»
Генеральному директору Иегове
от начальника отдела тестирования и техподдержки Рафаила
Первичное тестирование системы выявило следующие дефекты:
1) Наблюдается устойчивый перегрев
2) Ось вращения отклонилась на 23 град. от вертикали, вследствие
чего возникли цикличные температурные аномалии
3) Пропускная способность рек не соответствует проектной
4) Травоядная фауна отсутствует
5) Орбита нестабильна, планета имеет тенденцию к падению на солнце
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
1) А что вы хотели при таком соотношении суша/вода? Для оптимального
охлаждения нужно где-то 1:3 — 1:4.
2) Мы работаем над этим
3) Потому что молоко скисает, а мед засахаривается
4) Травоядной фауне трава нужна, а она не растет при такой жаре и
без воды. Предлагаю пустить по рекам воду, это заодно поможет решить
проблему 3.
5) В качестве гравитационного противовеса мы выведем на внешнюю
орбиту еще одну планету.
«Сушу ужимать некуда, значит, придется увеличивать площадь морей. А
это — рост объема и силы тяжести. Да еще лишняя планета… — Михаил»
«Ничего, пользователь стерпит. Лишнюю планету оформим, как фичу. А вот
молоко и мед мы уже анонсировали. Хотя бы в самых заметных реках надо
оставить — Гавриил»
«Напоминаю, что сроки поджимают, а у вас еще конь не валялся. Кстати,
дизайнеры до сих пор не представили проект коня, все с динозаврами
возятся. Кому нужны эти динозавры? — Иегова»
«Вообще-то пользователь динозавров любит — Гавриил»
«Ладно, но и конь чтоб был — Иегова»
Генеральному директору Иегове
от начальника отдела тестирования и техподдержки Рафаила
1) Помимо нерешенных проблем с осью, планета теперь имеет тенденцию
к улету в космос.
2) Травоядной фауны опять нет.
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
1) Сделаем еще один противовес, теперь на внутренней орбите.
2) А фауна размножилась, сожрала всю траву и передохла
«Сколько всего противовесов вам надо? — Михаил»
«В общем, после калибровочных работ удалось стабилизировать систему
на девяти — Люцифер»
«Я правильно понял? Вместо одной планеты пользователь получит 9?! — Иегова»
«Ну и что? 8 из них все равно непригодны для жизни — Люцифер»
«А размеры системы? — Иегова»
«А пользователю их и знать необязательно. Половину этих планет без
телескопа и не увидишь. Предлагаю дополнить Руководство пользователя
11-й заповедью: „Не изобретай телескоп“ — Гавриил»
«Не надо. Тогда они его точно изобретут — Иегова»
«Кстати, после увеличения радиуса орбиты яркость ночного светила
упала ниже проектного минимума. Предлагаю инсталлировать вместо
него зеркало — Рафаил»
«А где вы раньше были? Мы только-только уравновесили систему! Хотите
все перенастраивать заново?! — Люцифер»
«Никаких заново! До сдачи проекта осталось шесть дней. Люцифер, или
вы заставите все это работать, или я вас переведу с понижением! — Иегова»
Генеральному директору Иегове
от начальника отдела системотехники Люцифера
А я виноват, что мне сразу не дали нормального ТЗ? В общем, так.
Наклон оси придется оставить, как есть. По крайней мере, в Эдемском
саду +24 будет, а если пользователь полезет куда-то еще, это его
проблемы. Динозавров мы доделать не успеваем, но коней сделаем.
С молоком и медом ничего не вышло, пустили по рекам воду, правда,
она выносит в море соль. Чтобы травоядные не отжирали все ресурсы, мы
выпустили патч в виде хищников, но поставить им программу отличения
пользователя от добычи уже не успеваем. Ну а в общем, как-то работать
будет.
«И это хорошо — Иегова»
(С) YuN, 2002
yun.complife.info
Кто может поделиться личным опытом, когда он рассказывал, что такое тестирование — пишите в комменты.
Комментарии (7)
serafims
25.11.2015 11:56+1Ситуация с заводом в Западной Австралии странная — если насосы не должны включаться при при выключенном питании охладителей, то проблема скорее в отсутствии чертовой релюшки или иного блокирующего устройства, не установленного при проектировании…
Alexeyslav
25.11.2015 15:22Управление было видимо строго централизованное, непосредственной связи между подсистемами не было даже предусмотрено…
Да даже если было бы предусмотрено, сама релюшка могла быть причиной отказа — насосы остановятся когда должны бы работать из-за какой-то мелкой чёртовой релюшки.
saboteur_kiev
25.11.2015 15:09+2История про третьего кандидата-тестировщика — шикарная. Я хочу почитать еще!
dyadyaSerezha
25.11.2015 17:42Продолжая ряд…
1986 год, на Чернобыльской АЭС нафик отключили все проверки и программы безопасности. И сделали нечто. Погибло… боюсь даже сказать.
2004 год, землетрясение в Юго-Востойной Азии. Погибло, по разным оценкам, от 225 тысяч до 300 тысяч человек.
Вывод: в ответе за всё кто-то другой.
BalinTomsk
25.11.2015 23:13+1----1986 год, на Чернобыльской АЭС нафик отключили все проверки и программы безопасности. И сделали нечто.
Данный функциональный тест был инициирован ЦК КПСС после войны в Египте, когда СССР решил построить там атомную станцию, что бы проверить как АЭС будет функционировать при потере источников питания. Беда в была в том, что попался неуемный начальник смены, имеюший образование и опыт только по ТЭЦ, плюс к этому конструктивные недостатки данного типа АЭС. Сочетание всех факторов и привело к проблеме.
А по теме статьи — большинство данных дефектов программного обеспечения не может быть выявлено на стадии тестирования ибо тестировать их нужно в реальных космических условиях.
А вот написание программистом юнит тестов решило бы 99% описанных проблем.
ArXen42
27.11.2015 17:45+1С трудом удерживаюсь от того проверки своей лампы на перегорание при промежуточном положении выключателя.
VolCh
Рассказывал коллегам-программистам. Основной тезис: тестирование — проверка соответствия программы (как продукта) заданным или заявленным требованиям.