Сообщений в теме: 6

[gamretsky]

Столкнулся с такой мыслью, как правильно протестировать что-то, что сохраняет старый функционал, но принцип работы меняет.
Например у нас в проекте сказали для каждого окна (клиента под которым мы можем зайти в одном браузере) генерить новый SessionID, так как возникали некоторые накладки. Сделали, работает, а что именно проверять-то?
Ну что мне первое пришло в голову:
- убедится в том что все старое работает так же как и работало
А вот с тем как найти в этом какие либо БАГи мыслей нет, ну попробовать поменять этот SessionID и все.
Готов выслушать Ваши мнения, прошу не абстрагироваться на текущем примере, интересуют какие то общие принципы такого тестирования.

[achumagin]

1. Если session IdБ где то еще используется, то проверить это
2. Спросить у программистов, что еще могло сломаться, какие классы, методы и т.д. меняли.
3. Проверять, основываясь на рисках

[negro]

Столкнулся с такой мыслью, как правильно протестировать что-то, что сохраняет старый функционал, но принцип работы меняет...

Регрессионное тестирование: "Я вижу твоё желание. Твоя цель здесь. Иди ко мне.".

А если серьёзно:
1)

...возникали некоторые накладки...

1.1 Накладки кто выявил, вы? нет - изучите их как следует (локализацию и проявление).
1.2 Если имеете доступ к системе хранения версий исходников и умеете читать код - проанализируйте, что и где поменяли девелоперы.
1.3 Подготовьте/проведите адекватные тесты, чтобы убедиться - проблема решена.
2)

...что мне первое пришло в голову: убедится в том что все старое работает так же как и работало

2.1 Автоматизированные тесты есть?
2.2 Убедились, что старое работает на старых сценариях и наборах данных - это здорово, но:
2.3.1 Старые наборы сценариев модифицировали?
2.3.2 Наборы данных модифицировали?
3)

2. Спросить у программистов, что еще могло сломаться, какие классы, методы и т.д. меняли.

Нет!
Естественно, они не только чинят, но и ломают. Знали бы где и что - не было бы проблем, поэтому спрашивать у девелоперов: "где в программе баги?" - это для неадекватного тестера. Кстати, девелоперы "под шумок" наверняка, что-нибудь ещё где-нибудь отрефакторили...
<<Тестер, никому не верь!>>
4)

3. Проверять, основываясь на рисках

Нет!
Да - основываясь на плане тестирования (чек-листе, кейсах...)
<<Тестер, проверяй всё, за что отвечаешь!>> (но! заметишь дефект, который пропустил коллега, - быстрее беги к тест-лиду и доложи! а потом с этим коллегой, например, попейте кофе в непринужденной беседе...)

[Фрося]

Спрашивать у программиста смысл имеет.
И большой - в том случае если есть представление о проекте ПО.
О том, как ПО устроено.

[negro]

...Спрашивать у программиста смысл имеет...

А если, (что обычно для нашей действительности) всё типа очень запущено:
1) проект похоже уже сдан/на сопровождении, - значит команда девелоперов рассыпалась/занимается другими задачами;
2) в команде было несколько программистов и каждый свою часть "пилил" (кто - frontend, кто - backend), не погружаясь в контекст работы коллег;
3) проект эволюционировал-эволюционировал и наконец потерял целостность восприятия;
...
и вот программист Вася Пупкин (сами знаете уровень специалистов сопровождения, - знает ПО, как два пальца) и

...сохраняет старый функционал, но принцип работы меняет...

Не знаю как вы, - я буду во фрустрации!

[gamretsky]

Спасибо всем за свое мнение и советы в отношении решения данной ситуации.
К сожалению проект еще не до конца заточен под регрессионное тестирование, все только начинает набирать обороты.
У нас есть желание. Мы видим цель. Мы к ней движемся!
Провести регрессионное логично, думал есть еще какие то варианты, а еще понял что эти варианты не нужны.

[Arkady]

Определить какие области функционала мог задеть изменнный SessionID. Если не уверен что сам можешь определить то спросить программистов с каким функционалом связан SessionID и протестировать только его. Если у всех сомнения и точно незнают то протестировать все (регриссионное тестирование). Если нет регриссионного то значит просто все протестировать и заодно составить регриссионное на будущее.
Возможно SessionID вообще не связан ни с каким функционалом тогда просто проверить что SessionID изменился.

- так как возникали некоторые накладки

и необходиом узнать какие накладки возникали

- К сожалению проект еще не до конца заточен под регрессионное тестирование

Регрессия - это просто повторение тестов которые уже были, но часто в более урезанном варианте.
Или в том смысле что проект в начальной стадии разработки и нет завершенных областей? тогда получается что он еще не протестирован и можно вообще не обращать внимание на SessionID, а тестировать в обычном режиме, если SessionID что-то задел то это все рано вылезет в процессе обычного тестирования.