Я в таком случае фиксировал поведение(то как в данный момент ведет себя система). И брал его за ожидаемый результат. В случае нахождения отличия ожидаемого и фактического результат, мы будем иметь баг. Ну а если выяснится что поведение(которое мы изначально брали за ожидаемое) было ошибочным, то корректируем ожидаемый результат. Чаще всего, в таких случаях, 2-3 подобные итерации тестирования помогут более-менее получить внятный ожидаемый результат.
Есть в этой ситуации и психологический фактор. Я его называю "Все не по плану", ну или наше народное: "Все через ж...". Тут я могу сказать, что плохого опыта не бывает. Если преодолеть подобную ситуацию и научиться выходить из нее, то это будет отличный опыт.
Тут есть еще 1 момент, который стоит подсветить. Если начальство с тебя не снимает за это шкуру, то первые все что написано выше - вам может помочь. А вот если начальство еще и "спрашивает" за это, то тут надо уметь прикрыть свою филейную часть. Как это можно сделать:
найти линии разграничения твоей зоны ответственности, с другими коллегами
исправить все косяки на своей стороне
отрапортовать руководству(только в письменной форме!) что проблемы находятся в определенной(или определенных) зонах, где твоей ответственности нет, но они напрямую на тебя влияют.
Да, конечно, можно идти по жесткому сценарию и стать "в позу", мол дайте мне ТЗ и все нужную документацию. Но боюсь это будет тупиковый сценарий, кторый приводит к смене проекта/работы.
Если мы говорим про ситуацию, когда вам не сообщают что проект с проблемами - согласен. Но если вы осознанно идете на такой проект(по разным причинам), то это уже другая ситуация. И требует она несколько других действий.
Я в таком случае фиксировал поведение(то как в данный момент ведет себя система). И брал его за ожидаемый результат. В случае нахождения отличия ожидаемого и фактического результат, мы будем иметь баг. Ну а если выяснится что поведение(которое мы изначально брали за ожидаемое) было ошибочным, то корректируем ожидаемый результат. Чаще всего, в таких случаях, 2-3 подобные итерации тестирования помогут более-менее получить внятный ожидаемый результат.
Есть в этой ситуации и психологический фактор. Я его называю "Все не по плану", ну или наше народное: "Все через ж...". Тут я могу сказать, что плохого опыта не бывает. Если преодолеть подобную ситуацию и научиться выходить из нее, то это будет отличный опыт.
Тут есть еще 1 момент, который стоит подсветить. Если начальство с тебя не снимает за это шкуру, то первые все что написано выше - вам может помочь. А вот если начальство еще и "спрашивает" за это, то тут надо уметь прикрыть свою филейную часть. Как это можно сделать:
найти линии разграничения твоей зоны ответственности, с другими коллегами
исправить все косяки на своей стороне
отрапортовать руководству(только в письменной форме!) что проблемы находятся в определенной(или определенных) зонах, где твоей ответственности нет, но они напрямую на тебя влияют.
Да, конечно, можно идти по жесткому сценарию и стать "в позу", мол дайте мне ТЗ и все нужную документацию. Но боюсь это будет тупиковый сценарий, кторый приводит к смене проекта/работы.
P.S. надеюсь эта информация вам поможет
Если мы говорим про ситуацию, когда вам не сообщают что проект с проблемами - согласен. Но если вы осознанно идете на такой проект(по разным причинам), то это уже другая ситуация. И требует она несколько других действий.