ALMELN.ru - Алексей Мельников

о блоге ~ заметки по RSS или почте

Подход к решению тестовых заданий на интервью

Первая глава книги «Искусство тестирования программ» Гленфорда Майерса начинается с предложения пройти тест для самооценки. Задача состоит в том, чтобы проверить некоторую программу. Для этого предлагается написать на листе бумаги набор тестов (то есть специальные последовательности данных), которые будут адекватно проверять программу. Затем Гленфорд приводит примеры тестов, которые позволят оценить читателю эффективность самостоятельно придуманных тестов. Автор подводит итог главе, что если вы не программист, то вы не очень хорошо справитесь с составлением теста. Опытные профессиональные программисты набираются в среднем только 7-8 очков из 14 возможных. «Выполненное упражнение показывает нам, что тестирование даже тривиальных программ, подобных приведенной, — непростая задача».

О том, как неправильно можно использовать эту задачу рассказал mike1999 в форумной теме Задача — тестирование подсчета типа треугольника. В рассказе не столько при тестирование треугольника, сколько про правильный подход про процедуру решения тестовых задач на собеседованиях:

Я вот в тестировании 8 лет, на текущей работе уже тест-лид, сам собеседовал не раз. Решил сменить компашку, до этого собеседования нигде не проходил. И что вы думаете — на первом же интервью мне выдают задачу (дословно): «- Составьте, пожалуйста, список тестов для функции на входе которой три параметра, а на выходе треугольник». Повторяю — это была дословная постановка задачи. И с умным видом он откинулся на спинку кресла.

Это мне предложил технарь из компании «Открытые технологии»... Я вот конкретно эту задачу не встречал, и догадаться что за параметры передаются в функцию не мог. Попробовал было задать наводящие вопросы, что мол за значения в параметрах? (ну там длины это или тройки координат в пространстве) на что был ответ — типа «...вы мне скажИте какие это параметры...» ... Что за параметры, что за треугольник на выходе? Попробуй догадайся.... Ну я ему совставил кейсы для троек координат в пространстве (отголоски текущей работы)...

К чему это я... А да... товарищи собеседующие кандидатов, прежде чем тестить кандидата потрудитесь вникнуть в суть задач. Оригинальная задача звучит так: «Составьте список тестов для функции, в которую передается три значения длин, а на выходе функция выдает — одно значение boolean — true, если существует треугольник со сторонами такой длины, и false если не существует».

В случае если функция до кучи определяет тип треугольника — половина ответов, что тут написана — полная бредятинаю. 50 кейсов это заява от кого? Кто-нибудь вообще слышал об избыточности тестов? С таким подходом тестирование по стоимости будет в несколько раз дороже всего остального проекта + все как макаки уперлись в этот треугольник, никто даже не заикнулся про проверки максимальных значений, про проверку требований, явных, неявных, производительность... мы функцию проверяем, а не треугольник...

Опять же к чему это я... а да... на собеседовании постарайтесь не бросаться на составление максимального числа перестановок и конкретных значений. При любой задаче на составление тестов уточните непонятные моменты, составьте микро тест-план, составьте микро-список требований, разделите их на приоритетные и нет, постройте в голове маленькое оглавление для сценария, например: смок, функционал, производительность, юзабилити (+ эргономика), безопасность, окружение... И тд, все виды и подвиды, какие вспомните, далее по каждому пункту определите нужен он или нет. Далее наиболее критичные тесты. Не бойтесь записывать. При таком подходе грамотный собеседующий технарь увидит что вы умеете думать, а не тупо выписываете все возможные комбинации из трех чисел.

Как пример, периодически даем на проверку кандидату форму доступа путем ввода пятизначного цифрового пароля, для сенсорного терминала, и просим «на лету» протестировать и составить отчет. Форма намеренно заторможена на нажание кнопки «0» — пауза секунд 5. Правильный пароль известен. На форме цифры, спецсимволы,«Отмена», «Вход», «Язык», у тестера есть возможность задать правильный пятизначный пароль обычным апдейтом на рядом стоящем компе. Все кидаются проверять и перебирать пароли.

Как результат : Половина не замечают тормозов другая половина, замечает, матерится на тормоза, но в отчете не указывает. Половина вводит только пятизначные значения. Половина вводит только цифры. 95% не проверяют вход при пустом пароле и вход с пустым паролем о комбинациях (0/NULL) я уже не говорю. 95% не проверяют кнопку «Отмена». 95% не уточняют может ли пароль содержать спецсимволы с клавиатуры терминала. Один человек за 3 года проверил смену языка. Никто не проверяет добавление к правильному паролю других цифр и спецсимволов. Никто не проверяет обрезанный с конца пароль.

И при этом все кандидаты надрочены на логические задачи про треугольники и лампочки, а если задачек не дают, то на лице истинное разочарование — как же так я ведь весь интернет прочитал, а вы меня совсем не то спрашивали...

Ох скока я понаписал...

Работа над ошибками малой кровью

«Джилл ввела информацию об ошибке в базу данных. Кстати, даже сам процесс записи информации об ошибке требует определенной дисциплины: бывают хорошие описания, а бывают и плохие...

Запомнить правила составления хорошего описания ошибки совсем нетрудно. Каждое хорошее описание ошибки должно содержать ровно три вещи: 1. Какие шаги привели к ошибке. 2. Что вы ожидали увидеть. 3. Что вы в самом деле увидели...

Когда ошибка разрешена, она назначается обратно тому, кто открыл её. Это важный момент. Ошибка не исчезает только потому, что программист так решил. Золотое правило гласит, что закрыть ошибку может только тот, кто её открыл...

Вы должны аккуратно отслеживать версии программы. Каждая сборка программы, которая передается тестеру, должна иметь номер версии, чтобы несчастный тестер не проверял ошибку, которая и не должна быть исправлена в этой версии».

Понравилась статья Работа над ошибками малой кровью под авторством Джоэла Сполски. Джоэл является соавтором Stack Overflow и основателем Fog Creek Software, сделавшей Trello. Спасибо переводчику Александру Башкову и редактору Юрию Удовиченко. Заставили задуматься, что на работе мы не используем понятие «сборка». Например, мы не указываем сборку в отчётах о дефектах и сбоях. Похоже у меня также отсутствует возможность самостоятельно проверить номер сборки, которую сейчас проверяю. Необходимо выяснить, можно ли в рабочем проекте оперировать сущностью «сборка» и как это делать самостоятельно.

Плюс обозначил для себя минимальный набор содержимого отчёта об ошибке на основе указаний Джоэла Сполски — шаги, ожидаемый и фактический результат. Теперь, когда тяжело начинать писать очередной отчет о дефекте согласно «Чек-листу подготовки отчета о недостатке программного обеспечения», начинаю с трех минимальных компонентов. После описания трех ключевых компонентов легче перейти и к описанию оставшихся необходимых элементов.

Джоэла Сполски в LinkedIn | Сайт Джоэла | Lurkmore про Джоэла

Принципы тестирования

В учебных программах по дисциплине «Обеспечение качества и тестирование программ» есть вопрос «Принципы тестирования». В программе обучения базового уровня International Software Testing Qualifications Board «Сертифицированный тестировщик» указано на необходимость «Объяснить семь принципов в тестировании».

«Искусство тестирования программ», Глендфорд Майерс, 1982, 25 страница:

Наиболее важными в тестировании программ являются вопросы психологии. Эти принципы интересны тем, что в основном они интуитивно ясны, но в то же время на них часто не обращают должного внимания.

  1. Описание предполагаемых значений выходных данных или результатов должно быть необходимой частью тестового набора
    Ошибочные, но правдоподобные результаты могут быть признаны правильными, если результаты теста не были заранее определены. Здесь мы сталкивается с явлением психологии: мы видим то, что мы хотим увидеть. Другими словами, несмотря на то что тестирование по определению — деструктивный процесс, есть подсознательное желание видеть корректный результат. Один из способов борьбы с этим состоит в поощрении детального анализа выходных переменных заранее при разработке теста. Поэтому тест должен включать две компоненты: описание входных данных и описание точного и корректного результата, соответствующего набору входных данных...
  2. Следует избегать тестирования программы ее автором
    После выполнения конструктивной части при проектировании и написании программы программисту трудно быстро (в течение одного дня) перестроиться на деструктивный образ мышления… Большинство программистов не могут эффективно тестировать свои программы, потому что им трудно демонстрировать собственные ошибки…
    В дополнение к этой психологической проблеме следует отметить еще одну, не менее важную: программа может содержать ошибки, связанные с неверным пониманием постановки или описания задачи программистом. Тогда существует вероятность, что к тестированию программист приступит с таким же недопониманием своей задачи.
  3. Программирующая организация не должна сама тестировать разработанные ею программы.
  4. Необходимо досконально изучать результаты применения каждого теста.
  5. Тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных.
  6. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать.
  7. Не следует выбрасывать тесты, даже если программа уже не нужна.
  8. Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены.
  9. Вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части.
  10. Тестирование — процесс творческий.
  11. Тестирование — это процесс выполнения программ с целью обнаружения ошибок.
  12. Хорошим считается тест, который имеет высокую вероятность обнаружения еще не выявленной ошибки.
  13. Удачным считается тест, который обнаруживает еще не выявленную ошибку.

«Быстрое тестирование», Роберт Калбертсон, Крис Браун, Гэри Кобб. Издательский дом «Вильямс», 2002. 75, 110/379 страница:

В начале главы мы сформулировали основной принцип тестирования, который гласит: исчерпывающее тестирование программы провести невозможно. То же самое справедливо и в случаях, когда приходится выполнять тестирование нескольких ком­ бинаций возможных конфигураций системы: невозможно полностью протестировать абсолютно все конфигурации системы. Основной способ состоит в установке соот­ ветствующих приоритетов конфигурациям. А вот дальше уже можно решать, какие конфигурации нужно подвергать полной отладке, а к каким применять частичное тестирование.

Один из основных принципов тестирования заключается в том, что всегда необхо­ димо знать, в каком состоянии находится тестируемая система. Если обнаружен де­ фект, но тестировщик не знает, какие действия привели к сбою, в таком случае воз­ никают трудности при воспроизведении этого сбоя. Необходимость проводить тес­ тирование из известного состояния означает, что каждый тестовый случай должен привести аппаратные и программные средства в известное состояние. Это отнюдь не означает, что тестировщик обязан обесточить систему, перезагрузить ее и запускать программу с самого начала — как и в любых других ситуациях при тестировании, все имеет свои пределы.

«Сертифицированный тестировщик Программа обучения Базового уровня», версия 2011 (от 13 апреля 2011 года), International Software Testing Qualifications Board, Андрей Конушин (председатель), Александр Александров, Алексей Александров, Татьяна Смехнова, Елена Абрамова. 16-17/101 страница:

Эти принципы тестирования были предложены в последние 40 лет и являются общим руководством для тестирования в целом.

  1. Принцип 1 — Тестирование демонстрирует наличие дефектов. Тестирование может показать, что дефекты присутствуют, но не может доказать, что их нет. Тестирование снижает вероятность наличия дефектов, находящихся в программном обеспечении, но, даже если дефекты не были обнаружены, это не доказывает его корректности.
  2. Принцип 2 — Исчерпывающее тестирование недостижимо. Полное тестирование с использованием всех комбинаций вводов и предусловий физически невыполнимо, за исключением тривиальных случаев. Вместо исчерпывающего тестирования должны использоваться анализ рисков и расстановка приоритетов, чтобы более точно сфокусировать усилия по тестированию.
  3. Принцип 3 — Раннее тестирование. Чтобы найти дефекты как можно раньше, активности по тестированию должны быть начаты как можно раньше в жизненном цикле разработки программного обеспечения или системы, и должны быть сфокусированы на определенных целях.
  4. Принцип 4 — Скопление дефектов. Усилия тестирования должны быть сосредоточены пропорционально ожидаемой, а позже реальной плотности дефектов по модулям. Как правило, большая часть дефектов, обнаруженных при тестировании или повлекших за собой основное количество сбоев системы, содержится в небольшом количестве модулей.
  5. Принцип 5 — Парадокс пестицида. Если одни и те же тесты будут прогоняться много раз, в конечном счете этот набор тестовых сценариев больше не будет находить новых дефектов. Чтобы преодолеть этот “парадокс пестицида”, тестовые сценарии должны регулярно рецензироваться и корректироваться, новые тесты должны быть разносторонними, чтобы охватить все компоненты программного обеспечения, или системы, и найти как можно больше дефектов.
  6. Принцип 6 — Тестирование зависит от контекста. Тестирование выполняется по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем сайт электронной коммерции.
  7. Принцип 7 — Заблуждение об отсутствии ошибок. Обнаружение и исправление дефектов не помогут, если созданная система не подходит пользователю и не удовлетворяет его ожиданиям и потребностям.

Эта заметка-конспект является ответом на один из экзаменационных вопросов по учебной дисциплине «Обеспечение качества и тестирование программ» и вопроса программы обучения базового уровня International Software Testing Qualifications Board «Сертифицированный тестировщик». Полный перечень вопросов привел в заметке Учебные программы, экзаменационные вопросы и литература по обеспечению качества и тестированию программ.

Мортимер Адлен и “Как читать книги. Руководство по чтению великих произведений”

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

Проанализировал ситуацию и сформулировал проблему с литературной частью — умею читать ради получения информации, но слабо владею искусством чтения ради понимания нового. Грешу с точным, внимательным чтением, медленно усваиваю опыт специалистов по тестированию. С целью постичь искусство аналитического, интерпретирующего и критического чтения взялся за книгу Мортимера Адлера “Как читать книги. Руководство по чтению великих произведений”.

Уделил первой части книги свободное время одной из недель, проведя его за сосредоточенным, обстоятельным чтением. Местами увлекался книгой, оставлял исписанными страницы блокнота, но больше всего испытывал раздражение и нетерпение. Казалось бы, прочитал ряд интересных вещей, но совсем не изменил стилистику чтения и не выработал никаких навыков. Взялся за другую книгу и уже при ее чтении обнаружил ряд приятных изменений.

Теперь читаю с блокнотом. Во время чтения оставляю не только текстовые заметки, но и рисую диаграммы Эйлера-Венна, которые позволяют удобно соотнести описываемые понятия и достигнуть понимания изучаемой темы. Например, практику работы согласно программе сертификации тестировщиков с практикой места работы. Приходит то самое понимание ради которого по мнению Мортимера Адлера и стоит браться за серьезную литературу. Начал рисовать не только графики, значки, которые помогают выделить мысли, маленькие личные открытия, появившиеся вопросы.

Рекомендации по повышению качества чтения ради понимания:

  1. “Учиться читать — это «параллельное восприятие себя» и сравнительное виртуальное отображение прочитанного, сравнение пережитого или переживаемого с собственным опытом, а также корректировка в этом сравнении своего мировосприятия”, 10-11 страницы электронной версии книги издательства “Манн, Иванов и Фербер” в PDF-формате.
    +
    Отобразить прочитанное, сравнивая пережитое или переживаемое с собственным опытом, корректировать в этом сравнение свое мировосприятие.
  2. “Если бы они позволили себе недоумевать в процессе чтения, а не по окончании, если бы начали подчеркивать непонятные места, а не выбрасывать их тут же из головы, быть может, им стало бы ясно, что эта книга не входит в их обычный «рацион»“, 40 страница.
    +
    Недоумевать в процессе чтения, подчеркивать непонятные места.
  3. “Разве это много — надеяться, что в учебных заведениях студентов научат не только пересказывать, но и критиковать, то есть отличать разумные мысли от ошибочных; уметь доказывать свою позицию и не торопиться с выводами при отсутствии уверенности?”, 76 страница.
    +
    Не только пересказывать содержание, но и критиковать, то есть отличать разумные мысли от ошибочных.

«Как читать книги» на сайте издательства МИФ | «How to Read a Book» на Goodreads

Классические и современные определения дефекта (бага)

В учебных программах по дисциплине «Обеспечение качества и тестирование программ» есть вопросы «Классические и современные определения дефекта (бага)» и «Типы дефектов». В программе обучения базового уровня International Software Testing Qualifications Board «Сертифицированный тестировщик» тема детализируется пунктом «Используя примеры, объяснить и сравнить термины ошибка, дефект, недочет, отказ и соответствующие термины просчет и помеха».

«Надежность программного обеспечения», Гленфорд Майерс. Москва, издательство «Мир», 1980 год. 11, 21 страницы:

Ошибка в программном обеспечении — это невыполнение того, что пользователь разумно ожидает от программного обеспечения... Ошибки в программном обеспечении не являются внутренним его свойством... Коротко говоря, наличие ошибок — функция как самого программного обеспечения, так и ожиданий его пользователей... Отказ программного обеспечения — это проявление ошибки в программном обеспечении.

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

Institute of Electrical and Electronics Engineers Std 610.12-1990 — IEEE Standard Glossary of Software Engineering Technology. 14, 31, 32, 65, 70, 73, 78 страницы:

Bug. See: error; fault.

Error. (1) The difference between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition. For example, a difference of 30 meters between a computed result and the correct result. (2) An incorrect step, process, or data definition. For example, an incorrect instruction in a computer program. (3) An incorrect result. For example, a computed result of 12 when the correct result is 10. (4) A human action that produces an incorrect result. For example, an incorrect action on the part of a programmer or operator. Note: While all four definitions are commonly used, one distinction assigns definition 1 to the word “error,” definition 2 to the word “fault,” definition 3 to the word “failure,” and definition 4 to the word “mistake.” See also: dynamic error; fatal error; indigenous error; semantic error; syntactic error; static error; transient error

Fault. (1) A defect in a hardware device or component; for example, a short circuit or broken wire. (2) An incorrect step, process, or data definition in a computer program. Note: This definition is used primarily by the fault tolerance discipline. In common usage, the terms “error” and “bug” are used to express this meaning. See also: data-sensitive fault; program sensitive fault; equivalent faults; fault masking; intermittent fault.

Dynamic error. An error that is dependent on the time-varying nature of an input. Contrast with: static error.

Fatal error. An error that results in the complete inability of a system or component to function.

Indigenous error. A computer program error that has not been purposely inserted as part of an error-seeding process.

Semantic error. An error resulting from a misunderstanding of the relationship of symbols or groups of symbols to their meanings in a given language. Contrast with: syntactic error.

Syntactic error. A violation of the structural or grammatical rules defined for a language; for example, using the statement B + C = A in Fortran, rather than the correct A = B + C. Syn: syntax error. Contrast with: semantic error.

Static error. An error that is independent of thetime-varying nature of an input. Contrast with: dynamic error.

Transient error. An error that occurs once, or at unpredictable intervals. See also: intermittent fault; random failure.

«Основы программной инженерии (по SWEBOK). Программная инженерия. Тестирование программного обеспечения» на базе IEEE Guide to SWEBOK® 2004, Сергей Орлик. 4 страница:

Недостаток (fault), дефект (defect) — причина нарушения работы прикладной системы.

Сбой (failure) — наблюдаемый нежелательный эффект, вызываемый причиной нарушения работы прикладной системы.

Ошибка — в зависимости от контекста, может описывать и как причину сбоя, и сам сбой.

«Быстрое тестирование», Роберт Калбертсон, Крис Браун, Гэри Кобб. Издательский дом «Вильямс», 2002. 17-18 страницы:

...Понятие дефекта (bug). Говоря простыми словами, программная ошибка— ни что иное, как изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически полученных результатов. Дефект может возникнуть на стадии кодирования, на стадии фор­мулирования требований или на стадии проектирования, либо же его причина может крыться в некорректной конфигурации или данных. Дефектом может быть также что-то другое, что не соответствует ожиданиям заказчика и что может быть, а может и не быть определено в спецификации программного продукта. Более подробное описание терминологии дефектов приводится во врезке 1.1...

Врезка 1.1. Долговечность дефекта может быть описана следующим образом. Дефект возникает в результате того, что человек допускает ошибку (error), осуществляя некоторый вид деятельности, который имеет отношение к разработке программного обеспечения. К упомянутым видам деятельности относятся, например, формулирование требований, проектирование программы или написание программного кода. Эта ошибка вкрадывает­ся в рабочий продукт (перечень требований, проектный документ или программный код) в виде неисправности (fault).

До тех пор пока эта неисправность (известная еще как дефект (bug, defect)) присутствует в рабочем продукте, она может служить причиной появления других дефектов. На­пример, если неисправность, допущенная в перечне требований, остается необнаруженной, вполне вероятно, что это приведет к возникновению соответствующих ошибок в проекте системы, в проекте программы, в программном коде и даже в документации для пользователя.

Дефект остается необнаруженным до тех пор, пока не произойдет отказ. Ведь именно тогда пользователь или тестировщик замечает, что система не выполняет возложенных на нее функций. На стадии системных испытаний цель специалиста по тестированию состоит в том, чтобы вызвать сбой программы, обнаружить и задокументировать связанные с ним дефекты, а затем удалить их из системы. В идеальном случае долговечность дефекта ограничена моментом, когда он обнаруживается средствами статичного или динамического тестирования и успешно устраняется.

«Тестирование черного ящика. Технологии функционального тестирования программного обеспечения систем», Борис Бейзер. СПб: Питер, 2004. 28 страница:

Симптом (отказ IEEE94). Наблюдаемое аномальное поведение любого объекта (не обязательно тестируемого), такое как несоответствие требованиям или возникновение незапланированных явлений.

Ошибка (сбой IEEE94). Просчет в проектировании, ведущий к возникновению симптомов у какого-либо объекта (тестируемого и не только) при прохождении этим объектом определенного теста.

«Стандартный глоссарий терминов, используемых в тестировании программного обеспечения», версия 2.3 (от 9 июля 2014 года), International Software Testing Qualifications Board, ред. пер. Александр Александров. 17, 36 и 38 страницы:

Недочет (fault) — см. «дефект». Дефект (fault) — это изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию, например, неверный оператор или определение данных. Дефект, обнаруженный во время выполнения, может привести к отказам компонента или системы.

Отказ (failure) — это отклонение компонента или системы от ожидаемого выполнения, эксплуатации или результата. (N. Fenton (1991), Software Metrics: a Rigorous Approach, Chapman & Hall, ISBN 0-53249-425).

Ошибка (error) — это действие человека, которое приводит к неправильному результату. [IEEE610].

Помеха (bug) — см. «дефект».

Просчет (mistake) — см. «ошибка».

«Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование», Рекс Блэк, Москва, Лори, 2006, 528/545 страницы:

Ошибка, дефект (Bug, Defect). Проблема, которая вызывается или может вызывать неадекватное выполнение системой одного или нескольких обоснованных ожиданий качества заказчика/пользователя.

«Верификация программного обеспечения», С.В. Синицын, Н.Ю. Налютин. МИФИ, Курс лекций, 2006, 19 страница:

Ошибка — действие программиста на этапе разработки, которое приводит к тому, что в программном обеспечении содержится внутренний дефект, который в процессе работы программы может привести к неправильному результату.

Отказ — непредсказуемое поведение системы, приводящее к неожидаемому результату, которое могло быть вызвано дефектами, содержащимся в ней.

«Основы инженерии качества программных систем», Филипп Андон, Галина Коваль, Татьяна Коротун, Екатерина Лаврищева, В. Суслов. Академпериодика, 2007. 218-220 страницы:

Ни за рубежом, ни в Украине, не достигнуто согласия по определению основных понятий в этой области — дефект, ошибка, отказ. Эти понятия по-разному определяются не только в научной литературе по качеству и надежности программного обеспечения, но и в стандартах. Проще всего поступили разработчики стандарта IEEE Std.1044 «Standard Classification for Software Anomalies» (Стандартная классификация аномалий программного обеспечения), которые предпочли использовать единый термин «аномалия» (anomaly) вместо других — error, fault, failure, incident, flaw, problem, gripe, glitch, defect или bug — что для целей этого стандарта оправданно.

Существуют глубокие причинно-следственные связи между отказами программной системы в эксплуатации, дефектами в поставляемом программном обеспечении, ошибками разработчика и изъянами в процессах создания программной системы (рисунок 5.13).

Отказ (failure) — событие перехода программной системы из работоспособного состояния в неработоспособное или получения результатов, которые находятся вне области допустимых значений. Отказы программной системы могут быть обусловлены как внешними причинами (ошибками элементов среды функционирования, в том числе человека-оператора), так и внутренними причинами — дефектами в программной системы.

Дефект (defect) в программной системе — запись элемента программы (кода) или текста документа (рабочего продукта), использование которой может привести к событию, заключающемуся в неправильной интерпретации этого элемента компьютером (ошибке (fault) в программе — ошибочному состоянию программы) или человеком (ошибке (error) исполнителя — заблуждению исполнителя).

Дефект всегда является следствием ошибки исполнителя процесса на любом из этапов разработки. Дефектом могут обладать спецификации требований, проектные документы, тексты кода, эксплуатационная документация и т. д. Выходные рабочие документы одних процессов, содержащие не устраненные при проверке дефекты, служат входными документами для других процессов, а дефекты в них — источником ошибок исполнителей этих процессов. Кроме того, ошибки исполнителей могут являться следствием изъянов в определении процессов (неправильная последовательность действий, неправильно выбранный инструмент и др.), способствующих неправильной интерпретации исходной информации человеком и принятию неверных решений, или просто недостаточной профессиональной зрелостью. Ошибки исполнителей, в свою очередь, приводят к дефекту в рабочем продукте, и цикл «ошибка (error) — дефект (defect) — ошибка (error)» повторяется.

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

Если дефект «срабатывает» — возникает цепь ошибок, передаваемых от модуля к модулю. Если ошибка не компенсируется в программе (благодаря встроенным в программу средствам отказоустойчивости или в результате случайного «срабатывания» другого дефекта), — она может привести к аномалии в функционировании программной системы. Считать ли аномалию отказом — зависит от определения понятия отказ в спецификации требований к разрабатываемой программной системы. Обычно говорят, что в результате выполнения программы произошел инцидент (incident), который проявился в виде определенной аномалии. Последующий анализ инцидента и аномалии может показать наличие проблемы (problem) или ее отсутствие. О проблеме составляется отчет, который в виде входного документа направляется процессу «Управление решением проблем». Таким образом, схему отказа программы можно представить цепочкой дефект в коде:
дефект в коде (defect) [- ошибка (fault)] — аномалия (anomaly) = отказ (failure).

«Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах», Роман Савин, Москва, Дело, 2007. 18 страница:

Баг (bug) — это отклонение фактического результата (actual result) от ожидаемого результата (expected result). В соответствии с законом исключенного третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого.

«Сертифицированный тестировщик Программа обучения Базового уровня», версия 2011 (от 13 апреля 2011 года), International Software Testing Qualifications Board, Андрей Конушин (председатель), Александр Александров, Алексей Александров, Татьяна Смехнова, Елена Абрамова. 12/101 страница:

Просчет — это сделанная человеком ошибка, которая порождает дефект (недочет, помеху) в программном коде или документе.

«Краткие основы тестирования программного обеспечения», А.Н. Коробейник. Киев: Директ-лайн, 2012. 10 страница:

Первый официальный отчет о дефекте в работе компьютера датируется 9-м сентября 1947 года. Грейс Хоппер работая с релейным вычислительным компьютером обнаружила сбои в работе оборудования. Разобрав компьютер её команда увидела что между движущимися частями застряла моль, что и мешало правильной работе компьютера. Насекомое было извлечено и прикреплено к журналу отчета об ошибке. Так был создан первый официальный отчет о дефекте, который и назвался в честь погибшего насекомого — Bug Report (отчет о насекомом). С тех пор дефекты в профессиональном жаргоне называются багами (bug — от англ. жук), а 9-е сентября считается днем тестировщика, профессиональным праздником.

Эта заметка-конспект является ответом на одну из тем экзаменационного вопроса вузов и ISTQB. Полный перечень вопросов привел в заметке Учебные программы, экзаменационные вопросы и литература по обеспечению качества и тестированию программ.

Манифест удаленной работы

В мае рассказывал про чтение книги Кали Рестлер и Джоди Томпсон «Офис в стиле фанк» о работе «откуда угодно и когда угодно». Но получилось скомкано и без минимального конспекта. Исправляюсь.

В книге «Why work sucks and how to fix it» авторы берутся описать пороки каждодневных приездов в офис и имитации восьмичасовой рабочей активности и живо преподносят впечатления и эмоции людей от перехода к стилю удаленной работы. Кали и Джоди удалось донести абсурдность каждодневных высиживаний восьми часов в душных офисах и передать энергию, увлеченность идей удаленной работы. Знакомство с книгой позволило составить четкое представление о том какого рабочего процесса стоит избегать и какой организационный стиль следует искать.

«Офис в стиле фанк» содержит упоминание внутреннего исследования BestBuy на группе из 320 человек со статистическими выдержками, но к сожалению более нет ссылок на сторонние исследования по теме, труды других авторов по тематике удаленной работы. Во время чтения произведения часто ловишь себя на мысли о чрезмерном количестве прилагательных, наречий, редком упоминании фактов, цифр. Создается впечатлении о недостаточной глубине труда. В определенный момент авторы разозлили настолько, что поставил на Goodreads рейтинг 1/5 и отбросил книгу. Но спустя некоторое время вернулся к произведению, дочитал до конца и не жалею.

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

Что происходит в офисах сейчас:

  1. «Мы приезжаем на работу и, вместо того чтобы думать, как лучше достичь результата, пытаемся сообразить, как добиться своих целей и при этом удержаться в жестких рамках рабочего дня с восьми до пяти часов». 40 страница
    +
    Думаю ли я как достичь результата на работе? Нет, я не думаю о результате, особенно, когда есть обязательство вести учет затраченного на задачи времени. Думаю о списании времени, о соблюдении рамок какого-то времени, а вечером не забыть разбросать суммарные затраты времени в Redmine или Jira.
  2. «Помимо того, что нам, пока мы находимся на работе, приходится соответствовать этим требованиям, нас еще вынуждают отказываться от всех личных планов — на них просто не остается ни энергии, ни времени, а значит, мы лишены возможности регулировать собственную жизнь». 60 страница
    +
    Пробудь девять часов в офисе, удели два часа дороге и после одиннадцати часов ни на что энергии больше не остается.
  3. «Если отказать людям в праве регулировать и планировать свою личную и трудовую жизнь, то они просто не смогут ни жить, ни работать с полной самоотдачей». 61 страница
    +
    Добрый день, меня зовут Алексей и у меня нет право регулировать и планировать свою жизнь. Я наврядли могу сделать что-либо с полной отдачей, будь то вопрос в личной или рабочей жизни.
  4. «В противостоянии ноутбука и табельного таймера побеждает последний». 61 страница
    +
    Таймер побеждает с завидным преимуществом, показывая всю никчемность официального учета времени и восьмичасового присутствия в бетонных коробках.
  5. «Чтобы демонстрировать свое постоянное присутствие на рабочем месте, мы перекусываем, не отходя от стола, но что могло бы помешать нашей досягаемости, если мы съели бы свой бутерброд, сидя на скамейке в соседнем парке». 62 страница
    +
    Уйти в парк, уйти во двор. Там поесть, там открыть ноутбук и сделать свою работу. Мечта.
  6. «Нас всех отягощает культура отстоя, но когда люди научатся не судить друг друга на основании убеждений о рабочем времени и месте и смогут стать выше мутного сознания и преодолеть свои привычки, они не станут поддерживать давно отжившие правила. Мы должны наконец избавиться от отстойной мути, и тогда работа перестанет изматывать нас до предела». 63 страница
    +
    Этот повседневный и всеохватывающий отстой имеет в нашем обществе слишком сильные корни и чрезмерно крепкие позиции. На вскидку можно пересчитать по пальцам компании, которые поддерживают стиль иключительно результативной рабочей недели. Например, дизайн-бюро Артема Горбунова, издательство «Манн, Иванов и Фербер», возможно компания Lazada.
  7. «Я не сразу поняла, что во многом разница между нашей командой (в которой в принципе никто не злоупотреблял мутью) и соседней (сотрудники которой проводили в офисе каждый рабочий день) объяснялась поведением руководства. Наша начальница доверяла нам». 65 страница
    +
    Какая приятная характеристика работы — доверие с начальником. Наверное это профессиональное счастье найти руководителя, который не только говорит об отсутствии претензий и наличия доверия, но и действительно доверяет работнику.
  8. «Джоди сама разрабатывала процедуры для преодоления культурных различий между компанией и ее партнерами, поэтому понимала, какую важную роль играет культура в деле внедрения изменений. Когда вы стремитесь научить людей поступать иначе, но при этом не обращаетесь к культуре, лежащей в основе их поведения, поражение неизбежно. Неписаные правила всякий раз будут брать верх над писаными». 77 страница
    +
    Ох уж эта культура в компании, эти неписанные правила. Ими пронизано все. Кто формирует эту культуру, атмосферу в компании? HR, отдел кадров? А если они не справляются и в компании нет атмосферы для результативной работы?
  9. «Можно также рассматривать муть как своего рода кодекс, охраняющий статус-кво. Поскольку нельзя открыто сказать то, что очень хочется, мы выбираем обходные пути. Мы говорим: „Одиннадцать часов, а вы только сейчас появились на работе?“, потому что не можем сказать: „Это несправедливо! Я, между прочим, приехал к восьми, как все“. Мы говорим: „Снова на отдых? Сколько же у вас отпускных дней, и откуда вы их берете? А я уже пять лет не могу никак вырваться!“, потому что не можем сказать: „Бездельник! Своей работе предан только тот, кто жертвует личным временем“». 78 страница
    +
    Прекрасные слова, которыми можно описать рабочий процесс в кабинете. И возможно в других отделах.
  10. «Предчувствие мути — напрасная трата времени и энергии, которых всегда недостает как в деловой, так и частной жизни. Выше мы привели пример, когда квалифицированный, с развитым чувством ответственности работник тратит драгоценные силы и время — ради чего? Чтобы оправдать потерю каких-то ничтожных пятнадцати минут? Пусть даже целого часа — есть ли в этом хоть малейший смысл?». 81 страница
    +
    Предчувствие мути, трата энергии, муть, бессмысленность, опять предчувствие. Вот характеристика традиционной рабочей атмосферы.
  11. «Во-вторых, рабочее кресло, на котором сотрудник должен сидеть целый день, важнее идей, которые могут появляться во время перекура; в-третьих, пожилые люди не в состоянии работать эффективно. Вместе с тем каждое из высказываний подобного рода выполняет более общую функцию. Таким нездоровым, извращенным способом муть объединяет людей. Это отголоски древней приверженности к племенному обособлению. Мы с тобой из одного племени. А тот человек — чужак». 85 страница
    +
    Да, помещайся в кресле и весь день что-то набирай на клавиатуре. Ты наверняка хороший работник. Никаких прогулок, в кресло! Или «стул оператора», что у тебя там.
  12. «Люди поднимают в коллективе муть с самого дна, когда под личиной „общественного мнения“ им хочется скрыть собственную неполноценность и несостоятельность. Им нет нужды чувствовать свою ответственность или проявлять инициативу — они и без того исправно присутствуют на работе все положенные часы. Им нет надобности достигать высокого уровня квалификации и профессионализма — намного проще выставить некомпетентным коллегу. Им нет смысла выдвигать идеи — ведь можно сделать так, чтобы кто-то из коллектива выглядел глупее их». 85 страница
    +
    Да, давайте найдем виноватых, будет нагнетать, тратить энергию, показывать глупость и забывать про результаты.
  13. «Муть даже в малых количествах всех нас связывает по рукам и ногам. Мы могли бы долго перечислять, чем именно она вредит общему делу любой компании, но ограничимся малым: муть понижает чувство ответственности у сотрудников, лишает их здоровых стимулов, тормозит развитие бизнеса. В итоге все сводится к одному: она лишает нас здравого смысла». 86 страница
    +
    Безответственность, вялость, деградация, уход.
  14. «Пока мы миримся с любыми проявлениями мути, мы тем самым будем утверждать правомерность тех рабочих условий, в которых имеют значение только время присутствия и видимость работы, а не подлинные достижения. Если наш труд оценивают по справедливости, если нам платят на основании вклада, вносимого в деятельность организации, то и рабочие часы, и наше присутствие за рабочим столом перестают играть важную роль». 86 страница
    +
    Та действительность, которую работодатели отвергают, преграждая путь развитию и успехам.
  15. «Что происходит, когда кому-то удается справиться с работой за тридцать шесть часов в неделю, а не за сорок? Обязательно ли требовать с него еще четыре часа работы? Должен ли начальник дать этому сотруднику работу еще на четыре часа?» 110 страница
    +
    Еще работы, еще задач. Основание для вознаграждения высеженное время в офисе, видимость деятельность. Ты быстр и эффективен? Получи еще ворох задач.
  16. «Для работников с почасовой оплатой условия несколько иные. У почасовиков также нет строгого графика, они вправе работать столько времени, сколько им нужно: по часу в день, начинать с десяти вечера, трудиться всю неделю без отдыха, — главное, строго контролировать оговоренный срок выполнения заказа. Увы, из-за постановлений министерства труда почасовикам, чтобы получать зарплату, по-прежнему приходится вести учет времени. Мы считаем это нелепым и устаревшим. Необходимость следить за отработанными часами даже в том случае, когда добиваешься хороших результатов, вынуждает людей чувствовать себя гражданами второго сорта. В условиях инновационной экономики такое положение вещей не только не идет на пользу работнику, но и вредит бизнесу. Мы убеждены, что в конце концов министерству труда придется пересмотреть и изменить законы в соответствии с новыми реалиями глобальной экономики, а пока для почасовиков существует одна возможность — перейти полностью на систему ROWE». 111 страница
    +
    Timetracking, учет времени, учет времени прихода и ухода, учет времени использования компьютера посещаемых сайтов, блокировки отдельных сайтов, вот почему все это кажется таким противоестественным. Ты чувствуешь себя второсортным человеком к которому применяют унижающие достоинство процедуры.
  17. «Сотрудникам, занимающим низкие должности, отпуск приходится заслуживать, а расчет им производят по формуле, в которой учитываются только отработанные часы. Нас ценят не за успехи, нас награждают за время, проведенное в рабочем кресле». 150 страница
    +
    Вот и проводим рабочее время, работая или имитируя, как тут разобрать.
  18. «Даже рядовые сотрудники, беспрестанно жалующиеся на давление со стороны начальства, способны оценить удачно составленный график работы. Он избавляет от неопределенности, помогает решить, как расходовать время, но вынуждает обращать внимание на количество отработанных часов, а не на достижение результатов, что создает напряженное состояние иного рода... графики создают новую проблему. Если их спускают сверху, значит, они составлены только с учетом интересов руководства. Передвигая своих подчиненных по графику работы, управляющие упускают из виду, что сотрудники не шахматные фигуры; каждый человек может выдвинуть свои требования о работе и рабочем времени». 153 страница
    +
    А мой таймтрекинг, не ответвление ли от мути? Ответвление, поскольку все то же отсутствие сосредоточенности на результатах.
  19. «Мы работаем на ноутбуке, но он всегда стоит на одном и том же месте, как стационарный компьютер». 162 страница
    +
    Вопрос потенциальным работодателям — а где могут работать ваши работники? Ваши работники работают за стационарными ПК или за ноутбуками? Если за стационарными, то почему? Вы хотите экономить деньги или на это есть объективные причины? Например, когда нужно мощный ПК. Может быть у вас есть тестовые машинки доступные через программы удаленного доступа, например VNC?
  20. «Все мы теперь так или иначе превращаемся в информационных работников. С этим связан довольно курьезный момент. Большинство людей ежедневно отправляются в некое физическое пространство, чтобы выполнять виртуальную работу». 162 страница
    +
    Очень верная мысль. Добраться общественным или личным транспортом до «загончика» и просидеть восемь часов.
  21. «Когда людей вынуждают изо дня в день находиться в строго определенном месте в течение строго определенного времени, им незачем прилагать максимум усилий. Поэтому, если нужные идеи посещают в другом месте и в другое время, они отмахиваются от них». 163 страница
    +
    Да, да, да, это наверное лучший момент книги.
  22. «А когда они находятся на работе, им довольно часто хочется оказаться где-нибудь в другом месте. Ничто не подавляет наше творческое и созидательное начало так же успешно, как ощущение недовольства». 163 страница
    +
    Творить тест-планы, работать из кафе, из парка или дома, творить и развивать, обучаться.
  23. «Поэтому они все выполняют медленнее, чтобы работа заняла у них социально приемлемый отрезок времени. Даже если они сомневаются в необходимости выполнения низкоприоритетных задач, но не перестают выполнять их из опасения, что их увидят бездельничающими». 178 страница
    +
    Суть восьмичасовки.
  24. «Среди ваших коллег наверняка есть люди, постоянно хвастающиеся своей марафонской рабочей неделей. Причем это делается с таким упоением, что каждую минуту ждешь: сейчас в качестве доказательств начнут предъявлять боевые шрамы!». 194 страница
    +
    Есть такие коллеги. А еще вспоминается эпизод сериала «Suits», где поощряли работника за переработки, ставили в пример рабочему коллективу. Вот она нездоровая атмосфера.
  25. «Работа выполняется, но не всегда самым эффективным образом. Лучшие работники уходят из компании в поисках более здорового баланса жизни и работы. ROWE может стать для вашей организации источником энергии и ответственности, а также значительно улучшить результаты работы... ROWE переведет вашу организацию на следующий уровень производительности и поднимет настроение сотрудникам. Сосредоточенность только на результатах, развития продуктивности, подробное и понятное описание работы и четкая формулировка целей — вот что даст людям возможность работать увлеченно, внедрять новшества, демонстрировать проактивность, эффективность и заинтересованность». 224 страница
    +
    Сейчас выполняю работу, но чувствую как малоэффективно это получается. Энергии на жизнь не остается.
  26. «Это все равно, что задавать вопрос „что новенького?“, вместо того чтобы просто заглянуть в интернет и прочитать новости. Коллеги вовсе не обязаны заменять нам поисковик, справочник или словарь. В случае насущной необходимости нам, наверное, сможет помочь не только один человек. А если на ваш вопрос действительно способен ответить лишь единственный сотрудник организации, значит, это проблема системы, а не вина отсутствующего сотрудника». 248 страница
    +
    Знакомое неуважительное поведение, когда без ясности и определенности в обязанности тебя пытаются превратить из тестировщика в голосового ассистента Siri.

Как должен выглядеть интеллектуальный труд работник IT-сферы:

  1. «Компании возглавляют отнюдь не тупицы. Они понимают, что свободный режим рабочего дня может стать великолепной приманкой для привлечения талантливых людей». 68 страница
    +
    Свободный режим рабочего дня равняется признанию таланта профессионала?
  2. «В экспериментальной программе приняли участие 320 человек, и все сообщали о снижении уровня стресса, повышении ответственности и производительности. По общему мнению участников, никогда прежде они не чувствовали себя такими счастливыми». 76 страница
    +
    Хотелось бы верить. Что может быть прекрасней, чем производительная работа с ощущением необходимости выполняемой работы и счастья от результатов?
  3. «И не забывайте о главном — о том, что необходимо сегодня выполнить на работе. Справляетесь ли вы сами с этим заданием? Справляются ли коллеги? Все прочее — кто когда пришел, сколько времени провел на рабочем месте, как долго обедал — не ваша забота». 89 страница
    +
    Думал ли я сегодня про необходимое для выполнения? Нет, разбирался с валом задач, опасаясь вала всей этой кучи.
  4. «Задача работодателя — поставить конкретные цели, сформулировать определенные ожидания. Мы не имеем в виду описания должностных обязанностей, в которых излагаются только самые общие требования к работе сотрудника. Мы говорим о предельно ясных ожиданиях — о том, что необходимо делать ежедневно, за неделю, за месяц, за год. Задача сотрудника — с помощью обучающей системы, советов наставника или рекомендаций руководства — достичь этих целей и оправдать ожидания. Если по ходу дела возникают сомнения, трудности или проблемы, то объектом пристального внимания становится само дело, а не отработанные часы или впечатление, которое производит сотрудник. От работников требуется умение направить все свои способности и навыки на достижение поставленных целей. Работодатели рассчитывают, что работа будет выполнена. Все остальное, не имеющее отношение к этой задаче, отпадает». 110 страница
    +
    Золотой абзац. В моем распоряжении в JIRA три десятка задач и я не знаю, какие из них надо сделать сегодня, а какие можно и завтра. Весь этот скоп не оформлен в календаре и выглядит безумной кучей, мешаниной, которая дестабилизирует меня, вызывает дискомфорт и нежелание работать. Нет ясности в ожиданиях.
  5. «Концепция сосредоточенности внимания только на выполнении работы дает огромный эффект». 110 страница
    +
    Только выполнение работы.
  6. «Однажды я так провел выходные: побывал на фестивале еды „Вкус Чикаго“, поиграл в криббедж, побросал летающий диск в парке; вдобавок ко всему, воскресным вечером сходил на представление „Город ветров“. Утро понедельника я встретил в Чикаго. Но я ни о чем не беспокоился, кроме разве что одного — успею ли вернуться в Миннеаполис вовремя, к благотворительному концерту, устроенному компанией Best Buy, чтобы послушать Дэйва Мэтьюза второй вечер подряд. К прошлому уик-энду я добавил нерабочие пятницу и понедельник, и устроил нам с моей девушкой поездку. Мы разбили лагерь в местном лесу, побывали в музыкальном театре „Альпийская долина“, на концерте ее любимой группы Nickelback. Воскресенье я провел в аквапарке „Ноев ковчег“, катаясь на водных горках. Скоро я снова собираюсь в Чикаго, на музыкальный фестиваль Lollapalooza, а потом — еще раз в „Альпийскую долину“ и на концерт в кемпинге, куда съедутся человек сорок моих друзей со всей Америки». 127 страница
    +
    Это прекрасно.
  7. «Приход на работу в два часа дня не считается опозданием. Уход с работы в два часа дня не считается слишком ранним. По сути, этот фундаментальный принцип означает, что в условиях ROWE в центре внимания находятся результаты работы, а не отработанные часы. Время уже не служит определяющим фактором, когда требуется решить, работаете вы или нет. Нет ни опозданий, ни ранних приходов или уходов, только выполнение или невыполнение работы». 132 страница
    +
    Вот это ради чего читаю и слушаю книгу — ориентир к истинной работе.
  8. «Вам незачем следить за стрелками и думать: „Так, уже три часа, значит, эту часть надо завершить к концу рабочего дня, то есть к пяти. А прочие дела отложу до завтра, пусть подождут до восьми утра, когда приду на работу“. Вместо этого можно, глянув на часы, решить: „Так, три часа, значит, можно уйти прямо сейчас, пока не начался час пик. Вернусь домой, перекушу, отдохну, а в восемь возьмусь за проект и к полуночи уже все закончу, а завтра примусь за следующий этап“». 138 страница
    +
    Отличный пример.
  9. «Мы перестаем играть в игры с рабочими часами и обманывать самих себя (в такие-то часы я должен работать, а в такие-то — нет); вместо этого мы уделяем все внимание тому, чего от нас требует работа. Причем, когда нам ее делать, решаем мы сами — главное, уложиться в срок. Например, проснувшись в пять утра, человек вдруг находит решение проблемы и сразу, без всякого чувства раздражения или вины, приступает к работе. Позже, с восьми до одиннадцати, он может заняться личными делами или посвятить это время своим домашним — все так же продолжая пребывать в спокойном расположении духа, не дергаясь и не комплексуя». 139 страница
    +
    Не дергаясь и не комплексуя, без раздражения и вины.
  10. «Контролировать подчиненных так, как прежде, начальству незачем. Теперь у меня намного больше стимулов, потому что в моей жизни появилось хоть какое-то равновесие. Я могу отказываться от того, что не прибавит эффективности моей работе, и браться только за те дела, которые вызывают у меня глубокий интерес. Могу основательно проанализировать нашу конкурентоспособность. Могу предложить то, что более благоприятно для нашей группы». 157 страница
    +
    Это очень важно.
  11. «Доверие и меняет жизнь к лучшему, и обеспечивает результативность. Какие тут могут быть возражения?». 158 страница
    +
    Возможно на хороших местах работы практикуют опросники методом 360 градусов и получают обратную связь об отсутствии доверия в коллективе.
  12. «Дайте людям возможность распоряжаться своим временем и работой, и они начнут отыскивать творческие и новаторские решения в любое время, находясь при этом в самых неожиданных местах. В условиях ROWE люди работают в том месте и в то время, где и когда им удобнее, следовательно, они меньше часов и сил тратят на присутствие на работе, и больше времени и энергии — на собственно работу. Это означает, что больше не понадобится тратить несколько часов, чтобы сначала добраться до офиса, а потом из офиса домой. Часть этого времени отныне посвящена решению проблем, возникающих на работе. Остальное время целиком наше». 163 страница
    +
    Волшебный абзац.
  13. «Это означает, что презентеизму конец. Если работа перестает быть тем, куда ходят, и становится тем, что делают, от нее уже не спрячешься. Если не соответствуешь ожиданиям и не достигаешь поставленных целей, нельзя оправдаться „присутствием на рабочем месте“ и созданием видимости упорной работы». 164 страница
    +
    Презентеизм прощай.
  14. «Сотрудники вправе работать теми способами, которые выбирают сами. В условиях ROWE уже нельзя судить людей по тому, каким способом они работают, поскольку не все одинаково усваивают и обрабатывают информацию. В новой среде люди и их навыки стоят на первом месте, работа — на втором. Пока работа выполняется, беспокоиться о том, каким образом это происходит, незачем (разумеется, при условии, что люди ведут себя порядочно, не совершают ничего противозаконного и способствуют общему успеху компании). Но осуждать индивидуальный стиль работы уже нельзя». 165 страница
    +
    Почему нельзя судить по усвоению информации.
  15. «Вам лучше думается во время ходьбы? Отправляйтесь на прогулку. Вам лучше работается по ночам? Трудитесь ночью. Вам удобнее работать по традиционному графику? Трудитесь с восьми до пяти. Все возможно». 165 страница
    +
    Чудесная возможность выбора.
  16. «Одна сотрудница в разговоре с нами призналась, что стала ориентироваться в первую очередь на цели. Раньше она привыкла растягивать решение задачи на целый день, но поскольку теперь время принадлежит ей, а работа выполняется на ее условиях, она предпочитает заниматься всеми делами, не откладывая их. Даже когда до крайнего срока завершения проекта остается три дня, наша знакомая и ее коллеги могут сотрудничать друг с другом круглосуточно, зная, что затягивать работу не в их интересах». 166 страница
    +
    Знакомая мне ситуация, когда я в кандалах с 09 до 18.
  17. «Осталось в прошлом стереотипное представление о сотрудниках, работающих дистанционно, — если вы не в офисе, значит, по-настоящему не трудитесь». 167 страница
    +
    А разве осталось? Откуда такое убеждение? У нас так думают на работе и сейчас.
  18. «В итоге люди берут работу под личный контроль. Им платят за результаты, поэтому они ведут себя, подобно предпринимателям. У них возникает ощущение личной заинтересованности в бизнесе». 168 страница
    +
    Это было бы великолепно.
  19. «С другой стороны, руководители вынуждены теперь брать на себя роль наставников, а не надзирателей. В их задачи уже не входит контроль и ожидание, когда подчиненные успешно справятся с работой или провалят порученное дело. В условиях ROWE руководители занимают более активную позицию в достижении успеха сотрудниками, потому что, если они не в состоянии объяснить, какие цели стоят перед подчиненными и какие надежды на них возложены, всей системе грозит крах. Судить о людях по тому, насколько исправно они являются на работу, уже не получится, — оценивать их предстоит только по результатам работы, следовательно, надо совершенно ясно представлять себе, какая работа должна быть выполнена». 175 страница
    +
    Сформировать видение о том, какая работа должна быть выполнена.
  20. «Меньше времени тратится на попытки осчастливить людей туманными обещаниями». 175 страница
    +
    Уделить больше времени достижению результатов, нежели выслушиванию туманных устных обещаний.
  21. «Вашему коллеге незачем во всех подробностях знать, чем и как вы занимаетесь, но в ваше отсутствие он должен иметь представление о том, в чем вы участвуете и как продвинулись в выполнении своего дела». 175 страница
    +
    Опять же в условиях ненормальности, отсутствия четкости и планомерности необходимо формировать какую-то свою четкую картину плана работы и нынешнего положения дел.
  22. «Сотрудники начинают чувствовать личную ответственность, так как имеют право решать, что для них выгоднее. Какой стиль работы окажется наилучшим? Какое время суток будет наиболее продуктивным? Каким образом они могут внести максимальный вклад в работу компании?». 178 страница
    +
    Это было бы здорово.
  23. «Теперь мы с сестрой заботимся о маме поочередно. Например, я уезжаю в Индиану на эту пятницу, субботу, воскресенье и понедельник. С собой я беру ноутбук, поэтому не чувствую за собой никакой вины, зная, что по-прежнему вношу вклад в работу компании и забочусь о маме». 182 страница
    +
    В склад великолепных историй.
  24. «ROWE превратила мою работу из просто работы в то, что мне небезразлично». 182 страница
    +
    Как можно любить свою работу.
  25. «Система ROWE не облегчает труд, но благодаря ей работа не воспринимается как тяжелое наказание. Если на рабочем месте люди не чувствуют себя свободными, спокойными и самодостаточными, это означает одно: ROWE там нет. Потому что ключом к пониманию ROWE служит совершенно новое самоощущение человека на своей работе, которую даже трудно признать работой в привычном понимании слова. Рабочая среда становится принципиально другой — более подходящей человеческой природе». 189 страница
    +
    Отличное определение ROWE и быстрый способ понять, как обстоят дела в офисе.
  26. «Теперь я не могу не участвовать в жизни сына и его школы, а раньше об этом и не мечтала. Все свои отпуска и отгулы я тратила на то, чтобы помочь сыну в школьных делах. Но теперь я просто занимаюсь ими по мере надобности и не чувствую себя виноватой. Наконец-то я смогла познакомиться с его учителями». 230 страница
    +
    Не чувствовать себя виноватым.
  27. «Его друзья видят, как я приезжаю к нему в школу, участвую в его делах, знают, что я работаю в Best Buy и считают, что это лучшая компания». 231 страница
    +
    Вот оно истинное и честное привлечение людей, возможно истинно верная позиция компании.
  28. «Вы вправе распоряжаться своим временем. Вы вправе есть, когда голодны, и спать, когда устали. Да, все так просто... Ваш долг перед компанией — ваша работа, а не ваше время. Вы не должны отдавать ей свою жизнь». 232 страница
    +
    Это прекрасно. Это слова про принцип работы.
  29. «В системе ROWE отсутствие результатов означает отсутствие работы. Лентяям приходится либо перестраиваться, либо увольняться. А хорошие работники трудятся еще старательнее, потому что наградой им становится право распоряжаться собственным временем». 247 страница
    +
    Так можно было бы жить?
  30. «И еще одно: если проблемы с расписаниями, результатами и ожиданиями улажены, многие спонтанные запросы отпадают сами собой. Мы учимся заранее предвидеть все вопросы. Улучшается планирование, реже возникают экстренные ситуации. Нам уже незачем заглядывать к кому-нибудь из коллег в кабинет и отвлекать его от работы ради одного вопроса. Мы работаем более целенаправленно». 148 страница
    +
    То чего сейчас нет в организации — дальнозоркости, системности, оценки и предупреждения рисков. Люди подскакивают, что-то спонтанно придумывают, сообщают «мне нужно это сегодня».
  31. «Вероятно, наилучший способ оказать поддержку подчиненным — оставить их в покое и доверить им выполнение работы». 249 страница
    +
    Золотые слова.
  32. «Но ведь это непрофессионально — отвечать на вопросы клиента, одновременно делая личные покупки! Но если вы профессионально ответите на вопрос клиента, зачем сообщать ему, что вы разговариваете с ним, находясь в магазине? Если честно, то ему все равно. Клиенту нужна ваша помощь, а не подробности вашей частной жизни». 251 страница
  33. «Как мы узнаем, что работа идет, если не сможем видеть работников? В ROWE работа идет потому, что цели и ожидания совершенно ясны. Сведения Х следует предоставить сотруднику Y к такому-то времени. Если сведения не предоставляются вовремя, мы сразу узнаем об этом и действуем соответственно». 252 страница
    +
    Спонтанность, болтовня, отсутствие ясности ожиданий — вот что такое нынешнее место работы.
  34. «Взаимоотношения — это очень важно. Что будет с ними? Да, отношения — это важно. С ними все будет в полном порядке. Мы привыкли считать, что наши отношения улучшаются, если все мы находимся в одном и том же здании. Но пребывание в одном пространстве — еще не гарантия надежной связи». 252 страница
    +
    Да, совсем не мед пребывать в одном пространстве с товарищами, которые закрывают окна от открытого воздуха и от света, совершенно не интересуясь мнением своих соседей по кабинету. Было бы отлично выбрать самому свежесть и  освещенность на рабочем месте.
  35. «Как можно назначать совещания, если не знаешь, когда люди работают? В условиях ROWE совещания уже не назначают, не подумав. Расписание совещаний составляют на основании результатов, а не времени. Если результаты требуют присутствия тех или иных людей, они будут присутствовать на совещании». 253 страница
    +
    Так действительно бывает?
  36. «Как узнать, что штатные сотрудники отрабатывают положенные 40 часов? Никак. Это неважно. В условиях ROWE работу оценивают по результатам. Работникам говорят, что они должны делать, а они либо справляются с этой задачей, либо нет. Фактор времени не играет никакой роли. Люди начинают выдавать результаты, а не отсиживать часы». 253 страница
    +
    Возможно подобные заявления сейчас чрезмерны или даже революционны.
  37. Как быть с командами? Никто не озабочен сплоченностью, никто не добивается сплоченности только потому, что так принято. Люди объединяются потому, что этого требует достижение результатов... Зная, что коллег далеко не всегда можно застать в офисе, мы заранее принимаем меры, чтобы поддерживать друг друга в экстренных случаях. 253
    +
    Почему мы объединены в команду? Потому что так принято. Мы должны жить не в риске, а в профилактике риска заранее, прощупывании резервов и запасных вариантов.
  38. «Работа и частная жизнь не разграничены, как в таких условиях не перетруждаться? В условиях ROWE мы не перетруждаемся, поскольку для этого нет причин. За отработанные часы нас не награждают. Никто не считает нас героями только потому, что мы просидели за работой всю ночь, первыми явились в офис утром или не разгибали спины в выходные. Нас награждают только за продемонстрированные результаты. Если вы добились их, прекращайте работать, займитесь чем-нибудь другим. Очень удобно». 254 страница
    +
    Просто какая-то сказка в которой я хотел бы жить.

«Водянистые» моменты в книге:

  1. «ROWE — непрестанно развивающийся процесс». 115 страница
    +
    Как будто читаю проповедников. Никаких фактов или интересных мыслей, одни убеждения, голословные общие фразы.
  2. «Мы добились разрешения решительно отклонять удобные и привлекательные для всех, но ничего не решающие варианты. И мы начали напрямую выяснять, что именно нужно нашим сотрудникам, чего они хотят, какие решения окажутся для них наилучшими». 116 страница.
    +
    О чем здесь вообще сказано? Что за ерунда? Почему только наречия и прилагательные?
  3. «Мы понимаем, что все это кажется слишком масштабным, поэтому не может не вызывать паники у руководителей компаний. Им кажется, что они, утрачивая контроль, теряют власть». 120 страница
    +
    Нужно выполнить поиска и выяснить сколько раз авторы рассказывают как «все понимают».
  4. «Чтобы сохранить право на свою жизнь, человек будет стоять до конца». 123 страница
    +
    Вода надоела. Поставил на Goodreads рейтинг 1/5. Ужаснулся рецензии на LifeHacker.ru.
  5. «Сосредоточенность на результатах способна творить чудеса сотрудничества, планирования и управления». 225 страница
    +
    Продолжен проповеди.

Практика:

  1. Сотрудник выдает очередную муть: «Что-то у вас слишком часто болеет ребенок. Не боитесь, что это помешает вашей карьере?» На это следует отвечать спокойно и уверенно, без извиняющихся ноток: «Вам что-нибудь нужно? Чем я могу вам помочь?». 90 страница
    +
    Практический прием.
  2. «В условиях ROWE подход к делу меняется, потому что за работу, выполненную быстрее и эффективнее, сотрудников ждет не наказание, а награда. В условиях ROWE будет правильно, отработав половину недели или дойдя до середины проекта, спросить себя: делаю ли я все, что необходимо, для достижения цели? Если вы можете дать утвердительный ответ, значит, вы на верном пути. Если отрицательный, продолжайте спрашивать: что нужно делать? Это напоминает ответный маневр при столкновении с мутью: задайте себе вопрос, что надо сделать. Если вы сосредоточены на результатах и добиваетесь их, значит, ваше время принадлежит вам. Справились за тридцать шесть часов? Молодец! Наряжайтесь в изысканные и стильные одежды. Ведите детей в кино. Спасайте мир. Работу вы сделали. Никому нет дела до того, как вы потратите свое время». 110 страница
    +
    И далее замечательные слова про учет времени.
  3. «Рядовые работники сами должны потребовать для себя лучшей работы и жизни. Никто просто так не даст их нам». 234 страница
    +
    Путь к развитию. Руководство к действию.

«Офис в стиле фанк» на сайте издательства МИФ | «Why Work Sucks and How to Fix It» на Goodreads

3 июля   литература

Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах

В 2016 году коллега с удовольствием и восхищением упоминал книгу Романа Савина «Тестирование дот ком». Тогда я только начинал познавать азы тестирования, читал серьезных и обстоятельных Каннера, Фолка и Нгуена. Романа Савина листал, но читать всю книгу автора мешало предубеждение, созданное строкой «лучшие мгновения моего студенчества прошли не в аудиториях моей альма-матер, не в залах библиотек, а в пивной Коптевского рынка». Сейчас получилось преодолеть предубеждение, поверить в автора, прочитать первую из четырёх частей книги. Приятно удивлён легкости чтения и массе мыслей возникших во время чтения книги.

Счастье пользователя

Роман Савин с первых же страница книги вдохновляет и на 13 странице формулирует единственный смысл работы тестировщика — результат в форме счастья конечного пользователя... причем „счастья“ не в глобальном его значении, а той его частью, которая связана с качеством вашего продукта. Необходимо понимать, что осознание понятия «счастью пользователя» и стремление к его воплощения не должно являться уделом одного или нескольких идеалистов в компании. Не могу удержаться от цитаты двух абзацев Романа:

«Менеджмент должен сделать так, чтобы персонал понимал, что „качество“ и „счастье пользователя“ — это не фикция, а путь к финансовому успеху компании и соответственно лучшей жизни каждого, кто работает над проектом. Если менеджеры посмеиваются над мерами по улучшению качества и отпускают шутки о пользователях (даже в курилке!), то это тлетворно действует на всех сотрудников компании и в конечном счете негативно скажется на пользователях, а следовательно, по принципу бумеранга и на самой компании, включая „юмористов“».

«Пользователи знают, уважают их или нет, уже после одного сообщения об ошибке, одного е-мейла от компании или одного звонка в службу поддержки, и если философия компании — это „тупые юзеры“, то, поверьте, она проявится, на радость конкурентам, во многих вещах», 96 страница.

Функциональная баги и баги спецификаци

Важные слова с 20 и 24 страницы посвящены главному источнику ожидаемого результата для тестировщика — спецификации. Роман выражается проще Канера, Фолка и Нгуена и на 20-21 страницах отходит от терминологии «ошибка проектирования» и «ошибка кодирования» в пользу понятной и равнозначной пары «баг спецификации» и «функциональный баг».

Идея о статистике для пострелизных багов

Непонятным осталось пренебрежение Романа к количеству багов, найденных до релиза, высказанное на 30 странице книги.

Искусство создания тест-кейсов

Понятным и полезным оказалась мелочь про название очередного тест-кейса, когда на 37 странице автор предлагает изящный пример «Оплата может быть произведена картой VISA». Не мелочью оказалось напоминание 40 страницы о приоритезации тест-кейсов особенно полезной при регрессивном тестировании.

Впечатлила своей идее 43 страница книги, где описывается заманчивая практика написания data-driven тест-кейсов, когда происходит модификация только исходных данных: не нужно вносить изменения в шаги, а в каждом новом тест-кейсе подчеркиваем меняющиеся значения данных и меняем секцию ожидаемого результата. Замечательное разделение данных и инструкций по их применению.

Сбивает с толку 47 страница про один ожидаемый результат в тест-кейсе. Благо пару страниц спустя Роман подтверждает право на существование тест-кейсов, включающих более одного ожидаемого результата, что является нормальной ситуацией при проведении тестирования сложного программного обеспечения.

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

Цикл разработки программного обеспечения

Предотвращению тихого изменения спецификаций, внесению изменений без утверждения программистом и тестировщиком, посвящена 80 страница книги, описывающая процессуальную сторону вопроса и детали процедуры внесения изменений.

Подобные процедуры и устройство процесса разработки вдохновляет к работе. Как вдохновляет и напоминание Романа Савина про обязанность тестировщиков настаивать на максимальной иллюстрации спецификаций блок-схемами, макетами и примерами (БМП). БМП как чертеж физического объекта изображают объект, только не спереди, сверху и слева, а с описанием: алгоритма что и почему видит пользователь, с иллюстрацией графической и примером чего-либо описанного.

Обязательная к повторному чтению 89 страница про девять компонентов оздоровления кода и превентирования багов до передачи кода тестировщикам. Отмечаю для себя реализацию на работе только двух из девяти указанных пунктов. Такого компонента, как счастье пользователей уже касался в начале заметки и не могу не коснуться счастья команды разработки. Роман Савин очень живописно описывает заботу о команде через реальные финансовые рычаги стимуляция написания эффективного и «чистого» кода:

Хорошая заработная плата с возможностью увеличения; билеты в «Ленком»; премии за хорошую работу; неограниченные чипсы и диет-кола; оплата абонемента в бассейн и гимнастический зал; месячные проездные; выезды для игры в пейнтбол; беспроцентный кредит на машину; помощь при первоначальном взносе на квартиру, 95 страница.

Исполнение тестирования и ремонт багов

Роман предельно ясно описывает процесс тестирования. Сначала тест приемки (smoke test, sanity test или confidence test) для проверки основной функциональности. После его прохождения заморозка кода и тестирование новых компонентов (new feature testing) исполнением тест-кейсов, написанных по спецификациям данного релиза. После тестирования новых функциональностей выполнить «старые» тест-кейсы (regression testing), чтобы удостовериться, что компоненты ПО, которые работали раньше, все еще работают. Баги в отчеты, а после правки недостатков провести тест сдачи (Acceptance or Certification Test).

Релиз

На 118 странице Роман формулирует железное правило для тестировщиков и приводит пример простого разделения багов по критичности. Правило: «на каждый баг, для которого был произведен патч-релиз, должен быть написан тест-кейс приоритета 1. Этот тест-кейс добавляется к группе тест-кейсов для регрессивного тестирования соответствующей функциональности». Примеры: некритического бага — отсутствует проверка e-mail пользователя на два «@», можно отремонтировать в следующем релизе; критического бага — невозможно совершить покупку, отремонтировать и выпустить патч-релиз как можно быстрее.

122 страница книги учит, как во время релиза уважительно и предупредительно вести себя по отношению к пользователя. Вывешивать табличку о проведении технической поддержки, вернем работу сайта примерно в такое-то время и просим извинить за временные неудобства. Подробно объяснять обычную для on-line-бизнеса ситуацию и завершить вежливым «Извините». Быть честными перед пользователем.

Большая картина цикла разработки ПО

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

«Первое. Процедуры, стандарты, спеки, тест-кейсы и контактная информация должны быть задокументированы (пусть даже в электронном виде) и доступны на интранете.

Второе. Такие вещи, как утверждение спека, рассмотрение тест-кейсов или инспекция кода, — это не какие-то полицейские мероприятия, призванные подрезать крылышки творческим и свободным личностям. Совершенно наоборот — это средства, позволяющие (а) улучшить качество, (б) прикрыть спину, (в) стать хорошим людям еще лучше», 127 страница.

По итогу прочтения первой части книги «Тестирование дот ком» составил себе представление о компонентах рабочего процесса в достойной компании:

  1. ориентация на счастье пользователя, как основной составляющей корпоративной философии
  2. наличие письменных спецификаций для разрабатываемого продукта
  3. наличие требований к содержанию спецификаций и следование правилам их изменения
  4. наличие в спецификациях блок-схемам, макетов и примеров
  5. обязательное утверждение спецификаций тестированием и разработкой
  6. наличие инспекций кода
  7. использование стандартов программирования
  8. реальные сроки разработки программного продукта
  9. требования к альфа-тестированию, в виде юнит-тестирования программистами
  10. документирование тест-кейсов
  11. ревью тест-кейсов
  12. письменное уведомление клиентов о технических работах на сайте проекта
  13. хорошая заработная плата с возможностью увеличения
  14. премии за хорошую работу
  15. неограниченное питание и напитки
  16. оплата абонемента в бассейн и гимнастический зал
  17. месячные проездные
  18. выезды на спортивные командные игры
  19. беспроцентный кредит на машину
  20. помощь при первоначальном взносе на квартиру.

Место тестирования в процессах обеспечения качества

В учебных программах по дисциплине «Обеспечение качества и тестирование программ» есть темы «Место тестирования в процессах обеспечения качества», «Соотношение тестирования, контроля качества и обеспечения качества (quality assurance)» и «Процессы обеспечения качества: SQA, V&V, Тестирование». В программе обучения базового уровня International Software Testing Qualifications Board «Сертифицированный тестировщик» тема детализируется пунктом «Описать, почему тестирование — это часть обеспечения качества и привести примеры, как тестирование способствует повышению качества».

«Тестирование программного обеспечения. Фундаментальные концепции менеджмента бизнес-приложений», Сэм Канер, Джек Фолк и Енг Кек Нгуен, Москва, ДиаСофт, 2001. 431-434 страницы:

  • Существует четыре основных типа тестовых групп. У каждой из них своя роль в компании и свои задачи. (1) Группа контроля качества следит за соблюдением стандартов. (2) Группа обеспечения качества пытается тем или иным способом га­рантировать соблюдение стандартов. (3) Служба тестирования ищет и документирует ошибки. (4) Служба поддержки разработки выполняет ряд технических задач, и в том числе тестирование.
  • Группа контроля качества. Теоретически это очень влиятельное подразделение. Инспектор группы контроля качества (Quality Control) может задержать выпуск продукта до тех пор, пока не будут соблюдены все стандарты и процедуры и исправлены все ошибки. Какой заманчивой кажется сотрудникам служб тестирования и разработки такая власть! Но ничто не дается даром. Инспектор группы контроля качества не просто снимает с конвейера пару бракованных банок консервов. Он останавливает всю линию, возмож­но, единственную линию компании, и делает это не на пару минут, а на несколько дней, недель или месяцев. Руководство компании реагирует на такие события немедленно и может запросто отменить решение группы контроля качества и распорядиться выпускать продукт, каким бы ни было его качество.
  • Группа тестирования помогает руководству компании, предоставляя информацию о текущих проблемах разработки и степени их серьезности. Однако предоставление информации — это одно, а принятие решений — совсем другое. Здесь группа контроля качества обладает несколько более высокими полномочиями, чем обычная группа тестирования, поскольку может задержать выпуск продукта, не удовлетворяющего определенным требованиям. Однако сделать это она может только на некоторое время — пока руководство не проанализирует ситуацию, чтобы принять окончательное решение.
  • Группа обеспечения качества. Группа обеспечения качества (Quality Assurance) делает то, чего не может сделать обыкновенная группа тестирования, — она обеспечивает качество продукта. Для этого группа обеспечения качества участвует в разработке от первого до последнего дня, устанавливая стандарты, определяя процедуры контроля и обучая людей тому, как лучше проектировать и разрабатывать программные продукты. Таким образом, недостатки программ не просто устраняются, а предотвращаются. Группа обеспечения качества занимается также и тестированием, но это далеко не единственная ее работа.
  • Чтобы справиться со своей задачей, группа обеспечения качества должна обладать огромными полномочиями, а ее сотрудники — высочайшей квалификацией в целом ряде профессий. Они должны быть высококлассными программистами, техническими писателями, руководителями, проектировщиками и аналитиками. Иначе им просто не будут доверять.В любой компании имеется группа, отвечающая за определение стандартов, обучение персонала, управление работой и повышение ее эффективности, — это руководство компании. Именно оно обеспечивает качество выпускаемых продуктов.
  • Служба тестирования. В задачи службы тестирования (Testing Services) входит поиск ошибок и недостатков программы, их описание и предоставление этой информации всем, кому она необходима. Решений относительно выпуска продукта руководитель службы тестирования не принимает, он только предоставляет руководству информацию о том, насколько продукт протестирован и каково его качество.
  • Роль службы тестирования в разработке продукта может быть различной. В некоторых компаниях основными тестировщиками считаются сами программисты, а служба тестирования им только помогает. Как бы там ни было, служба тестирования отвечает за техническую сторону этой работы: анализ объекта тестирования, проектирование и подготовку тестов, их выполнение и документирование... Она отвечает за качественное тестирование, интерпретацию его
    результатов и их своевременное предоставление руководству, документирование своей работы. Но ни контролирующей, ни руководящей роли у нее нет. Участие службы тестирования в управлении проектом скорее косвенное, чем непосредственное. Ее сила заключается в собираемых данных и умении правильно их представить. И сила эта немалая. Переговорами и убеждением нередко удается достичь гораздо большего, чем просто отменой выпуска продукта или вводом новых процедур и стандартов.
  • Служба поддержки разработки. Концепция службы поддержки разработки (Developing Services) является расширением концепции службы тестирования. Обе они являются службами, а значит, предоставляют чисто технические услуги — это не административные, не контролирующие и, как правило, аполитичные группы. Они помогают улучшить продукт, созданный другими сотрудниками (программистами), используя для этого профессиональные навыки, которых у программистов нет. Если служба тестирования только тестирует продукт, то у службы поддержки разработки есть и другие задачи... Основной задачей службы поддержки разработки остается тестирование, но в зависимости от нужд конкретной компании могут выполняться следующие задачи. (1) Отладка. (2) Техническая поддержка пользователей, особенно в первые недели после выпуска продукта. (3) Редактирование копии руководства пользователя. (4) Техническое редактирование руководства (с правом вносить изменения, которого обычные тестировщики не имеют). (5) Анализ эксплуатационных характеристик продукта. (6) Сравнительная оценка продукта. (7) Изучение пользовательского удовлетворения продуктом.

«Ключевые процессы тестирования. Планирование, подготовка, проведение, совершенствование», Рекс Блэк, Москва, Лори, 2006, 531/545 страница:

Оценка качества (в отличие от тестирования) (Quality Assurance contrasted with Testing). В соответствии со стандартом IEEE 610.12-1990 стандартный глоссарий терминологии по программированию («IEEE Standard Glossary of Software Engineering Terminology») говорит: оценка качества (QA) включает в себя «всякую деятельность, необходимую для обеспечения достаточной уверенности „в качестве системы и оценку“ процесса, с помощью которого [система] разрабатывалась», тогда как тестирование состоит из действий, необходимых для «обнуражения различий между существующими и требуемыми условиями (ошибок) и оценки... свойств». Другими словами, оценка качества фокусируется на корректности процесса, а тестирование — на установлении качества.

Качество (Quality). 1. Пригодность для использования. Наличие свойств, атрибутов и функций, удовлетворяющий ожиданиям заказчиков и пользователей, и отсутствие свойств, атрибутов и функций, неудовлетворяющих ожиданиям заказчиков и пользователей. 2. Соответствие требованиям. Наличие свойств, атрибутов и функций, удовлетворяющих всем уставленным требованиям, и отсутствие свойств, атрибутов и функций, отклоняющихся от требование. (Данное определение применимо в конкретном контексте, в особенности для проектов, выполняемых по контракту.)

«Основы инженерии качества программных систем», Филипп Андон, Галина Коваль, Татьяна Коротун, Екатерина Лаврищева, В. Суслов, Академпериодика, 2007. 39, 41, 42, 303 страница:

  • Первый шаг к повышению качества ПС состоит во внедрении в повседневную практику организаций-разработчиков специально предназначенных для этого поддерживающих процессов жизненного цикла программной системы, регламентируемых стандартом ISO/IEC 12207:1995 «Information technologies. Software life cycle processes» (или ДСТУ 3918) по процессам жизненного цикла программной системе, а именно процессов гарантирования качества, верификации, валидации, совместного просмотра и аудита. Применение этих процессов обеспечивает руководство организации и проекта методами и средствами контроля за соблюдением требований к процессам разработки и качеству рабочих продуктов на каждой стадии жизненного цикла проекта.
  • Применяемый далее термин «гарантирование качества» соответствует обычно используемому за рубежом термину «Software Quality Assurance» (SQA), получившему в издаваемой у нас переводной литературе по программной инженерии и отечественных стандартах разные варианты перевода, например, «обеспечение качества», «контроль качества». Однако существующие переводы не в полной мере отражают суть деятельности по SQA.
  • Может сложиться впечатление, что именно (и только) процесс SQA должен обеспечивать качество программных продуктов или контролировать качество, что неверно. Неверно также все задачи обеспечения качества возлагать на одноименную группу — SQA. Без вовлечения в контроль качества других процессов жизненного цикла достижение целей качества было бы невозможным.
  • Процесс SQA обеспечивает гарантии (от assurance — давать заверения, гарантировать), что программные продукты и процессы в жизненном цикле проекта соответствуют предъявляемым к ним требованиям. Эти гарантии основаны на том, что SQA планирует и осуществляет контроль и оказание помощи в той деятельности по проекту, которая непосредственно связана со «встраиванием» в программные продукты свойств, обеспечивающих качество. SQA устанавливает стандарты, отвечающие передовой практике программной инженерии (нормы, правила, требования — как к процессам, так и к их продуктам) и контролирует их соблюдение в ходе жизненного цикла. SQA гарантирует, что проблемы, неизбежно возникающие в любой комплексной деятельности (каковой является совместное выполнение процессов жизненного цикла), своевременно идентифицируются и устраняются, что запланированные процессы пригодны для применения и надлежащим образом выполняются в соответствии с планом и что результаты выполняемых в проекте измерений могут быть использованы для регулирования деятельности в процессах жизненного цикла. Цель SQA — установить, почему допускаются ошибки и как они могут быть устранены. Таким образом, объектом исследований SQA являются в основном процессы жизненного цикла программной системы, а не программные продукты (в том числе рабочие продукты), качество которых должно быть обеспечено.
  • Для контроля качества программных продуктов (включая все рабочие продукты) предназначены процессы верификации и валидации.
  • Процессы верификации и валидации определяют, действительно ли продукты определенного этапа процесса разработки и сопровождения ПС соответствуют виду и потребностям данного шага и отвечают требованиям, предъявляемым к ним в начале этапа, а также в начале процесса. Задача верификации и валидации — проверить и подтвердить, что конечный программный продукт будет отвечать своему назначению и удовлетворять пользователей. Эти процессы контролируют качество путем выявления ошибок в продуктах процессов ЖЦ, не исследуя коренных причин появления этих ошибок.
  • Цель верификации — исследуя трансформации одних (входных) рабочих продуктов в другие (выходные) рабочие продукты проверить, правильно ли разрабатывается программный продукт (например, правильный ли код программного модуля по отношению к спецификации проекта этого модуля).
  • Цель валидации — исследуя совокупность рабочих продуктов, полученных на определенном этапе процесса разработки, убедиться в том, что они разработаны правильно, то есть отвечают назначению и специфицированным исходным требованиям к программному продукту (например, совокупность программных модулей действительно представляет требуемый программный продукт, совокупность выполненных тестов действительно достаточна для проверки всех функций ПС и т. п.).
  • И процесс верификации, и процесс валидации должны выполняться, начиная с самых ранних стадий ЖЦ ПС и применительно ко всем рабочим продуктам разработки (включая, например, планы). Эти процессы тесно взаимосвязаны и обычно определяются одним термином «верификация и валидация», которому соответствует термин «Verification and Validation» (V&V), используемый в зарубежной литературе.
  • Нужно отметить, что контроль процессов SQA и V&V осуществляет руководство проекта или организации (для независимого SQA или независимой верификации и валидации), а сами процессы координируют свои действия по проверке рабочих продуктов и других процессов.
  • Существует множество методов, пригодных для применения как в целях SQA, так и в целях V&V. Один из видов их классификации — деление на статические и динамические, не связанные и связанные с выполнением программ на компьютере, соответственно.
  • Статические методы касаются исследования документации по проекту (процессам, рабочим продуктам и пр.) одним лицом или группой лиц (коллективно), возможно с применением инструментальных средств поддержки.
  • К методам коллективной работы относятся инспекции, ревизии, сквозной контроль и др. Они могут также определяться и выполняться как самостоятельные поддерживающие процессы жизненного цикла.
  • Методы индивидуальной работы предполагают проведение аналитических исследований (например, анализ потоков данных, причинно-следственный анализ, анализ деревьев событий и деревьев отказов, анализ сложности алгоритмов, формальное доказательство корректности и др.).
  • К динамическим методам обычно относят тестирование, имитационное моделирование и символическое выполнение.
  • Примечательно, что тестированию, с одной стороны, отводится место среди основных процессов жизненного цикла программной системы, а с другой — его принято считать ключевым методом V&V (Коротун Т.М. Верификация и валидация ППО автоматизированных систем организационного управления //Сб. материалов конференции. УкрПРОГ’98, 2-4 сентября 1998 г. -Киев. — 1998. — С. 362 — 367). На наш взгляд тестирование, как процесс, недостаточно четко определено в действующих стандартах, поскольку эффективное осуществление процесса тестирования требует выполнения определенных действий практически на всех стадиях жизненного цикла проекта и во многих процессах, например, в процессах определения требований, SQA и V&V...
  • Тестирование имеет много общего с процессами верификации и валидации (V&V), рассмотренными в главе 6 «Процессы и методики проверки». Общность процесса тестирования с процессами V&V заключается в единстве состава и структуры планов, рекомендуемых IEEE Std 829:1998 «Standard for Software Test Documentation» (52 страница), а также объектов и применяемых методов. Отличие этих процессов состоит в условиях их применения. Тестирование — основной процесс в жизненного цикла, выполняемый всегда, для всех объектов ПО системы независимо от ее критичности. Процессы V&V, в современной трактовке стандартов . IEEE Std. 1012:1998 «IEEE Standard for Software Verification and Validation» и ISO/IEC 12207:1995 «Information technologies. Software life cycle processes» (61 страница) — поддерживающие процессы, которые могут применяться к выбранным объектам тестирования для проверки планов их тестирования и подтверждения того, что выполненное тестирование адекватно уровню критичности ПС. По отношению к процессу тестирования V&V выполняет контрольную функцию и подтверждает соответствие объектов установленным требованиям.
  • Тестирование ПС тесно связано с отладкой и собственно программированием, но охватывает гораздо более широкий круг проблем и участников — программистов, тестировщиков, аналитиков и инженеров по качеству.

«Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах», Роман Савин, Москва, Дело, 2007. 32 страница:

  • QA (Quality Assurance — буквально «обеспечение качества», произносится «кью-эй») — это забота о качестве в виде превентирования появления багов, тестирование — это забота о качестве в виде обнаружения багов до того, как их найдут пользователи. Общее в QA и тестировании заключается в том, что они призваны улучшить ПО, различие между ними — в том, что: QA призвано улучшить ПО через улучшение процесса разработки ПО; тестирование — через обнаружение багов.

Эта заметка-конспект является ответом на одну из тем экзаменационного вопроса вузов и ISTQB. Полный перечень вопросов привел в заметке Учебные программы, экзаменационные вопросы и литература по обеспечению качества и тестированию программ.

Обоснование потребности в тестировании

В учебных программах по дисциплине «Обеспечение качества и тестирование программ» есть вопрос «Обоснование потребности в тестировании». В программе обучения базового уровня International Software Testing Qualifications Board «Сертифицированный тестировщик» тема детализируется пунктами: «Используя примеры, объяснить, почему возникновение дефекта может нанести ущерб человеку, оборудованию или компании», «Определить различие между первопричиной дефекта и его эффектом» и «Используя примеры, привести причины, почему тестирование необходимо». Прошелся по доступной литературе и составил конспект, который содержит примеры и может быть использован для ответа на указанные вопросы.

«Надежность программного обеспечения», Гленфорд Майерс, 1980. 20, 28-30 страницы:

В 1971 году во Франции проводился крупный метеорологический эксперимент. Было запущено 115 шаров-зондов с измерительными приборами в верхние слои атмосферы, а также спутник для пересылки данных между шарами и наземными станциями. Шары умели реагировать на две команды: команду чтения, по которой данные пересылались от шара к спутнику, и команду ликвидации для взрыва помещенного в шаре заряда, если шар собьётся с курса. К несчастью, в программном обеспечения системы была ошибка. В результате вместо команды чтения была послана команда ликвидации, уничтожившая семь 72 шара, находившихся в поле зрения спутника.

В профессиональных журналах по обработке данных часто публикуются весёлые (для всех, кроме их участников) истории о классических ошибках в программном обеспечении. Страховая компания без всяких видимых причин аннулировала полис и отказалась его восстановить. Программа регистрации подписчиков направила все экземпляры журнала по одному адресу. Банковская система учёта займов представила к оплате месячный счёт в 212 958 долларов 72 центра, в то время как баланс по займу составлял всего 2 342 доллара 55 центов. Железнодорожная система потеряла товарные вагоны. Вследствие ошибок в системах обработки результатов голосования голоса избирателей подавались не за тех кандидатов, просто терялись, а в одном случае даже были отданы все одному кандидату (только последняя ошибка была без труда обнаружена). Ошибка в системе управления базой данных большого склада привела к разрушению записей, благодаря чему, помимо прочего, затерялись следы 15 тонн замороженной печени, помещенной в отсек без холодильника. Школьная система учёта успеваемости воспринимала только двухзначные числа, так что учащиеся, набравшие более 100 баллов, оказались неуспевающими. Программист, только что закончивший перенос программы начисления зарплаты для своей фирмы с IBM 1401 на IBM 360, открывает конверт c очередной выплатой и обнаруживает, что его оклад сокращен до 0 долларов 00 центов.

К счастью, почти все эти ошибки не имели серьезных последствий. Однако есть и другой классический свод ошибок, закончившихся катастрофами или почти катастрофами. Ошибка в программном обеспечении бортовой ЭВМ космического корабля «Аполлон-8» уничтожила содержимое части памяти машины. За 10 дней полёта «Аполлон-14» было обнаружено 18 ошибок. Беспокойство по поводу ошибок в программном обеспечении программы «Аполлон» выражает следующее заявление: «Самое тщательно спланированное и щедро финансированное программное обеспечение в мире было разработано для серии полётов на Луну по программе „Апполон“. К работе в двух соперничающих группах были привлечены лучшие программисты страны. Проверка программного обеспечения велась со всей полнотой, которую только могли представить себе специалисты. В общей сложности около шести 660 млн. долларов было затрачено на это программное обеспечение. И всё-таки почти все крупные неудачи программы „Аполлон“, от ложных тревог до реальных неприятностей, были прямым результатом ошибок в программном обеспечении ЭВМ».

Серьезные ошибки в программном обеспечении не ограничивались только программой «Аполлон». Вследствие ошибки в программе информация с радаров была послана не по назначению, и таким образом были уничтожены все результаты учений ПВО США NORAD в 1963 году. Частота сбоев из-за ошибок в программном обеспечении командной системы 465 L стратегического командования ВВС США, функционирующей уже 12 лет, до сих пор равна одному в среднем одному сбою в день. Ошибка в единственном операторе программы на Фортране привела к неудаче при первом запуске американского исследовательского корабля на Венеру. Что хуже всего, ошибки медицинском программном обеспечении явились причиной нескольких смертельных случаев, а ошибка в программе проектирования самолёта вызвала несколько серьезных авиакатастроф, хотя имеющаяся информация об этих ошибках, как и следовало ожидать, весьма неполна.

«Наука отладки», Мэтт Тэллес, Юань Хсих. Пер. с англ. С. Лунин, науч. ред. С. Брудков. Кудиц-образ, 2003 г. — 560 с.:

Ошибка аппарата Therac-25 была, пожалуй, самой дорогой ошибкой в современной истории. Как известно, с июня 1985 по январь 1987 года шесть пациентов получили передозировку радиации, что привело к гибели троих из них... Therac­-25 представлял собой компьютеризированную машину для радиационной терапии, построенную, компанией Atomic Energy of Canada Limited (AECL). Предшественниками Therac­-25 были Therac­-6, который представлял собой ускоритель на 6 миллионов электрон­вольт (МэВ), способный испускать, только рентгеновские лучи, и Therac­-20, рентгеновский излучатель и ускоритель электронов на 20 МэВ... Therac­-25 поступил в продажу в конце 1982 года, и 11 таких машин были установлены в Северной, Америке, 5 ­ в США и 6 ­ в Канаде. Шесть несчастных случаев с большими передозировками произошли, между 1985 и 1987 годами...

Kennestone Regional Oncology Center, г. Кенстоун, округ Мариетта, штат Джорджия (Kennestone, Marietta, Georgia), июнь 1985. Женщина в возрасте 61 года была направлена в онкологический центр для дополнительного лечения аппаратом Therac­-25 после хирургического удаления молочной железы. Как считается, пациентка, получила одну или две дозы радиации от 15 000 до 20 000 рад (поглощенная доза радиации). Для, сравнения, типичная разовая терапевтическая доза радиации составляет до 200 рад. Кенстоунская клиника, использовала Therac­-25 с 1983 года без происшествий. Техники и фирма AECL не поверили, что эта, проблема может быть вызвана Therac­-25. В конечном итоге пациентка потеряла грудь, а также, возможность пользоваться руками и плечами из­-за радиационного поражения.

Ontario Cancer Foundation, Хемилтон, провинция Онтарио, Канада (Hamilton, Ontario, Canada). Клиника в Хэмилтоне использовала Therac­-25 в течение шести месяцев до инцидента с передозировкой. Сорокалетняя женщина поступила в клинику на 24­-в й сеанс лечения аппаратом Therac­-25. Аппарат, отключился через пять секунд после того, как оператор запустил его. Операторы были знакомы с частыми, неполадками машины. Эти неполадки, вероятно, не имели серьезных последствий для пациента., Поскольку машина показывала, что облучение не было произведено, оператор попытался повторить его. Были произведены пять попыток. После пятой попытки был вызван техник, не обнаруживший проблем в аппарате. Об инциденте сообщили в AECL, но воспроизвести неполадку и сделать заключение о причинах такого поведения Therac­-25 не удалось. Однако благодаря этому сообщению фирма AECL обнаружила некоторые слабости конструкции и потенциальные механические проблемы в позиционировании поворотной платформы Therac­-25 и были сделаны исправления. Пациентка умерла через пять месяцев. Результаты, вскрытия показали, что смерть наступила от рака, а не от передозировки радиации. Однако вскрытие, также выявило серьезные поражения бедра, вызванные радиационным воздействием. Как было позже, определено, пациентка получила дозу порядка 13 000 ­ 17 000 рад.

East Texas Cancer Center (Восточно­техасский онкологический центр), г. Тайлер, штат Техас (Tyler, Texas), и арт 1986. Восточно­техасский онкологический центр использовал аппарат Therac­-25 с 1984 года и применял его при, лечении более 500 пациентов. 21 марта 1986 года пациент (мужчина) был направлен на дополнительное, лечение. Оператор, которая осуществляла лечение, была знакома с Therac­-25 и хорошо разбиралась в его свойствах и в процессе использования. Когда она вводила данные пациента и врачебные предписания, она допустила ошибку, которую быстро исправила и начала лечение. Спустя мгновение машина отключилась и дисплей отобразил сообщения об ошибках. Как обычно происходит в программных системах сообщение об ошибке представляло собой код, который никто не смог бы расшифровать. «Ошибка 54», расшифровывалась в печатном перечне ошибок как «ввод дозы 2». Восточно­техасский онкологический центр не располагал другой документацией, которая объясняла бы смысл выражения «ввод дозы 2». Дисплей показал также очень малую дозу облучения и, поскольку оператор была знакома с капризами, Therac­25, она немедленно запустила повторное лечение. Машина снова отключилась с теми же, сообщениями об ошибках. Клиника связалась с AECL по поводу этой проблемы. Техники фирмы, направленные в Восточно­техасский онкологический центр, не смогли воспроизвести неисправность, и AECL все так же считала, что передозировка на Therac-25 невозможна. Пациент умер от осложнений передозировки через пять месяцев после этих событий.

East Texas Cancer Center (Восточнотехасский онкологический центр), г. Тайлер, штат Техас (Tyler, Texas), апрель 1986. Три недели спустя другой мужчина поступил для лечения с помощью Therac-25. Та же женщина-оператор, которая участвовала в прошлом инциденте, была ответственной за лечение. Как и в предыдущем случае, она сделала ошибку при вводе данных, и, почти столь же быстро исправив ошибку, она запустила лечение. Машина ответила сообщением «ошибка 54» и отключилась. Однако пациент уже получил передозировку, и оператор побежала за помощью. Therac-25 был отключен, и клиника проинформировала AECL о втором случае передозировки. Физик клиники, Фриц Хэгер (Fritz Hager), совместно с оператором научились воспроизводить сообщение «ошибка 54» произвольно. Оказалось, что передозировка возникала, если данные врачебного предписания редактировались в быстром темпе. Люди из AECL наконец смогли воспроизвести ошибку и признали, что передозировка была возможна.

Yakima Valley Memorial Hospital, г. Якима, штат Вашингтон (Yakima, Washington). Январь 1987... случился шестой инцидент. В данном случае пациент должен был получить три дозы облучения. Первые две дозы составляли 4 и 3 рад. Следующая доза составляла 79 рад в фотонном режиме. Первые два сеанса прошли без осложнений. После второй дозы оператор вошел в комнату облучения, чтобы повернуть поворотную платформу, чтобы проверить положение лучевого пучка относительно тела пациента. Оператор нажал кнопку возле поворотной платформы для указания того, что контроль произведен. Установив платформу, оператор запустил процесс лечения. Машина остановилась через 5-6 секунд, и поэтому оператор запустил лечение снова. И снова машина отключилась и отобразила «маловразумительную» причину остановки. Возникло предположение о передозировке, однако дисплей показал только облучение в 7 рад от двух первых сеансов.

Через неделю AECL обнаружила недостаток в программном обеспечении, который смог объяснить это поведение. Этот программный дефект отличался от того, который был обнаружен в Восточно-техасском онкологическом центре в деталях. Однако оба дефекта были вызваны неожиданными зависимостями от скорости в программных модулях. В данном случае существовала разделяемая переменная, названная Class3, содержащая однобайтовое значение. Это значение указывало, соответствуют ли параметры машины параметрам лечения. Если значение Class3 было ненулевым, параметры считались несоответствующими, и пучок лучей подавлялся. Эта переменная инициализировалась в модуле, который готовил машину к лечению. Однако инициализация заканчивалась инкрементированием данной переменной. Поскольку переменная была однобайтовой, через каждые 256 итераций значение ее доходило до нуля, программный модуль, проводивший инициализацию, запускался все время в зависимости от других событий в системе. Если кнопка на поворотной платформе была нажата именно в тот момент, когда переменная Class3 была равна нулю, проверка соответствия не производилась, и машина могла облучить пациента электронным пучком дозой до 25МеV. Пациент умер в апреле 1987 году от осложнений, вызванных передозировкой. Машина была отозвана вскоре после этого...

Ракета-носитель Ariane 5 была ответом попыткам Европейского космического агентства (European Space Agency) стать лидером в запусках ракет на коммерческом космическом рынке. Стоившая 7 миллиардов долларов и строившаяся в течение 10 лет, Arian 5 могла вывести на орбиту два трехтонных спутника. При своем первом полете ракета Ariane 5 взорвалась через 40 секунд после старта утром 4 июня 1996 года. Анализ данных полета быстро показал, что ракета вела себя нормально до того момента, когда она вдруг отклонилась от курса и самоуничтожилась... Команда Ariane 5 решила не защищать некоторые переменные от возможной ошибки операнда, поскольку они считали, что значения этих переменных либо ограничены физическими факторами, либо имеют существенный запас по максимальной величине. Команда Ariane 5 решила не включать данные о траектории в функциональные требования для Инерционной системы ориентировки. Следовательно, данные о траектории Ariane 5 не использовались при тестировании. Из-за физических законов трудно осуществить реалистичный полетный тест Инерционной системы ориентировки. При функциональном имитационном тестировании полетных программ было решено не включать в тест эту систему главным образом по той причине, что она должна быть проверена при тестировании аппаратного уровня, а также потому, что было бы трудно достигнуть необходимой точности при имитационном тестировании, если бы была использована реальная Инерционная система ориентировки...

Аппарат для исследования климата Марса Mars Climate Orbiter является частью программы Mars Surveyor по изучению и картографированию Марса. Ожидалось, что программа Mars Surveyor продлится в течение 10 лет и в рамках программы будет запускаться одна экспедиция в год. Первыми двумя экспедициями были миссии аппаратов Mars Pathfinder и Mars Global Surveyor в 1996 году. Аппарат Mars Climate Orbiter был запущен 11 декабря 1998 года. Следом за ним был также запущен Mars Polar Lander — 3 января 1999. Оба аппарата были потеряны вскоре после того, как они достигли красной планеты. Эти два космических корабля стоили NASA около 327,6 миллиона долларов, потраченных на их создание и функционирование. Эти аварии заставили NASA пересмотреть свои цели и методы в Марсианской программе, чтобы быть уверенными в успехе будущих миссий. Причину аварии Mars Polar Lander определить все еще нельзя. Однако причина потери Mars Climate Orbiter выяснена.

Согласно спецификации модуль... должен формировать данные... используя метрические единицы, то есть ньютон-секунды. Однако по тем или иным причинам модуль на наземной станции выводил данные, используя английские единицы (фунт-секунды) (в официальном отчете причина не указывалась, и мы не будем строить предположения по этому поводу). Программный модуль, который рассчитывал изменение скорости с использованием данных..., ожидал, что они будут в метрических единицах, согласно спецификации. На борту аппарата модуль... использовал метрические единицы. Это привело к различию между траекториями, вычисленными космическим аппаратом и наземной станцией, а именно параметры траектории, вычисленные наземной станцией, были в 4,45 раза меньше, поскольку 1 фунт-секунда равен 4,45 ньютон-секундам.

«Люди иногда делают ошибки», — заявил доктор Эдвард Уэйлер (Edward Weiler), первый заместитель главы NASA по науке о космосе. «Данная проблема — это не ошибка, это неудача системотехники и систем проверки в наших технологиях, предназначенных для обнаружения ошибки. Вот почему мы потеряли космический аппарат». Три главных составляющих аварии Mars Climate Orbiter: 1. Если бы было проведено соответствующее тестирование, такая ошибка могла быть быстро обнаружена и исправлена. 2. Однако, поскольку программное обеспечение наземной станции не было хорошо протестировано, после запуска космического аппарата проявились дополнительные ошибки. Эти ошибки отсрочили наблюдения над проблемой. Вместо девяти месяцев из-за дополнительных ошибок персонал имел только пять месяцев на выяснение причины несоответствий. 3. Когда несоответствие в итоге было обнаружено, оно так и не было правильно объяснено. Первоначальная причина так и не была выяснена, а это дало бы персоналу информацию о надвигающейся катастрофе.

В отчете комиссии по расследованию первой фазы ее работы также были указаны следующие факторы неудачи и сделаны некоторые дополнительные рекомендации... 1. Обмен информацией. Команда наземного обслуживания не сообщала о своем беспокойстве по поводу различия траекторий команде управления космическим аппаратом и органам управления проектом. Важная информация от одной команды не передавалась другим командам, что внесло свой вклад в аварию. 2. Обучение и переход от стадии разработки к стадии функционирования... Обслуживающий персонал не был полностью обучен. Переход от разработки к функционированию не был тщательно спланирован и осуществлен. В разработке программного обеспечения это можно приравнять к тому, как если бы команда разработчиков перебросила готовую систему команде сетевых операторов, не снабдив их соответствующими инструментами и не проведя обучение особенностям и поведению системы. 3. Самоуверенность. Комиссия по расследованию обнаружила, что персонал проекта считал посылку космического аппарата на орбиту вокруг Марса легкой задачей, поскольку JPL имела тридцатилетний опыт безошибочной межпланетной навигации. Эта самоуверенность может объяснить недостаток соответствующего тестирования в программных модулях...

В ходе всей разработки и процессов тестирования существовало много стадий, на которых данный дефект мог быть выявлен: 1). Программный модуль был повторно использован в новой среде, где условия функционирования отличались от требований программного модуля. Эти требования не были пересмотрены. 2). Система выявила и распознала ошибку. К несчастью, спецификация механизма обработки ошибок была несоответственной и вызвала окончательное разрушение. 3). Ошибочный модуль никогда должным образом не тестировался в новом окружении — ни на уровне оборудования, ни на уровне системной интеграции. Следовательно, ошибочность разработки и реализации не была обнаружена.

К 15 января 1990 года в компании AT&T произошла авария, охватившая всю страну и продолжавшаяся девять часов. Причина состояла в ошибке в программном обеспечении, которое должно было сделать эту систему более эффективной... В 1990 году телефонная сеть AT&T состояла из 114 соединенных между собой систем коммутирования вызовов... В середине декабря 1989 года AT&T произвела обновление программного обеспечения на коммутаторах 4ESS с целью увеличения производительности системы и введения быстрого процесса восстановления после ошибки. Приблизительно в 14:40 15 января 1990 года на 4ESS коммутаторе в Нью-Йорке возникла небольшая аппаратная проблема, и коммутатор начал процесс восстановления... Обновление программ, проведенное в середине декабря, внесло в действия ошибку. Эта ошибка проявилась, когда коммутатор получил два IAM сообщения с интервалом 1/100 секунды. Некоторые данные в коммутаторе оказались искажены, и он прекратил обслуживание, перейдя к инициализации. Когда соседние узлы выходили из строя, они запускали тот же самый процесс восстановления. Поскольку все коммутаторы были одинаковы, та же последовательность событий каскадом распространялась от одного коммутатора к другому и вывела из строя всю систему... В течение дня инженеры AT&T смогли стабилизировать сеть, уменьшив нагрузку на нее. К 23:30 EST они смогли очистить все звенья сети, и система практически вернулась к нормальному состоянию... Во вторник, 16 января 1990 года, инженеры AT&T смогли идентифицировать и выделить ошибку, которая была отслежена до набора ошибочных кодов... Один из операторов приводил к исполнению части кода, которая не входила в намерения программиста. В официальном отчете AT&T говорилось: «Мы считаем, что процессы планирования, разработки и тестирования программ, которые мы используем, базируются на прочных и качественных основах. Все будущие программы будут также скрупулезно тестироваться. Мы используем опыт, приобретенный при решении этой проблемы, для дальнейшего улучшения наших методов».

13 апреля 1998 года, на AT&T произошла другая крупная авария в сети ретрансляции кадров (frame relay network) Cisco Stratacom BPX, которая затронула банкоматы, операции с кредитными картами и другие службы, связанные с передачей бизнес-данных. Авария длилась 26 часов. И опять ошибка была внесена при обновлении программного обеспечения... Когда техник прибыл на место, он посчитал, что коммутатор, которому требуется обновление, не подключен к сети, поскольку казалось, что через него не проходил никакой сетевой трафик. Однако коммутатор был подключен к сети и активен. К несчастью для техника и для AT&T, обе карты имели дефекты. Как только карты были установлены и активированы, они немедленно выслали коммутатору поток сообщений об ошибках. Эти сообщения от транк-карт активировали ошибку в программном модуле коммутатора. Этот дефект вызвал распространение передачи сообщений об ошибках к другим коммутаторам сети, ко всем 145. Объем этих посланий был достаточно велик, для того чтобы быстро перегрузить все коммутаторы, что очень действенно вывело из строя всю систему приблизительно к 15:00... Компания AT&T смогла быстро изолировать аварийный коммутатор, к 23:00 он был отключен от сети. Оставшаяся задача состояла в том, чтобы просто перестроить всю сеть, одну часть за другой. К 2:00 пополудни 14 апреля 1998 года 99,9 % сети ретрансляции кадров были снова работоспособны... Программные дефекты в обоих случаях представляли собой проблемы со скрытыми граничными условиями, которые было трудно протестировать и которые, по всей вероятности, так и не были протестированы.

... Цена ошибки может быть астрономической. Миллионы долларов, затраченные на оборудование и работу, исчезают без следа. Человеческая боль и страдания, даже смерть могу быть вызваны простой ошибкой в программе.

Эта заметка является ответом на экзаменационный вопрос «Обоснование потребности в тестировании» по учебной дисциплине «Обеспечение качества и тестирование программ». Полный перечень вопросов привел в заметке Учебные программы, экзаменационные вопросы и литература по обеспечению качества и тестированию программ.

Перевод главы из книги «Наука отладки» | Книга «Надежность программного обеспечения»

Список распространенных программных ошибок

В приложении к книге «Тестирование программного обеспечения» Сэм Канер, Джек Фолк и Енг Кек Нгуен рассказывают о списке распространенных программных ошибок, как основе работы тестировщика:

Формировать список возможных ошибок по ходу работы — плохая практика. Гораздо удобнее и надежнее иметь раз и навсегда составленный готовый список, из которого можно будет отбирать то, что подходит для каждой конкретной программы... Тестируя новую программу, вы будете не только отбирать подходящие элементы приведенного списка, но и дополнять его новыми описаниями ошибок. Поэтому лучше всего хранить его в электронном виде, чтобы он всегда был под рукой и его без труда можно было редактировать.

Мэтт Тэллес и Юань Хсих в книге «Наука отладки» отмечают:

В индустрии программного обеспечения мы очень мало делаем того, что можно назвать, посмертным анализом ошибки. Мы не задаем таких вопросов, как, каким образом ошибка была, обнаружена, как она возникла и что мы можем сделать, чтобы предотвратить ее. Если мы все же, проводим посмертный анализ, мы так редко документируем наши открытия, что наше знание недоступно другим людям... Действительно ли посмертный анализ ошибки поможет нам создать лучший продукт? Мы считаем, что, ответ на этот вопрос ­ да! В 1981 году фирма NEC осуществила план, призванный помочь разработчикам, программ и менеджерам проектов учиться на ошибках. Был создан каталог ошибок, наблюдавшихся во, многих корпоративных проектах. Это поддержало разработчиков в поисках причин отказов программ и в, предотвращении их повторного появления. За 10 лет, прошедших с запуска проекта, разработчики, извлекли много уроков и стали способны применять этот опыт для повышения своей производительности, и понижения числа ошибок.

Следуя совету авторов, решил хранить список распространенных программных ошибок в электронном виде, дополнять список случаями из практики и использовать для тестирования программных продуктов. Первым шагом сформирую на основе готового списка список ошибок для конкретной программы. Включу в список все ошибки, что только могут встретиться в программе, независимо от того, насколько вероятно их появление. Вторым шагом разработаю тесты для выявления каждой включенной в список ошибки. Третьим шагом подстрахую план тестирования, проверив, охватывает ли план все классы ошибок из списка. Четвертым шагом выявлю трудновоспроизводимые ошибки, соотнося симптомы ошибки с ошибками из списка. Пятым шагом сосредоточусь на представителях класса ошибок к которому относится найденная ошибка.

В оригинальном списке Канера, Фолка и Нгуена содержится порядка 400 ошибок и каждая из них с той или иной степенью ясности относится к определенному классу, содержит описание и примеры. В представленном ниже списке не 400, а 21 ошибка с описанием классиков тестирования и добавленными мной примерами из практики. По мере обнаружения новых примеров ошибок буду обновлять список распространенных программных ошибок.

  1. Ошибки пользовательского интерфейса. Функциональность. Неадекватность реализации базовых функций. К одной из ключевых функций программы невозможно обратиться и если она реализована слишком узко или слишком медленно работает, такая программа не годится для реальной эксплуатации.
    • Случай 1: пользователем нажать кнопку выбора города нахождения, не появляется попап с вариантами для выбора. Случай 2: в мобильной версии сайта выбрать одну из меток к статье и в результатах поиска по меткам получить сообщение «Нет статей по выбранным меткам». Случай 3: ввести на главной странице сайта в форме подписки на рассылку почтовый адрес и нажать кнопку «Подписаться». Результатом получить графический индикатор выполнения действия без подтверждения о подписке. Случай 4: в форме подписке по почте ввести почтовый адрес, нажать кнопку «Подписаться», получить перезагрузку страницы и отображение адреса почты в URL. Случай 5: не загружаются графические анонсы статей на главной странице сайта. Случай 6: в браузере Mozilla Firefox на главной страница форума нажать кнопку Создать тему, не получить попапа создания темы и в консоли браузера увидеть ошибку «ReferenceError event is not defined forum.ensure.min.js».
  2. Ошибки пользовательского интерфейса. Функциональность. Пропущенная функция. Все, о чем пользователю необходимо знать, должно отображаться на экране. Желательно также, чтобы на экране отображалась информация, которую среднестатистический пользователь найдет полезной.
    • Случай 1: пройти в подрубрику сайта и не обнаружить счетчика числа тем, предусмотренный в макете страницы. Случай 2: прокрутить страницу до конца, у пагинатора присутствуют цифры и отсутствуют стрелок. Случай 3: пройти в подрубрику и не обнаружить кнопку «Создать тему», предусмотренный в макете страницы. Случай 4: пройти в раздел форума и обратить внимание на темы с ответами экспертов, не обнаружить графического и текстового вывода информации об ответе эксперта и кнопки «Читать ответ эксперта».
  3. Ошибки пользовательского интерфейса. Функциональность. Неверно работающая функция
    • Случай 1: удалить пару комментариев к теме форума, обратить внимание на показания счетчика в 0 комментариев, несмотря на присутствие в теме еще двух комментариев. Случай 2: пройти через поисковик Google в AMP-версию статьи и обратить внимание на кнопки поделиться в социальных сети. Кнопки ссылаются на название статьи и переносят в шапку статьи, вместо отправки данных в социальные сети.
  4. Ошибки пользовательского интерфейса. Функциональность. Программа не делает того, что ожидает от нее пользователь.
    • Случай 1: отправить комментарий к теме форума и не увидеть появление комментария на странице. Перезагрузить страницу и снова не увидеть комментарий. Еще раз перезагрузить страницу и обнаружить комментарий.
  5. Ошибки пользовательского интерфейса. Взаимодействие пользователя и программы. Ошибки отображения. Отображена неверная или неполная строка.
    • Случай 1: на главной странице раздела обрезаны аватарки и имена пользователей. Случай 2: в профиле «звезды» в полной версии сайта обрезана последнюю строку в заголовке к изображению. Случай 3: в профиле «звезды» в полной версии сайта в блоке «Читайте также» обрезана половина высоты текста в четвертой строке.
  6. Ошибки пользовательского интерфейса. Взаимодействие пользователя и программы. Организация экрана. Организация команд и способы их ввода. Нестандартное использование клавиатуры. Принятие недопустимого ввода.
    • Случай 1: в аналитику ChartBeat не попадают статьи со спецсимволами в названии.
  7. Ошибки пользовательского интерфейса. Взаимодействие пользователя и программы. Организация экрана. Организация команд и способы их ввода. Нестандартное использование клавиатуры. Невозможность использования клавиш управления курсором, функциональных клавиш и клавиш редактирования.
    • Случай 1: пройти в редактирование статьи и воспользоваться комбинацией клавиш Ctrl+S, получить не сохранение страницы, а окно с текстом ошибки «Error. No form element found».
  8. Ошибки пользовательского интерфейса. Взаимодействие пользователя и программы. Организация экрана. Организация команд и способы их ввода. Нестандартное использование клавиатуры. Неэстетическое оформление экрана. Это субъективная, но все же достаточно четко распознаваемая характеристика. Пользуйтесь собственным чувством гармонии, а в случае неуверенности обращайтесь к мнению других. Распространенными эстетическими недоработками являются: неудачное сочетание цветов, не­равномерное расположение элементов, их непропорциональные размеры, невыровненные строки и столбцы данных.
    • Случай 1: в браузере Safari в новой версии «подвала» одни составляющие элементы расположены в центре, а другие составляющие элементы прижаты к левой стороне. Случай 2: на iPhone с iOS 10 в Yandex.Browser вставить в статью код с изображением Instagram, в результате чего iframe выходит за сетку страницы, а значки наезжают на текст.
  9. Ошибки пользовательского интерфейса. Взаимодействие пользователя и программы. Организация экрана. Организация команд и способы их ввода. Потери времени. Выбор, который не может быть сделан.
    • Случай 1: пройти в профиль пользователя и в подразделе «Последние действия» воспользоваться имеющейся кнопкй «Показать еще...», которая работает даже при отсутствие данных внутри. Случай 2: в голосовании с большим числом ответов попытаться воспользоваться той же кнопкой «Показать ещё», которая исчезает и не показывает дополнительного материала, которого просто нет.
  10. Ошибки пользовательского интерфейса. Взаимодействие пользователя и программы. Организация экрана. Организация команд и способы их ввода. Предотвращение неприятностей. Отсутствие возможности периодического сохранения данных. Если пользователь вводит большое количество данных, программа дол­жна уметь сохранять их через определенные интервалы времени. Это гаран­тирует, что при любом сбое большая часть введенной информации будет сохранена. Данная функция может включаться и отключаться по желанию пользователя.
    • Случай 1: пройти в форму создания новой статьи и заполнить 18 полей, нажать кнопку «Сохранить» и получить сообщение «Проблема При Сохранении XML».
  11. Ошибки пользовательского интерфейса. Взаимодействие пользователя и программы. Пропущенная информация. Отсутствие инструкций на экране. Невозможно определить, выполнена ли данная программе команда.
    • Случай 1: нажать кнопку «Зарегистрироваться» и не дождаться результата. Затем обратить внимание в панели разработчика на вкладку Network, с просмотром Preview одного из запросов, где есть сообщение о незаполненной капче, которая не отобразилась на странице регистрации. Случай 2: пройти из почты по ссылке с кодом активации учетной записи на сайте, не увидеть подтверждения об успешной активации. Пройти по ссылке второй раз и только тогда увидеть информацию об ошибке операции, поскольку активация была выполнена ранее.
  12. Ошибки пользовательского интерфейса. Взаимодействие пользователя и программы. Неверная или смущающая пользователя информация. Неточные названия команд и функций.
    • Случай 1: оставить на сайте комментарий, воспользоваться кнопкой «Редактировать», изменить текст комментария, не найти кнопку «Сохранить» и воспользоваться имеющейся кнопкой «Ответить».
  13. Ошибки пользовательского интерфейса. Справочная система и сообщения об ошибках. Отказ в предоставлении ресурсов без объяснения причины. Если программе не удается использовать принтер, модем, дополнительную память или другие ресурсы, она должна не только сообщить пользователю о неудаче, но и объяснить ее причины. Сообщения «Принтер уже используется» и «Принтер не подключен» требуют от пользователя разных действий.
    • Случай 1: пройти в форму создания новой статьи и заполнить 18 полей, нажать кнопку «Сохранить» и получить сообщение «Проблема При Сохранении XML».
  14. Ошибки пользовательского интерфейса. Справочная система и сообщения об ошибках. Фактическая ошибка. Нередко в документации и сообщениях программы приводятся неверные примеры того, как правильно выполнить то или иное действие. Одни из них устарели, другие неверны с «рождения». На одном из последних циклов тестирования все они должны быть тщательно проверены.
    • Случай 1: вызвать всплывающее окно входа в учетную запись на сайте, заполнить поле E-mail и получить сообщение «Введите корректный логин-пароль» при фактическом отсутствии формы с названием «Логин». Случай 2: вызвать всплывающее окно создания новой теме форума, приложить картинку, получить уведомление «Необходимо авторизоваться для добавления изображения к комментарию» при фактическом добавлении изображения к теме форума.
  15. Ошибки пользовательского интерфейса. Производительность. Время ответа.
    • Случай 1: на тестовой среде в одном из разделов воспользоваться кнопкой «Показать еще» и ждать 07 секунд до загрузки дополнительной информации.
  16. Ошибки пользовательского интерфейса. Кто здесь главный. Навязывание ненужных ограничений.
    • Случай 1: в панели администратора веб-сайта в разделе со списком пользователей поисковой запрос выполняется только после выбора пользователем одного из предложенных вариантов запроса. Использование кнопки «Поиск» или клавиши Enter при водит к обновлению страницы и появлению в строке поискового запроса значения «0».
  17. Ошибки пользовательского интерфейса. Кто здесь главный. Запрос информации без необходимости.
    • Случай 1: в панели администратора веб-сайта в разделе редактирования статьи не вносить изменения в материал и попытаться закрыть окно браузера, вызвав предупреждение о несохраненном материале.
  18. Ошибки обработки или интерпретации данных. Порча данных, хранящихся на внешнем устройстве. Объем данных слишком велик для процесса-получателя.
    • Случай 1: попытаться сохранить материал и не получить результат, а в Apache_error запись «PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 5619 bytes) in ... db_class.php».
  19. Обработка ошибок. Неадекватная проверка пользовательского ввода. Недостаточно просто сказать человеку, что он не должен вводить чисел, состоящих больше чем из трех цифр. Программа должна проверить, действительно ли введенные данные соответствуют этому условию. Если пользователь может что-то ввести, программа должна адекватно на это среагировать.
    • Случай 1: в всплывающем окне авторизации пользователя в поле e-mail ввести любое значение, в том числе и без символа at (@).
  20. Повышенные нагрузки. Системе не возвращена неиспользуемая память.
    • Случай: в диспетчере задач браузера Google Chrome 57 обратить внимание на работу расширения и обнаружить потребление 1.7 гигабайта оперативной памяти.
  21. Ошибки тестирования. Не замечена проблема. Тестировщик не знает, каким должен быть правильный вариант.
    • Случай 1: при описании ожидаемого результата по объекту «ссылка» не учитывал, какого типа ссылка передо мной и не фиксировал атрибуты ссылки, например, target или class.
Ctrl + ↓ Ранее