Как стать автором
Обновить

В поисках самого лучшего способа тестирования системы

Время на прочтение8 мин
Количество просмотров19K
Всего голосов 21: ↑20 и ↓1+19
Комментарии9

Комментарии 9

Вопрос по таблице. При "Небольшом бюджете" тестирование, предполагается, вообще не проводить?

Может быть, при «небольшом бюджете» тестирование становится искусством (очень сложное ограничение — и протестировать надо, и денег нет), и думать об этом в смысле этой таблицы уже не применимо? Есть какая-то хитрая комбинация минимально необходимых мер, сильно зависящая от очень конкретных обстоятельств и микро-проблем. Ландшафт будет в основном формироваться этими микро-проблемами, а не аналитикой
По сути, имхо, градация между сценарным и исследовательским подходами, очень напоминает градацию между каскадной и гибкими методологиями. На мой взгляд, автор занимается адаптацией этих методологий к процессу тестирования, хотя прямых аналогий не проводит.

А ещё сравнительная таблица очень напоминает приведённую у Макконнелла в «совершенном коде»: насколько детальным должно быть проектирование по ситуации.
Почему автор считает, что при подробном сценарном тестировании, тестировщик не занимается и отчасти исследовательским? Мне кажется, автор считает, что цель тестировщика при сценарном тестировании — пройти сценарий, но это не так, так же как и в исследовательском тестировании целью является проверка, что система работает так, как ожидалось и поиск ошибок. Да, у тестировщика есть сценарий, который как правило описывают возможные сценарии работы пользователя с системой, и тестировщик обязан проверить, что такой сценарий выполняется, но при этом тестировщик так же может производить проверки и не описанные в сценарии.

При подробном сценарном тестировании, весь акцент и поставлен на сценарий. Вам все равно придётся проходить эти сценарии, а совмещать подробное сценарное и исследовательское… хм, пока не понимаю какую выгоду вы в этом увидели. По мне это будут очень большие трудозатраты, и не стоит делать какого-то гибридного гиганта из этого…

Вы не можете проводить исследовательское тестирование при регрессионном тестировании большой и сложной системы большой командой. Очень велик шанс, что какие то сценарии работы не будут протестированы. Но с другой стороны, вы не можете проходить только сценарий, из-за этого велик шанс, что вы пропустите ошибки при вариантах работы системы, которые не были учтены при составлении сценария. Поэтому, сейчас происходит как. У тестировщика есть сценарий, который он обязан пройти, этот сценарий, соответствует тому, как пользователи будут работать с системой, но при прохождении сценария, тестировщик может так же «попутно» проверить другие сценарии работы на свое усмотрение, вводить некорректные данные и многое другое. К тому же, когда систем много, то тестировщик может не знать всех ньюансов работы с системой, тогда ему тоже необходим сценарий.

Я понимаю вашу логику, и думаю что действительно это имеет место быть — для больших систем, типа банковских и т д, но в тоже время такой выбор тестирования, заставляет очень много времени тратить на поддержку, актуализацию, написание сценариев… Насколько это выгодно для вас — решать только вам конечно же.
Возможно, этот вариант — это хорошая подушка безопасности)
Но думаю мы все равно не придём никогда к 1 мнению, так как все равно для каждой организации подойдёт исключительно свой процесс, и то что кажется верным мне — может быть совершенно противоположным для вас)

Ну изначально мне не понятно было, почему сценарное тестирования исключает исследовательское. Прохождение сценария — это не цель, а средство проверки качества системы. И да, я считаю, что если для маленьких систем можно обойтись только исследовательским тестированием, то для больших систем, сценарий в том или ином виде, с каким-либо уровнем детализации, необходим.
Я до сих пор не понимаю этих терок между скриптовым и исследовательским тестированием. Неужели до сих пор жесткое следование детально прописанным сценариям широко распространено? Настолько, что это проблема, с которой надо бороться, продвигая исследовательское? Что вот тестировщики составили тест-кейсы и ни на шаг, не отступают от них.
Или это частный случай тренда «придумай проблему, а потом борись с ней», чтобы создавать движение в отрасли.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий