Во время тестирования я заметил, что одного и того же пользовательского сценария недостаточно просто пройти до конца. Важно понять, всё ли происходило так, как ожидал пользователь, и не пропустил ли я проблему по пути. Например, если экран сам переключается на следующий шаг, я смотрю не только на то, открылся ли он. Было ли действие пользователя, которое должно было вызвать переход? Успел ли человек прочитать информацию? Повторяется ли это поведение на других платформах? Во время практического тестирования я проверял пользовательские сценарии на разных платформах WEB, android и iOS, фиксировал отклонения в поведении и предложения по улучшению, а затем передавал результаты команде продукта. Вот какие выводы сделал по ходу работы. Сравнивать поведение, а не только результат Если сценарий успешно проходит на одной платформе, я не спешу считать проверку завершённой. Повторяю его в другом окружении и сравниваю поведение. При этом различие само по себе ещё не означает дефект. Я задаю себе вопрос: есть ли требование, которому противоречит результат? Если ответ неясен, нужно сначала разобраться в ожидаемом поведении, а не объявлять всё необычное ошибкой. Смотреть на путь глазами пользователя При проверке я стараюсь не останавливаться на отдельном элементе. Допустим, кнопка нажимается, но после этого пользователь не может перейти дальше. Формально нажатие сработало, но задача не выполнена. Поэтому я прослеживаю сценарий целиком: что было до действия, что произошло после и есть ли у пользователя возможность продолжить. Иногда проблема обнаруживается не там, где я ожидал её увидеть. Отделять дефект от неудобства Не каждое неудачное решение интерфейса можно назвать ошибкой. Например, функция может работать, но взаимодействовать с ней неудобно: текст трудно проверить перед отправкой или важная информация занимает слишком мало места на экране. В таких случаях я проверяю, нарушено ли требование. Если нет, рассматриваю находку как предложение по улучшению и объясняю, какую пользу оно может дать пользователю. Это помогает не смешивать ошибки и личные предпочтения. Думать о том, кто будет разбираться с находкой Когда проблема обнаружена, важно не просто записать, что что-то пошло не так. Я старался описать условия, последовательность действий, ожидаемый и фактический результаты. Перед передачей находки я спрашивал себя: сможет ли другой человек повторить проверку по моему описанию? Понятно ли, в чём именно отклонение и как оно влияет на сценарий? Если для понимания приходится додумывать детали, описание стоит улучшить. После исправления я также возвращаюсь к сценарию и проверяю, изменилось ли поведение. Ведь сам факт исправления ещё не гарантирует, что проблема устранена полностью. Что я вынес из практики Я стал лучше понимать, что работа QA начинается с вопросов. Почему произошло именно так? Как это влияет на пользователя? Одинаково ли ведёт себя продукт в других условиях? Есть ли требование, с которым можно сравнить результат? Я продолжаю развиваться в QA и собирать портфолио из практических проектов. Для меня этот опыт стал возможностью не только применять техники тестирования, но и учиться рассуждать как тестировщик. Мой главный вывод: найти необычное поведение недостаточно, нужно разобраться, является ли оно проблемой, показать, как её проверить, и объяснить, почему она заслуживает внимания команды.