Поделиться:
- Послать ссылку другу по электронной почте (Открывается в новом окне)
- Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)
- Нажмите, чтобы поделиться в Mastodon (Открывается в новом окне)
- Нажмите, чтобы поделиться в Telegram (Открывается в новом окне)
- Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)
- Нажмите, чтобы открыть на Facebook (Открывается в новом окне)
Я напишу тест кейсы не имея понятия как оно работает.
А почему это вообще глупо?
Делать вывод о том, как что-то ДОЛЖНО работать только на основе наблюдения за тем, как оно работает — ошибочно.
Сегодня тыцали по Google Calendar на предмет изучения сущностей и их свойств. Время там можно указывать в режиме 16:00, или 15:60 — что эквивалентно, бо календарь переводит «15:60» в «16:00».
Сделали так — 14:00-14:60, и календарь создал евент, время которого ожидалось 14:00-15:00. А календарь создал евент с временем 14:00-14:50.
Я знаю о том, что у меня в настройках профиля есть опция «Длительность евента по умолчанию 50 минут вместо 60-ти». Но об этом в интерфейсе ничего не указывает, об этом надо знать отдельно.
А выглядит всё как баг, который надо зарепортить.
Иногда студенты видят ошибку и так и пишут: «Ввести корректные данные. Ожидаемый результат — система падает со страшной ошибкой». Нуачо, оно жеж так и работает ))
Бывает вариант, когда исследовательское тестирование системы, не имеющей документации, документируется и превращается в тест-кейсы.
Но смотрится в данном случае не «как оно работает», а «что там есть» и это
«что» валидируется исходя из своей экспертизы и опроса пользователей/стейкхолдеров по неоднозначным моментам.
Бывает и такое. Но это не тестирование.
Делать вывод о том как оно должно работать без того чтобы смотреть как оно заработает может быть не менее, даже более глупо.
— Может выясниться что оно работает не так
— Может выясниться что меняются строки — структуры
— Могут передумать и сказать переделать
— Могут что-то вообще отменить
Только непосредственно взаимодействуя с ним ты по-настоящему выясняешь как оно работает.
Если его работа формализована и не будет меняться, — окей. Но если она будет меняться (а в наши эджайльные времена это очень возможно), то лучше писать полнотекстные сценарии уже потом.
А по Болтону это очень даже тестирование, и я в этом с ним согласен.
Роман, вы, видимо, не работали на проектах с реальной личной ответственностью. Когда заказчик, генерал какой нибудь силовой структуры, может лично вас спросить почему у вас «строки-структуры поменяны» а руки и ноги местами нет.
Резко становится понятно, что программа должна работать так как ожидает заказчик, а не как видит разработчик. Что если РП пожимает плечами: «ну такой вот проект», то это значит не что проект такой, а что проблему надо эскалировать до его начальника. И что баги писать надо в багтрекер, а не в тесткейсы.