Тестирование дот ком ответы на вопросы

Обновлено: 07.07.2024

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

Если да, то в какую ветку форума лучше перенести и кому по этому поводу лучше обратиться?

Планирую оформить теоретические вопросы в формате pdf , дополнив некоторые из-них (в частности п.24), и выложить сюда.

Также думаю добавить новые ответы на вопросы отсюда . Автор вопросов: Александр Селяев.

Теоретические вопросы на собеседовании по тестированию:

1. Что такое тестирование?

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

[IEEE Guide to Software Engineering Body of Knowledge, SWEBOK, 2004]

· Повышение уверенности в уровне качества

· Предоставление информации для принятия решений

[Сертифицированный тестировщик. Программа обучения Базового уровня. Версия 2011]

Обеспечение качества ( quality assurance) - часть менеджмента качества, направленная на создание уверенности, что требования к качеству будут выполнены.

Управление качеством ( quality control) - часть менеджмента качества, направленная на выполнение требований к качеству.

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

[ГОСТ ISO 9000-2011; Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2).

Менеджмент качества (quality management) - скоординированная деятельность по руководству и управлению организацией, применительно к качеству.

Примечание - Руководство и управление применительно к качеству обычно включает в себя разработку политики в области качества и целей в области качества, планирование качества, управление качеством, обеспечения качества и улучшение качества. ]

4. Основные виды тестирования.

· Тестирование структуры/архитектуры программного обеспечения (Структурное тестирование)

· Тестирование изменений: подтверждающее и регрессионное тестирование.

[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

Классификация видов Тестирования: по знанию внутренностей системы, по объекту тестирования, по субъекту тестирования, по времени проведения тестирования, по критерию "позитивности" сценариев, по степени изолированности тестируемых компонентов, по степени автоматизированности тестирования и по степени подготовки к тестированию.

[Тестирование Дот Ком, Савин]

Важное Дополнение: По каким атрибутам характеристик качества мы тестируем? (благодарю SALar за формулировку данного дополнения )

[В соответствии с ГОСТ Р ИСО/МЭК 9126-93 у ПО есть 6 характеристик качества: Функциональные возможности (Functionality), Надёжность (Reliability), Практичность (Usability), Эффективность (Efficiencies), Сопровождаемость (Maintainability) и Мобильность (Portability). У каждой характеристики есть атрибуты.]

5. Load and performance testing различия.

Нагрузочное тестирование ( load testing) - вид тестирования производительности, проводимый с целью оценить поведение компонента или системы под увеличивающейся нагрузкой (число одновременно работающих пользователей и/или число транзакций) для определения максимального уровня нагрузки компонента или системы.)

Тестирование производительности ( performance testing): Процесс тестирования с целью определить производительность программного продукта.

[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

Load vs Performance Testing
Нам показалось, что Load и Performance Testing преследуют все же одну и ту же цель: проверка производительности (времени отклика) на разных нагрузках. Собственно поэтому мы и не стали разделять их. В то же время кто то может разделить. Главное все таки понимать цели того или иного вида тестирования и постараться их достигнуть.

(Автор: Андрей Широбоков . Ответ взят отсюда .)

Интересная статья о цели нагрузочного тестирования: Читать . Благодарю, SALar за ссылку.

6. Не функциональные виды тестирования.

· Нефункциональное тестирование - включает, но не ограничивается, нагрузочное тестирование, тестирование производительности, стресс-тестирование, тестирование удобства использования, тестирование восстановления, тестирование надежности и тестирование переносимости. Это тестирование того, “ как ” система работает.

· Тестирование структуры/архитектуры программного обеспечения (Структурное тестирование)

· Тестирование изменений: подтверждающее и регрессионное тестирование.

[Примечание: Регрессионное тестирование может выполняться на всех уровнях тестирования и включает функциональное, нефункциональное и структурное тестирование. ]

[Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)]

7. Тестирование инсталляции.

Тестирование установки ( installation testing) - Проверяет работоспособность методов установки программы на всех поддерживаемых платформах.

[Искусство тестирования программ, Гленфорд Майерс, 3 издание]

8. Тестирование документации основные принципы.

Проверка точности пользовательской документации ( documentation testing) - Проверяет точность всей пользовательской документации.

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

[Искусство тестирования программ, Гленфорд Майерс, 3 издание]

Читая и анализируя документацию, следует прежде всего уделить внимание её точности, полноте, ясности, простоте использования и тому, насколько она соответствует духу программного продукта.

[Тестирование программного обеспечения, Канер, Фолк, Нгуен, 2 издание]

9. Основные принципы Usability testing.

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

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

[ Искусство тестирования программ, Гленфорд Майерс, 3 издание ]

10. Артефакты тестирования.

Основными понятиями RUP являются артефакт (artifact) и прецедент (precedent). Артефакты — это некоторые продукты проекта, порождаемые или используемые в нем при работе над окончательным продуктом. Прецеденты — это последовательности действий, выполняемых системой для получения наблюдаемого результата.

(Автор: Сергей Трофимов . Ответ взят отсюда .)

2 вариант ответа на вопрос:

В соответствие с процессами или методологиями разработки ПО, во время проведения тестирования создается и используется определенное количество тестовых артефактов (документы, модели и т.д.). Наиболее распространенными тестовыми артефактами являются:

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

Набор тест кейсов и тестов (Test Case & Test suite) - это последовательность действий, по которой можно проверить соответствует ли тестируемая функция установленным требованиям.

Дефекты / Баг Репорты (Bug Reports / Defects) - это документы, описывающие ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.

Интересный факт: На Сайт «Про Тестинг» ссылается и "Учебно-методический комплекс по дисциплине «Тестирование программного обеспечения»" для студентов специальности «ПРИКЛАДНАЯ ИНФОРМАТИКА (В УПРАВЛЕНИИ)» - ИНСТИТУТ УПРАВЛЕНИЯ, БИЗНЕСА И ПРАВА.

11. Тест план и check-list.

Чек-лист - это документ, описывающий что должно быть протестировано. При этом чек-лист может быть абсолютно разного уровня детализации. На сколько детальным будет чек-лист зависит от требований к отчётности, уровня знания продукта сотрудниками и сложности продукта.

Чек-лист нужен для

· Не забыть требуемые тесты

· Для деления задач по уровню квалификации

· Для сохранения отчётности и результатов тестирования

Что должно быть в Чек-Листе:

· Список проверок (с требуемой степенью детализации)

сборка, на которой проводилось тестирование

тестовое окружение (если применимо)

12. Tracebility matrix, а нарисуйте

Матрица соответствия требований - это двумерная таблица, содержащая соответствие функциональных требований (functional requirements) продукта и подготовленных тестовых сценариев (test cases). В заголовках колонок таблицы расположены требования, а в заголовках строк - тестовые сценарии. На пересечении - отметка, означающая, что требование текущей колонки покрыто тестовым сценарием текущей строки. Матрица соответствия требований используется QA-инженерами для валидации покрытия продукта тестами. МСТ является неотъемлемой частью тест-плана.

Тестовый сценарий (test case) - Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения, разработанный для определенной цели или тестового условия, таких как выполнения определенного пути программы или же для проверки соответствия определенному требованию. [IEEE 610 - Стандартный глоссарий терминов, используемых в тестировании программного обеспечения (Версия 2.2)] Основные поля тестового сценария: Набор входных значений, предусловий выполнения, ожидаемых результатов и постусловий выполнения.

Блок-схема, показывающая основные статусы и возможные переходы от статуса к статусу в процессе его существования:

Описание данной схемы.
Допустим вы нашли баг и зарегистрировали его в баг трекинг системе. Согласно нашей блок-схеме он получит статус “Новый”. Тестировщик, ответственный за валидацию новых баг репортов, или координатор проекта (в зависимости от распределения ролей в вашей команде) может перевести его в один из следующих статусов:
· “Отклонен”, если данный баг невалидный или повторный, или же его просто не смогли воспроизвести
· “Отсрочен”, если данный баг не нужно исправлять в данной итерации
· “Открыт”, если исправление бага необходимо
Рассмотрим теперь по порядку каждый из вариантов.

1. Отклонен. В этом случае вы можете либо поспорить о судьбе вашего багрепорта, изменив статус на “Переоткрыт” либо закрыть его - статус “Закрыт”

2. Отсрочен. Баг репорт в статусе “Отсрочен” можно перевести в статус “Открыт”, когда потребуется исправление либо в статус “Закрыт”, если уже не потребуется.

* * *
Хотим отметить, что данная схема сильно упрощена. Для большей наглядности и, возможно, удобства работы на проекте, вы можете добавить дополнительные статусы и переходы, тем более, что современные баг трекинговые системы позволяют это делать. Правда имейте ввиду, что излишне запутанные схемы переходов и лишние статусы могут значительно усложнить жизнь.
Примечание 1: в некоторых системах баг трекинга созданный баг репорт сразу получает статус “Открыт” без дополнительной валидации
Примечание 2: многие баг трекинговые системы позволяют переоткрывать закрытые баги, однако лично я против такой практики, поэтому и не описывал подобный переход в выше представленном жизненном цикле
Примечание 3: Рассмотренный выше жизненный цикл основан на том, что в команде есть кто-то, ответственный за назначение баг репортов. В случае, если такой роли на проекте нет, то баги назначаются разработчиками самостоятельно, и тогда во избежании путанницы, есть смысл ввести еще один промежуточный статус “В разработке” (In progress), показывающий, что данный баг репорт уже назначен и находится на стадии исправления.
[ Сайт «Про Тестинг» ]

Три условия жизни и процветания бага

Конкретный баг живет и процветает лишь при одновременном выполнении всех трех условий:

Известен фактический результат;
Известен ожидаемый результат;
Известно, что результат из пункта 1 не равен результату из пункта 2.

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

Примеры багов из жизни:

Бутерброд падает маслом вниз.
Подхалимы и говоруны имеют намного больше шансов на повышение, чем скромные честные труженики.
Несоответствие миловидной внешности и змеиной сущности.
Попугай воспроизводит на людях худшее из словарного запаса хозяина.
Автомобили российского производства.
Кот Бегемот в фильме В. Бортко «Мастер и Маргарита».

Определение бага

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

В соответствии с законом исключенного третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого.

Определение бага

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

Вопрос по книге Романа Савина «Тестирование dot com»?

У меня есть вопрос по содержимому:
На странице 204 рассматривается пример использования метода пограничных значений на основе таблицы 1 на странице 180.

"Пример
Возьмем индекс, который должен быть равен 6 цифрам (Индекс_эл_005 из табл. 1, матричной раскладки поля "Индекс").

Применяем метод тестирования пограничных значений:
а. 6
б. 6
в. 6
г. 5
Д. 7

Таким образом, у нас есть:
• один позитивный тест 6 и
• два негативных теста 5 и 7."

Почему из а,б,в осталось только а?
Я так понимаю, что метод пограничных значений не учитывает различные негативные кейсы? Например, ввод буквы.
Тогда вопрос в том, зачем автор применял метод пограничных значений в данной ситуации, если он этим методом покрыл только половину того, что нужно проверить? После матричной раскладки и комбинирования элементов (табл. 2) вполне удобно составлять тест-кейсы.

Если вопрос уж сильной дилетантский, то прошу отнестись с пониманием, т.к. только начал вливаться.

Потому, что значения а, б, в -- эквивалентны и чтоб не создавать тесты на каждое эквивалентное значение, используются классы эквивалентности.
Вывод: Почитайте про классы эквивалентности.

Метод пограничных значений тестирует именно границы. Если эталонное значение 6, то тестируется сама граница (6) и минимальные граничащие с ней значения (если речь о целочисленных то 5 и 7).
Вывод: Если речь о проверке граничных значений в числовом поле, в котором может быть 6 цифр -- проверяются ближайшие значения и сама граница. Негативные тесты с буквами, в данном примере -- не проводятся.

Источники ожидаемого результата

Основными источниками ожидаемого результата являются:

Спецификация.
Спецификация.
Спецификация.
Спецификация.
Жизненный опыт, здравый смысл, общение, устоявшиеся стандарты, статистические данные, авторитетное мнение и др.

Спецификация на первой— четвертой ролях — это не ошибка, а ударение на то, что спецификация для тестировщика — это:

мать родная, а также
друг,
товарищ и
брат.

Спецификация важна для программиста и тестировщика так же, как постановление пленума ЦК для коммуниста.

Спецификация — это инструмент, с помощью которого вы сможете выпустить качественный продукт и прикрыть свою спину (в оригинале звучит как CYA или cover your ass).

Итак, что же это за зверь?

Спецификация (или spec — читается «спек». Далее употребляется в мужском роде) — это детальное описание того, как должно работать ПО. Вот так, ни много ни мало.

В большинстве случаев баг — это отклонение от спецификации (я говорю о компаниях, в которых спеки в принципе существуют и ими пользуются).

Пример

В общем все просто:

Если ошибка не показана и регистрация подтверждается, то это есть момент истины и нужно рапортовать баг (file a bug).

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

Что такое Баг?

Логический закон исключенного третьего гласит, что любая вещь — это либо А, либо не-А. Третьего не дано, т.е. если у вас есть часы «Брегет» за номером 5, то любая вещь в этом мире будет либо вашими часами «Брегет» за номером 5, либо чем-то другим.

Представим себе конвейер, в конце которого стоим мы. Лента конвейера движется, и перед нами по очереди появляется по одному предмету. Задача проста — ожидать появления ваших часов «Брегет» за номером 5 и говорить «баг» при появлении любого предмета, отличного от них.

Нетрудно догадаться, что такие предметы, как пакет кефира, будильник «Слава», буклет с предвыборными обещаниями кандидата в президенты Н. будут для нас багами.

Далее. Рассмотрим, что объединяет следующие ситуации.

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

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

Разбор ситуаций.

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

Что такое тестирование

Любое тестирование — это поиск багов. Испытываем ли мы новую соковыжималку, наблюдаем ли за поведением подруги или занимаемся самокопанием — мы ищем баги. Баги находятся следующим образом:

Мы узнаем (или уже знаем) ожидаемый результат;
Мы узнаем (или уже знаем) фактический результат;
Мы сравниваем пункт 1 и пункт 2.

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

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

Теперь вспомним о том, что есть компьютерное ПО и что нам нужно научиться его тестировать.

С фактическим результатом здесь более или менее понятно: нужно заставить систему проявить себя и посмотреть, что произойдет.

Сложнее дело обстоит с ожидаемым результатом.

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

Допустим, что ошибка не была показана и мы имеем классический случай функционального бага (functional bug, или баг обыкновенный), т.е. бага, вскормленного на несоответствии фактической работы кода и функционального спека.

и в любом случае формально будет прав, так как спецификация не детализирует текста ошибки.

Кстати, несколько лет назад был случай, когда программисты в специальном ПО, разработанном для американских тюрем, оставили «рабочее» название кнопки, причем тюремщикам идея так понравилась, что они просили ничего не исправлять. Надпись на кнопке была: «Освободить подонка».

В общем сложилась ситуация, когда сама спецификация имеет проблему, так как мы ожидаем (или по крайней мере должны ожидать), что в спеке будут подробности о тексте ошибки, а в реальности их там нет. Так и запишем — «баг в спецификации» (spec bug).

Кстати, вот варианты развития ситуации с проблемным спеком:

Кстати, вот две релевантные политически важные вещи:

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

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

ЖИЗНЕННЫЙ ОПЫТ

Как справедливо отметил Борис Слуцкий: «Не только пиво-раки мы ели и лакали». Мы также учились и работали, любили и ненавидели, верили политикам и не слушались родителей, в общем приобретали жизненный опыт (включая опыт работы). Так вот этот опыт настолько полезен в нашем черном деле, что для демонстрации уважения к идее о его полезности (вместе с логикой и здравым смыслом) я вынес ее в качестве эпиграфа во Введении. Дело в том, что тестирование ПО — это то самое тестирование (которое мы делаем постоянно), но только в отношении ПО. И моя задача заключается лишь в том, чтобы дать вам основные концепции и практический инструментарий по интернет-тестированию и помочь их интеграции с тем, что у вас уже есть, — с жизненным опытом.

ЗДРАВЫЙ СМЫСЛ (дитя жизненного опыта и соответственно внук «ошибок трудных»)

Это один из наших главных союзников, порой даже и при наличии спека. Например, вы тестируете веб-сайт, где пользователь может загрузить (upload) свои цифровые фотографии. Спек говорит, что пользователь может загрузить лишь одну фотографию за раз. А что, если у него таких фотографий 200? Будет он счастлив? Что делаем? Правильно: пишем е-мейл к producers@testshop.rs с предложением о включении в спек функциональности, позволяющей пользователю загружать цифровые фотографии оптом. Кстати, баг такого рационализаторского плана лицемерно называется не багом, а Feature Request («запрос об улучшении» — пока остановимся на таком переводе).

ОБЩЕНИЕ

Даже самый лучший спек может вызвать необходимость в уточнениях. А что, если спека нет вообще? Наш ответ: общение. Советуйтесь с коллегами. Уточняйте и обсуждайте. Одна голова хорошо, а две лучше.

УСТОЯВШИЕСЯ СТАНДАРТЫ

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

СТАТИСТИЧЕСКИЕ ДАННЫЕ

Было установлено, что средний пользователь теряет терпение, если web page (веб-страница) не загружается в течение 5 секунд. Эти данные можно использовать, проводя performance testing (тестирование скорости работы всей системы либо ее компонента). Как говорят американцы: «Your user is just one click away from your competitor» («Ваш пользователь находится на расстоянии в один клик от вашего конкурента»). Успех вашего проекта — это счастливые пользователи. Превышение 5 секунд — это превращение веб-сайта в зал ожиданий, в котором вряд ли кто захочет находиться.

АВТОРИТЕТНОЕ МНЕНИЕ

Это может быть, например, мнение вашего начальника.

Отметим, что баг (bug) буквально переводится как «жук» или «букашка».

Теперь, как я и обещал, немного истории.

Согласно фольклору, баги вошли в лексикон компьютерщиков после случая, происшедшего в Гарвардском университете в 1947 г. После того как на реле прадедушки ПК Маркa II присел отдохнуть мотылек, один из контактов слегка коротнуло и весь 15тонный агрегат со скрежетом остановился. Инженеры проявили милосердие и извлекли мотылька, после чего аккуратно зафиксировали его скотчем в журнале испытаний с комментарием «Первый фактический случай найденного жука» («First actual case of bug being found»).

Источники ожидаемого результата

Основными источниками ожидаемого результата являются:

Спецификация.
Спецификация.
Спецификация.
Спецификация.
Жизненный опыт, здравый смысл, общение, устоявшиеся стандарты, статистические данные, авторитетное мнение и др.

мать родная, а также
друг,
товарищ и
брат.

Спецификация важна для программиста и тестировщика так же, как постановление пленума ЦК для коммуниста.

Итак, что же это за зверь?

Пример

В общем все просто:

Что такое Баг?

Далее. Рассмотрим, что объединяет следующие ситуации.

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

Разбор ситуаций.

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

Что такое тестирование

Мы узнаем (или уже знаем) ожидаемый результат;
Мы узнаем (или уже знаем) фактический результат;
Мы сравниваем пункт 1 и пункт 2.

Теперь вспомним о том, что есть компьютерное ПО и что нам нужно научиться его тестировать.

Сложнее дело обстоит с ожидаемым результатом.

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

и в любом случае формально будет прав, так как спецификация не детализирует текста ошибки.

Кстати, вот варианты развития ситуации с проблемным спеком:

Кстати, вот две релевантные политически важные вещи:

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

ЖИЗНЕННЫЙ ОПЫТ

ЗДРАВЫЙ СМЫСЛ (дитя жизненного опыта и соответственно внук «ошибок трудных»)

ОБЩЕНИЕ

УСТОЯВШИЕСЯ СТАНДАРТЫ

СТАТИСТИЧЕСКИЕ ДАННЫЕ

АВТОРИТЕТНОЕ МНЕНИЕ

Это может быть, например, мнение вашего начальника.

Отметим, что баг (bug) буквально переводится как «жук» или «букашка».

Теперь, как я и обещал, немного истории.

Три условия жизни и процветания бага

Конкретный баг живет и процветает лишь при одновременном выполнении всех трех условий:

Известен фактический результат;
Известен ожидаемый результат;
Известно, что результат из пункта 1 не равен результату из пункта 2.

Примеры багов из жизни:

Бутерброд падает маслом вниз.
Подхалимы и говоруны имеют намного больше шансов на повышение, чем скромные честные труженики.
Несоответствие миловидной внешности и змеиной сущности.
Попугай воспроизводит на людях худшее из словарного запаса хозяина.
Автомобили российского производства.
Кот Бегемот в фильме В. Бортко «Мастер и Маргарита».

Читайте также: