Принцип что где когда тестирование
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Принципы тестирования программного обеспечения. Личный перевод из книги «Искусство тестирования» Г. Майерса
Продолжая отдавать должное вопросам психологии в процессе тестирования, мы можем определить набор витальных (читай, чертовски жизненных) принципов тестирования. Многие из них покажутся очевидными, что, однако, не мешает зачастую ими пренебрегать. Вот они, а дальше – подробное их рассмотрение:
1. Обязательная часть тестирования – определение ожидаемого результата;
2. Программистам следует избегать тестирования их собственных программ (и участков кода);
3. Организациям, создающие программы, следует избегать тестирования их собственных программ;
4. Процесс тестирования должен включать в себя тщательную проверку результатов каждого теста;
5. Тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых;
6. Исследование Системы на предмет того, что она не делает того, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает;
7. Избегайте одноразовых тест-кейсов, только если сама программа не является одноразовой. Одноразовые тест-кейсы для одноразовых программ. В остальных случаях следует избегать таковых;
8. Не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок;
9. Вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок;
10. Тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие.
Принцип 1: обязательная часть тестирования – определение ожидаемого результата
Этот принцип, который типа очевидный, когда его упускают из вида, является причиной наиболее частых ошибок в процессе тестирования. Тут снова вмешивается психология. Если заранее не разобраться с тем, как должен выглядеть результат, то нечто похожее на правду, но таковым не являющееся, будет воспринято как корректный результат. Ведь «мы видим то, что хотим видеть». Другими словами, несмотря на разрушительную природу тестирования, где-то в глубине души мы все еще храним желание увидеть корректный результат. Но с этим нужно решительно бороться. Например, путем поощрения подробного заблаговременного исследования всех выходных данных и ожидаемых результатов. А это значит, что тест-кейс должен содержать два компонента:
— описание входных данных
— точное описание корректных выходных данных для указанных входных данных.
Проблемы могут возникнуть тогда, когда мы встречаем нечто, что не имеет приемлемого описания, что выглядит странным, что не согласуется с нашими ожиданиями или предубеждениями. При встрече с чем-то подобным нам нужно иметь хотя бы какие-то обобщенные представления, поскольку если не будет даже их, легко вообще пропустить потенциальные проблемы. Нет ожидания – нет сюрпризов.
Принцип 2: программистам следует избегать тестирования их собственных программ (и участков кода)
Каждый писатель знает – или должен знать – что редактировать свою собственную работу – это плохая идея. Они знают, что именно должна сказать, к примеру, определенная глава книги, и поэтому могут не увидеть то, что она говорит нечто другое. И они как-то не хотят искать ошибки в своей работе. То же можно сказать и об авторах программных продуктов.
Еще одна проблема связана со сменой фокуса. В то время, как при дизайне и написании кода программист настроен созидательно, перенастроиться на разрушительную волну может быть очень сложно.
Каждый домовладелец знает, что снимать обои очень трудно. Но если эти обои еще и ты сам вешал — это невыносимо удручает. Аналогично и с ПО, большинство программистов не могут протестировать свои программы эффективно, поскольку они не могут произвести ментальные перестройки, способствующие выявлению ошибок. Более того, подсознательный страх перед наказанием со стороны коллег, руководителей, клиентов или владельцев может приводить к избеганию ошибок.
И еще одна проблема: программа может содержать ошибки, которые вызваны непониманием поставленных задач или спецификации. И если это так, то сам процесс тестирования может включать в себя производные этого непонимания.
Это не значит, что путь тестирования собственных программ для программиста закрыт. Просто лучше (эффективнее), чтобы это делал кто-то другой. Разработчики могут быть полезными участниками команды тестирования, когда проводится оценка спецификации и самого программного кода.
И еще. Речь не шла о процессе дебаггинга. В этом случае автор кода является наиболее эффективным участником процесса.
Принцип 3: организациям, создающим программы, следует избегать тестирования их собственных программ
Аргументы такие же, что и для предыдущего принципа. Организация, создающая ПО, во многих смыслах как человек: имеет психологические проблемы. Более того, в нашем лучшем из миров работа организации или ее менеджеров часто оценивается способностью производить программы в установленные сроки и за определенную стоимость. Причиной этому то, что эти величины легко описать количественно, в противоположность надежности, которую оценить в цифрах может быть сложно. Отсюда — организациям-разработчикам сложно быть эффективными в тестировании собственных продуктов. Эта оценка может проводится на основе соблюдения графиков работ и расходов.
Следует сказать и тут, что участие организации в процессе тестирования собственных продуктов не обязательно является бессмысленным. Здесь мы говорим, что наиболее удачно с экономической точки зрения выполнять такую работу независимой стороной.
Принцип 4: процесс тестирования должен включать в себя тщательную проверку результатов каждого теста
Это очевидно, но это часто упускается. Мы знакомы с большим количеством случаев, когда ошибку не удавалось обнаружить даже тогда, когда ее симптомы были четко различимы в выходных списках (результатах). Если выразится по-другому, ошибки, которые находят в последующих тестах, часто не замечают в результатах предшествующих тестов.
Принцип 5: тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых
Это естественная и здравая тенденция – концентрироваться на допустимых и ожидаемых условия в процессе тестирования. Пренебрегать недопустимыми и неожиданными условиями также естественно, но не также здраво. Много ошибок может выявится, когда программный продукт используется неким новым или неожиданным путем. Невозможно определить все сценарии, какими пользователь будет работать с продуктом, однако что-то отличное от спокойного, привычного течения программы, кажется, имеет все шансы на успех (в деле поиска ошибок).
Принцип 6: исследование Системы на предмет того, что она не делает, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает
Это следствие предыдущего принципа. Программу нужно проверить еще и на предмет нежеланных сторонних эффектов. Например, ПО для расчета заработанной платы, которая выдает зарплатный чек корректно, все еще содержит ошибки, если она также выдает дополнительные чеки для несуществующих работников, или она переписывает первую запись в персональном деле.
Принцип 7: одноразовые тест-кейсы для одноразовых программ, в остальных случаях следует избегать таковых тестов
Эта проблема, кажется, часто проявляется в различных системах для тестирования программ. Типичная практика – сидеть у компьютера и разрабатывать тесты на лету, и далее проводить эти тест-кейсы в программе. Суть в том, что тест-кейсы представляют собой ценные инвестиции, которые в рамках конкретного окружения могут исчезнуть, как только процесс тестирования будет завершен. И всякий раз, когда возникнет необходимость в повторном тестировании ПО (в регрессионном тестировании или при улучшении системы), тест-кейсы могут потребовать новой разработки. Это дополнительная, сложная работа, встречаясь с которой тест-инженер может волить избегать ее. Так получается, что последующие усилия на работу редко столь же объемны и качественны сколь объемны и качественны первоначальные. И если, к примеру, изменение функциональности влечет за собой ошибки, вновь разработанные тесты могут их не обнаружить.
Принцип 8: не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок
Частая ошибка менеджеров проекта и маленький звоночек к тому, что кто-то определяет процесс тестирования некорректно. Например, как процесс демонстрации, что программа работает правильно. Мы принимаем другое определение (хотя догадываемся, что есть ребята, которые так не делают) – это процесс выполнения программы со стойким намерением найти ошибки. Мы утверждаем: это очевидно, что разработать программный продукт, совершенно не содержащий ошибок, невозможно. Даже после качественно выполненного процесса тестирования и исправления ошибок, уместно предполагать, что ошибки все еще существуют; просто их пока не нашли.
Принцип 9: вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок
Может показаться, что эта штука сомнительна, но такой феномен наблюдается во многих программах. На пальцах это вот как: предположим, что программа состоит из модулей А и Б. В модуле А было найдено 5 ошибок, а в модуле Б – всего лишь одна. И если модуль А еще не подвергся тщательному тестированию, тогда принцип говорит: вероятность найти еще больше ошибок в модуле А выше, нежели вероятность найти еще больше ошибок в модуле Б.
Другой способ проиллюстрировать указанный принцип такой: ошибки имеют волю к объединению в группы, и в типичном случае, определенные программные блоки больше подвержены ошибочности, нежели другие. Хотя это похоже на магию… ничем не подкрепленную магию. Она может быть полезна, поскольку дает некое понимание и обратную связь в процессе тестирования. Если какой-то участок программы кажется больше подверженным ошибкам, нежели другие участки, этот феномен намекает нам, что лучше бы нам потестировать здесь чуточку дольше. И это вопрос об инвестициях.
Проверьте себя: а на какое количество вопросов ЧГК сможете ответить вы?
Проверьте себя: а на какое количество вопросов ЧГК сможете ответить вы?
Для затравки: в 1979 году, еще до выхода своей компании на биржу, Стив Джобс провел тесты, не имеющие отношения непосредственно к продукции компании. А какие именно тесты?
Хотите больше — добро пожаловать под кат!
29 августа в офисе ManyChat прошел интеллектуальный ИТ-вечер «Что? Где? Когда?». В игре приняли участие команды из Badoo, Deutsche Bank, HeadHunter, ManyChat, Raiffeisen bank, Tutu.ru, Тинькофф и целых три команды от Яндекса, включая Яндекс.Такси и Яндекс.Еду. Главная игра проходила в 2 тура по 12 вопросов. Ведущий зачитывал вопрос, и команде давалась минута на поиск правильной версии, затем ведущий озвучивал правильный ответ. После первых 12 вопросов (1 тура) мы объявили небольшой перерыв, во время которого прошла командная «Своя игра».
Результаты игры
Страсти во время игры разгорелись нешуточные, причем последние 6 вопросов оказалась решающими — именно они определили победителя. В итоге 3 место заняла сборная команда Яндекса, которая ответила на 17 вопросов из 24.
Команда Raiffeisenbank смогла взять на один вопрос больше и заработала 18 баллов. Это и помогло команде взять второе место в нашем ИТ-соревновании.
Абсолютным победителем стала команда из Deutsche Bank, которая нашла правильные ответы на 20 вопросов. Причем во втором туре ребят было не остановить, они взяли 11 вопросов из 12 возможных.
Как проходила игра любой желающий мог посмотреть online. Помимо стандартного веб-вещания (которое нам помогали делать ребята из Типичного Программиста), была организована трансляция с режимом обзора 360 градусов.
Готовы себя проверить? Вопросы перед вами!
1. [Черный ящик]
В одном интервью Сергей Шипов упомянул экстремалов, которые в рамках борьбы с читерством предложили экипировать шахматистов тем, что лежит в черном ящике.
Вопрос: Что в черном ящике?
2. В 1979 году, еще до выхода своей компании на биржу, Стив Джобс провел тесты, не имеющие отношения непосредственно к продукции компании.
Вопрос: А какие именно тесты?
3. Борислав Козловский отмечает, что организаторы в 2011 году сделали рискованный ход, пригласив ЕГО. Сейчас ОН работает в сфере здравоохранения.
Вопрос: Назовите его.
4. Некоторые из вас смогут получить ЕГО, скажем, в апреле 2020 года. До недавнего времени считалось, что первым случайно нашел ЕГО двенадцатилетний мальчик из Солт-Лейк-Сити во время игры в «Adventure» около 40 лет назад.
Вопрос: Назовите его.
5. В названии вирусов-червей, способных заразить все доступные в сети машины за четверть часа, фигурирует фамилия художника.
Вопрос: Назовите этого художника
6. Изначально ОН должен был защищать от своеобразного ожога, которому подвергались области со статичными элементами. Сейчас же ОН выполняет, в основном, декоративные функции.
Вопрос: Назовите ЕГО.
7. Инженеру Михаилу Рыжку длинные тычинки каллистемона напомнили ЕГО. В слове «ОНО» все гласные одинаковы.
Вопрос: Назовите ЕГО.
8. В 2012 году программист из Google Тим Брей предложил ввести новый HTTP-статус — код для страниц в Интернете, доступ к которым запрещен госслужбами.
Вопрос: Напишите номер этого HTTP-статуса.
9. Сначала Альфред Филдинг и Марк Шаван предлагали использовать свое изобретение в качестве экзотических обоев, затем — для покрытия теплиц, но успех пришел, когда в IBM убедились, что оно лучше, чем газеты. Созданная ими фирма называется «Запечатанный. ». Что?
10. По мнению одного из авторов, пишущих в журнале «Хакер», эта история, имевшая место на Ближнем Востоке, — несомненный пример того, как хакеры, внедряя в практику несовместимые протоколы передачи информации, делали невозможным функционирование огромной корпоративной структуры.
Вопрос: Назовите ее основную, так и не завершенную, задачу.
11. Действие одного юмористического ролика происходит в Шотландии. Герой ролика собирается жениться. Его родители приходят в ужас, узнав, что невеста в родстве с Бьюкененами, Иннесам и Мактавишами.
Вопрос: Напишите фамилию героя.
12. На логотипе учебного языка программирования Kenya можно увидеть слово «Kenya» и несколько ИХ. Программа, написанная на этом языке, автоматически транслируется в Java-код.
Вопрос: Назовите ИХ.
Второй тур
Комментарий: по словам учёного, вопрос, что появилось раньше – ДНК или белок, — сродни знаменитому вопросу про яйцо и курицу.
Источник: Е. Кунин. Логика случая.
14. Согласно одной не очень правдоподобной версии, Майкл допоздна работал над дизайном макета. А ночью случилось небольшое землетрясение, слегка повлиявшее на вторую. Майклу понравилось, и он решил всё так и оставить.
Вопрос: Напишите короткую фамилию Майкла.
15. Из-за НЕГО зайцу-беляку стала дольше угрожать опасность, а на Аляске возникли транспортные проблемы.
Вопрос: Назовите ЕГО двумя словами.
16. Палеонтологам трудно работать в Южной Африке, так как там нет ИХ, способных «законсервировать» останки первобытных людей.
Вопрос: Как называется тот из НИХ, чью деятельность можно увидеть на картине в Государственном Русском музее?
17. В своей книге известный ученый сравнил ЕЁ с водопадом, на краю которого можно некоторое время удерживаться, если грести в обратную сторону изо всех сил.
Вопрос: Назовите ЕЁ.
18. Диеновый синтез, с помощью которого ученые получили многие важные лекарственные препараты, образно называют «ИМ органической химии».
Вопрос: Кто фигурирует вместе с НИМ в названии известного произведения?
19. Колумнистка газеты «Чикаго Трибьюн» Джулия Келлер вспоминает о мире до Гарри Поттера, когда слово «Поттер» в детской литературе однозначно опознавалось как фамилия английской писательницы Беатрис Поттер, а инициалы J.K относились не к Джоан Кэтлин Роулинг, а к ней самой. В статье также упоминается одна американская компания. Какая?
20. Герои одного комикса, попавшие в постапокалиптический мир, радуются, когда решают, что хотя бы сверчки всё-таки выжили. Это, однако, оказывается ошибкой, виной которой стал ОН.
Вопрос: Назовите его.
21. Новых менеджеров компании ОгИлви на рабочем месте ожидает предмет, в котором, в конце концов, они могут обнаружить записку: «Нанимая людей, равных себе или менее способных, мы превращаемся в компанию карликов. Нанимая людей сильнее, умнее и способнее себя, мы превращаемся в компанию гигантов».
Вопрос: Назовите этот предмет.
22. Персонаж Эрнеста Клайна видит женщину, одетую по моде 80-ых годов ХХ века. Описывая её причёску, персонаж в шутку предполагает, что ОН сильно пострадал.
Вопрос: Как называют места, в которых ОН пострадал особенно сильно?
23. В начале одного голливудского фильма главная героиня на машине съезжает с дороги, падает в воду и теряет сознание. Через пару минут в машину попадает молния. В этот момент закадровый голос упоминает ТО, что было впервые успешно применено в 1956 году.
Вопрос: Назовите ЭТО.
24. Несмотря на научно-технический прогресс, ЕЮ пользуются до сих пор. Сейчас чаще всего к её помощи прибегают океанологи и картографы.
Вопрос: Какая книга начинается с примера её успешного использования?
Про будущие мероприятия
Регистрацию на первую игру нам пришлось закрыть уже спустя 24 часа после анонса. Мы поняли, что к «Что? Где? Когда?» есть большой интерес у ИТ-сообщества. А самое главное, нам самим очень понравилось проводить это мероприятие. Поэтому мы решили сделать целый осенний ИТ-сезон: два отборочных тура и Рождественский финал.
Отборочные игры мы планируем провести 3 октября и 8 ноября, а финальная битва состоится в декабре. Совсем скоро мы объявим регистрацию, а всеми подробностями обязательно поделимся в нашем блоге и социальных сетях (Vk, Facebook). Так что начинайте собирать команду и готовьтесь посоревноваться в логике и сообразительности!
Принципы тестирования — применение, искажения и иллюзии
Эта статья была начата ещё в апреле текущего (2020) года. И с тех пор я её несколько раз переписывал. Я никак не мог достичь того результата, который бы меня устроил. Я не хотел писать очередную статью про 7 принципов тестирования, куда бы просто скопипастились переводы этих принципов из ISTQB, а потом (как в лучших из статей) сопровождались разъяснениями на тему «Что это всё означает». Получилось бы очередное переписывание «священного писания» с его толкованием. Однако, поистине священное писание в толковании не нуждается.
Моя статья будет не про то, что же это за 7 столпов тестирования. Я специально опущу некоторые детали при объяснении принципов. Легким движением руки по клавиатуре вы сможете нагуглить всё это сами. Мы поговорим сразу о боли.
Принципы тестирования — это своеобразная конституция, манифест и договорённости нашей профессии. Но, как и в реальной жизни, как бы чётко ни был написан документ, какими бы благими намерениями не руководствовались авторы, конституцию можно трактовать по-разному, на манифест можно забить, о договорённостях можно забыть.
Вот об этом я бы хотел поговорить в этой статье. О том, как же мы живём с семью принципами тестирования на самом деле.
Это статья-рассуждение. Тут не будет слишком много полезностей, будьте к этому готовы. Скорее призыв к диалогу и попытка поделиться своим опытом и кое-где даже болью. Так что комментарии приветствуются.
Немного о себе, прежде чем начать (эту часть можно пропустить)
Меня зовут Кирилл, я в ИТ с 2009 года, тестированием занимаюсь уже почти 10 лет. Сейчас я работаю на руководящей должности в QA, а так же помогаю в обучении начинающих тестировщиков и параллельно этому всему веду свой телеграм-канал для джуниоров QA (ссылочка будет в конце статьи)
Я не всегда руководствовался в жизни 7ю принципами тестирования. Более того, я не всегда даже знал о них (как и многие тестировщики, я думаю). Но, чем больше сила, тем больше и ответственность, как говаривал дядя Бен. И со временем до меня начал доходить смысл каждого принципа, а после я начал замечать как эти принципы трактуются, искажаются и видоизменяются под тяжестью корпоративных культур каждой отдельной компании.
Собственно семь принципов тестирования
Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие.
Но, коллеги, не забывайте, что иногда бизнес спрашивает «почему этот баг попал на продакшн?». На этот вопрос вы обязаны ответить вполне конкретно. У каждого конкретного бага есть причины появления/пропуска. Но давая ответ на вопрос, так же давайте понять бизнесу, что отсутствие найденных дефектов в процессе тестирования не гарантирует отсутствия ошибок в системе.
Сколь бы скрупулёзным тестирование не было, нельзя учесть все возможные сценарии, а значит и предвидеть все возможные ошибки.
Запомнили принцип выше? Отсутствие багов не гарантирует отсутствие ошибок, кажется, что второй принцип очевидно вытекает из первого, верно?
В мире ограниченных ресурсов и возможностей нужно уметь оценивать риски и расставлять приоритеты. Тестируя, мы снижаем риски. Делая правильный тест-дизайн, мы ещё сильнее снижаем риски. Так и живём.
Это избитая истина, примерно такого же плана, как и «ПО надо тестировать, т.к. писать код без ошибок физически невозможно». Но многим руководителям кажется, что на самом деле тестирование отнимает время релизного цикла, т.к. задерживает доставку фич, а так же тратит время тестировщиков, на то, чтобы они читали «бумажки» вместо того, чтоб тестировать.
Я всю свою жизнь сталкиваюсь с этим удивительным противоречием; парадоксом, если угодно. Менеджеры говорят, что качество ПО превыше всего, недовольные клиенты — недопустимо, если надо тестировать, то мы выделим на это время. Но на деле почти всегда оказывается, что рук не хватает, бюджета нет и «давайте вы сейчас проверите, чтобы катнуть побыстрее, а потом уже будете свои тест-кейсы писать».
Дефекты не размазаны равномерно по приложению, а сконцентрированы в больших количествах в некоторых модулях системы
Для начала хотелось бы заметить, что об этом принципе вообще не вспоминают. Наоборот, найдя пару ошибок в каком-то блоке функционала некоторые тестировщики успокаиваются, мол «ну мы там баги нашли, отлично, пойдем дальше».
Просто помните, если вы уже нашли несколько багов в каком-то модуле, стоит перелопатить его ещё тщательнее, скорее всего там есть ещё скрытые дефекты.
В то же время, отсутствие дефектов в других модулях не говорит, что дефектов там нет (помните первый принцип?)
Это самый распиаренный принцип тестирования. Суть его в том, что если вы долго проводите одни и те же проверки, скорее всего новых багов вы не найдете. Именно поэтому периодически нужно «встряхивать» вашу тестовую базу, ревьюить её новыми сотрудниками и проводить исследовательское тестирование.
Некоторые коллеги во имя избегания этого эффекта «забивают» на классические подходы к тестированию и всё время проводят только исследовательское тестирование. Часто объясняют это тем, что «раз регрессионные прогоны одних и тех же тестов не помогают выявлять новые дефекты, проще полностью отказаться от этого подхода и каждый раз тестировать как на новенького». К сожалению в этом суждении забывается тот факт, что парадокс пестицида говорит лишь о том, что имеющиеся наборы больше не находят новые баги, а не о том, что формальные повторяющиеся из раза в раз проверки вообще не способны находить ошибки.
Об этом я уже как-то упоминал в одной из предыдущих статей. Набор методологий и инструментов, а также подходов и ресурсов для тестирования зависит от того, что именно вы тестируете и на сколько объект тестирования важен
Иногда забывают о том, что каждой задаче своё решение и подход. Очень распространённая тактика, везде использовать старую методологию, если она себя показала хорошо. Однако этот принцип как раз напоминает нам о противоположном.
Зачастую, говоря о контексте, тестировщики рассуждают о внешнем контексте: доменных областях и пользователях (которые не меняются длительное время в рамках одного продукта). Но они забывают внутренний контекст: новые разработчики, больше разработчиков, другие владельцы компании, нагрузка на сотрудников, внутриполитические силы в компании. Этот внутренний контекст и позволяет нам поднимать вопрос о смене методологии и процессов, которые раньше были неуместны.
Тот факт, что тестирование не обнаружило дефектов, ещё не значит, что программа хорошая.
Ну вот снова! Хочется сорвать с себя шапку-ушанку и крикнуть: «Ай, да катись оно всё пропадом», раз никаких гарантий нет, то нафига вообще тестировать!? Ответ прост: чтобы снизить риски. Протестированный продукт с вероятностью 95% bug free, но не протестированный продукт с вероятностью 95% уйдет в продакшн с багами.
Не могу сказать, что я всю свою сознательную QA жизнь только и вижу, как принципы тестирования нарушаются. Нет, ни в коем случае. Я просто подобрал для каждого принципа распространенные случаи игнорирования или иной трактовки. В том или ином виде, объёме, сознательно или нет, но часть принципов соблюдается почти всеми командами, в которых присутствует процесс тестирования ПО. Мне лишь хотелось подсветить некоторые моменты/признаки, по которым чуть легче пустить факт нарушения принципов в своё сознание.
И напоследок вопрос без ответа, который я задаю сам себе (а теперь задам и вам): можно ли поступиться принципами тестирования во имя каких-то благих целей, или принципы тестирования, как семь смертных грехов (ох, вот это аллюзия. только сейчас это понял), являются нерушимой догмой, нарушение которой есть зло?
На просторах интернета я наткнулся ещё на парочку неофициальных доп.принципов, которые мне кажутся более понятными, приземленными и интуитивно полезными: