Home

Автор: Майкл Фритциус (Michael Fritzius)

Оригинал статьи: https://testzius.wordpress.com/2016/12/13/testing-without-requirements/

Перевод: Ольга Алифанова

Этот вопрос звучит частенько: что же делать, вот приходишь ты на работу, или на проект, и должен тестировать, а ТРЕБОВАНИЙ НЕТ!

Для некоторых из нас крайне трудно представить себя в подобной ситуации.

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

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

На то есть множество причин – и очень хороших причин, хотя плохие среди них тоже присутствуют.

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

Сейчас я объясню, что это вполне посильная задача – и вы не просто справитесь с ней, но справитесь блестяще, и улучшите свой навык тестировщика.

Я тестировщик… и могу тестировать без требований… думаю…

Черноящичное тестирование

Когда мы берем часть продукта и не знаем толком, что у него происходит внутри – "внутри ящика", так сказать – мы используем черноящичное тестирование.

Если термин вам незнаком, он может вас немного пугать. Не беспокойтесь. Все хорошо. Это немного похоже на взлом замков.

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

С черноящичным тестированием то же самое.

Возможно, вам уже доводилось тестировать и находить баги. Мы будем использовать эти инструменты и опыт для будущего тестирования.

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

Вот формочка:

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

Привет, короче говоря, мы просили стажера набросать простенькую форму для ввода данных клиентов. Форма была нам нужна для клиентского терминала. Для стажера это был неплохой опыт.

Клиенту понравилось, поэтому мы доделали этот продукт. Но вот эта часть, эта формочка, не смотрит на клиента – мы просто использовали ее как зацепку, чтобы грузить записи о пользователях в систему.

А теперь стажер уволилась, а у нас никогда не доходили руки написать требования на такую простую форму. Но протестировать-то ее надо! Успехов!

Отлично. Требований нет. Просто прекрасно.

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

Мы знаем, что эта форма, скорее всего, хранит данные где-то в базе данных, и мы можем написать множество тестов, чтобы проверить, корректно ли данные сохраняются в базе.

А вот что можно проверить еще:

• Все ли поля на форме обязательные? Что, если оставить одно из них пустым в разных тестах, каждый ли раз результатом будет ошибка?
• Если форма хранит данные в базе данных, могут ли данные обрезаться? Если ввести имя в 20 символов, а база данных хранит только 18, есть ли в этом проблема?
• Выдает ли форма сообщения об ошибках, если информации слишком мало или чересчур много?
• Какого формата даты ожидает поле? Выдает ли оно соответствующую ошибку, если введен неверный формат?
• Выбор даты рядом с этим полем заполняет поле, как ожидается? Вашим локальным (США/не США) форматом? Как система воспринимает это?
• Что, если выбрать дату в будущем?
• Для чего нужен активный чекбокс? Переносится ли это состояние в базу данных, устанавливается ли там какой-то флажок? Или выбор этого чекбокса ни на что не влияет?
• Что, если вы попробуете внести запись с уже существующим в базе именем – она перезатрет старую запись или создаст новую? И какая из них двоих будет использоваться в системе?
• Что должно находиться в выпадающем списке Инвестиции? Он заполняется откуда-либо? Содержание соответствует источнику информации?
• Как насчет поля "почта", проводит ли оно проверки на то, что введет валидный почтовый адрес? Что, если вы попытаетесь разделить два адреса точкой с запятой? Возможно ли это?
• Для всех текстовых полей – можно ли пробиться через них при помощи XSS или SQL-инъекций? Если да, это очень, очень плохо и нужно немедленно исправлять.
• Как воспринимаются спецсимволы? Не каждое имя содержит только буквы.
• Когда вы нажимаете на ОК, запись фактически появляется в базе данных, как ожидается?
• Если нажать на "Отмену", поля очищаются? Если вернуться к форме снова после отмены, не осталось ли там артефактов от предыдущей попытки заполнения?
• Можете ли вы поменять модель и сделать так, чтобы данные появлялись там, где не должны?

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

Небольшая часть тестирования посвящена убеждению, что ПО делает то, что должно. Оставшаяся, довольно крупная часть – убеждению, что оно НЕ делает того, что НЕ должно.

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

Обсудить в форуме