Скучные и унылые определения забывают через час после прочтения, через неделю после зазубривания. А яркий и запоминающийся образ остается в голове! На собеседовании часто волнуются и забывают напрочь все, что учили. Отвечать на вопросы помогает яркий образ 🙂
Поэтому в статье «Теория Тестирования ПО в картинках» на простых примерах объясним сложные термины.
Тестирование производительности, нагрузочное и стресс
Студенты при изучении классификации часто спрашивают, чем отличаются между собой:
- Тестирование производительности
- Нагрузочное тестирование
- Стресс-тестирование
1. Производительность: как быстро машина разгонится до сотни
2. Нагрузка: как быстро она разгонится до сотни с 4 пассажирами и багажом
3. Стресс: при каком весе на осях у нее подломятся балки
Типы границ
В моей классификации есть всего три типа границ (мнемоника ЛТП):
- Логическая — ограничение, накладываемое логикой, не программой.
- Технологическая — ограничение, накладываемое используемой технологией
- Произвольная — ограничение, накладываемое аналитиком или разработчиком.
Типы границ на примере стиральной машинки
У вас есть стиральная машинка.
1. Логическая: нельзя засунуть меньше 0 киллограммов белья. Это логика.
2. Произвольная: нельзя засовывать больше 1 кг махровых полотенец — так производитель написал в инструкции. Завтра напишет 1,5 кг — вот граница и поменялась.
3. Технологическая: нельзя засунуть больше, чем влезет в бак машинки. И вот это уже никак не изменить, без смены технологии, в данном случае самой машинки.
Обратите внимание, что в данном случае границы измеряются в разных величинах, полный бак белья может по-разному весить.
В IT тоже часто такое может быть. Например, произвольная граница у нас указана в символах, а технологическая будет в байтах, а разные символы содержат разное количество байт, поэтому может оказаться, что в символах точную длину не указать.
Тест-кейс VS чек-лист
Чем же они различаются?
Вроде все понятно:
тест-кейсы — подробно;
чек-листы — кратенько.
Но иногда студентам все равно тяжело понять. Зачем в тест-кейсе писать, что именно за файл создается, как его загружать в систему (на какие кнопки нажимать, какие действия выполнять)?
Идея 1
Пояснение:
Тест-кейсы тупые до невозможности, словно ребенка на работу привели и показываем, «Вот мамочка сейчас файл обработает. Нажимаем кнопочку А, потом кнопочку Б, потом…», а не просто «Ну вот загрузили и все получилось».
Ну а чек-листы — это когда не нужны все эти подробности, как именно мы загружаем файлы, на какие кнопочки нажимаем. Нужна просто напоминалка — «Проверить загрузку Excel, CSV, JPG…»
Идея 2
Вы делали ремонт? Покупали шкафы, собирали их? А я делала и отсюда у меня вторая ассоциация.
Мы купили комод в ИКЕА. Он небольшой и простой в сборке. Но инструкция выглядит как талмуд — все настолько подробно. Каждое действие, каждый шаг. Каждый винтик — все в новом пункте на пол-листа А4, максильно доступно. Такой комод соберет даже полный профан. Потому что ребята не считают нужным пропускать этапы как «Ну это же очевидно, куда ввинчивать этот шуруп». Очень напоминает «Ну это же очевидно, на какую кнопочку нажимать, чтобы загрузить файл»
А вот диванчик в коридор мы купили в другом месте. Он тоже небольшой и не сильно сложный в сборке — кубик шкафчика собрать и прицепить к самому диванчику. Но инструкция — полный швах. На ней ровно одна картинка — уже собранный диванчик, все детали чуть на расстоянии друг от друга. Ну это же очевидно, как его собрать!
Мы, кстати, не осилили, оставили мастеру
Но разница «Простая инструкция — инструкция из ИКЕА» === «Чек-листы — Тест-кейсы». Когда будете писать тест-кейс, помните об этом и о том, что очевидное вам — темный лес для кого-то другого…
Ошибка, дефект и сбой
Чем же они отличаются? Почитайте веселую историю и вспомнить отличие будет легко без подсматривания в гугл!
Жил-был мастер. Он шил платья на заказ. Однажды он допустил ошибку— забыл прошить нижний край у кармана платья.
Результатом ошибки стал дефект. Платье висело на вешалке и выглядело абсолютно нормально, но оно было с дефектом.
Маленькая девочка увидела платье и сразу влюбилась. Она купила платье и носила его повсюду. И все было хорошо, платье сидело замечательно, дефект никак не проявлялся. Пока новая хозяйка не решила положить в карман ключ.
Девочка опустила руку в карман, отпустила ключ… У-у-у-упс, ключ выпал на пол! Произошел сбой в системе — проявился ранее скрытый дефект.
Точно также бывает и в ПО → разработчики допускают ошибки при написании кода и в программе затаивается дефект. И даже если дефект не нашли и о нем никто не знает, он все равно есть! Сидит и ждет своего часа. И когда пользователь натыкается на ошибочный код, происходит сбой.
