Даже давние, уважаемые, профессиональные тестировщики скажут вам: это искусство больше, чем наука.
Мой трюк при разработке новых тестовых примеров начинается с различных типов тестов, которые вы упомянули, и должен включать все те, которые являются тщательными, но я пытаюсь найти список всех способов, которыми я могу взаимодействовать с кодом / продуктом.
Для примера торгового автомата, есть тонны деталей, внутри и снаружи.
Простое тестирование, поскольку продукт предназначен для работы, дает множество случаев
- Дает ли правильное изменение
- Как быстро он может обработать запрос
- Что делать, если товара нет в наличии
- Что, если он переполнен
- Что, если ящик смены заполнен
- Что делать, если предметы слишком большие или плохо уложены
- Что делать, если пользователь вкладывает слишком мало денег
- Что делать, если оно не изменилось
Тогда есть интересные случаи, о которых обычные пользователи не подумают.
- Что если вы попытаетесь опрокинуть его
- Дайте ему поддельную монету
- Украсть у него
- Положите монету со струной
- Дайте ему смешные суммы изменений
- Дайте ему половинные счета
- Открой его ломом
- Поток плохой силы / затухания
- Выключите его во время различных операций
Способ мыслить как тестер состоит в том, чтобы придумать любой возможный способ атаковать его, от всех «забавных случаев» в обычных сценариях до всех методов, которые полностью выходят за рамки того, как его следует использовать. Любая точка ввода, включая те, которые, по вашему мнению, контролируют разработчики / владельцы, является честной игрой.
Вы также можете использовать множество инструментов автоматического тестирования, таких как выбор парных тестов, наборы инструментов для тестирования на основе моделей, или для программного обеспечения, различных инструментов для защиты от нагрузки / нагрузки и безопасности.
Я чувствую, что этот ответ был хорошим началом, но теперь я понимаю, что это только половина истории.
Важно использовать все возможные способы тестирования системы. Вам нужно научиться расширять пределы своего воображения, свои навыки декомпозиции проблем, ваше понимание цепочек функциональности / сбоя и знание предметной области того, что вы тестируете. Это точка, которую я пытался изложить выше. При правильном мышлении и достаточной бдительности эти навыки начнут улучшаться очень быстро - через год или через несколько лет (в зависимости от сложности предметной области).
Второй уровень становления очень компетентным тестером - это определение того, какие тесты вам нужны. Вы всегда сможете сломать каждую систему множеством разных способов. Являются ли эти неудачи важными или нет, это более интересный вопрос, и зачастую на него гораздо сложнее ответить. Преимущество ответа на этот вопрос, однако, двоякое.
Во-первых, если вы знаете, почему важно починить части системы, которые ломаются (или пропустить их исправление!), Тогда вы сможете понять, на чем следует сосредоточить свои усилия. Вы знаете, на что вы можете потратить меньше времени на тестирование, и на что вы должны тратить больше времени.
Во-вторых, и что более важно, вы поможете своей команде показать, на чем она должна сосредоточить свои усилия. Вы начнете раскрывать вещи, которые называются «неизвестными второго порядка». Ваша команда не знает, чего не знает.
Основной трюк, который помогает вам в этом, - всегда спрашивать «почему?», Пока тот, кого вы спрашиваете, не озадачен.
Пример:
Q: Почему этот тест?
A: Поскольку я хочу использовать все функции системы.
Q: Почему эта система работает таким образом?
A: Из-за решений, принятых программистом на основе спецификаций продукта.
Q: Почему в наших спецификациях об этом говорится?
A: Поскольку компания, для которой мы пишем программное обеспечение, требовала, чтобы программное обеспечение работало таким образом.
Q: Почему эта компаниязаключают контракт на добавление этого как требование?
A: Потому что их пользователи должны сделать: вещь:
Q: Почему пользователинужно сделать: вещь:?
A: Потому что они пытаются выполнить: xyz:
Q: Почему они должны выполнить: xyz:
A: Потому что они экономят деньги, делая: abc:
Q: Почему они выбрали: xyz: решить:abc:?
A: ... хороший вопрос.
Q: Что они могли сделать вместо этого?
A: ... теперь, когда я думаю об этом, есть множество вариантов!Может быть, один из них работает лучше?
С практикой вы начнете знать, какие конкретные вопросы «почему» задавать, а на каких фокусироваться.Вы также научитесь начинать глубже по цепочке и будете менее механичны в своем подходе.
Это больше не просто гарантия того, что продукт соответствует спецификациям, предоставленным разработчиком, пользователем, клиентом или конечным пользователем.,Это также помогает определить, является ли решение, которое вы предоставляете, решением наивысшего качества, которое может предоставить ваша команда.
Скрытое требование этого заключается в том, что вы должны понимать, что половина работы тестировщика - задавать вопросы всемвремя.Вы можете подумать, что ваши товарищи по команде будут раздражены этим, но, надеюсь, я показал, что это имеет решающее значение как для вашей разработки, так и для качества продукта, который вы тестируете.Умные и любопытные товарищи по команде, которые заботятся о продукте (которые не заняты и расстроены), будут любить ваши вопросы.