Что тестирование без навыков разработки ловит, а ревью — нет
Ложь
Сообщение об успехе — а данные не сохранились. Чтение кода показывает намерение, а не результат.
Путаница
Сценарий формально работает, но никто не может пройти его до конца. Это замечает только человек.
Допущение
Работает для аккаунта, на котором это создавали, и ломается у всех остальных.
Для владельца того самого первого аккаунта это невидимо.
Четыре проверки, для которых не нужен код
Сделайте действие — и перезагрузите. Отделяет «экран обновился» от «данные сохранились». Самая результативная проверка из всех.
Сделайте то же самое от имени другого человека. Второй аккаунт мгновенно вскрывает допущения о правах доступа.
Сделайте намеренно неправильно. Отправьте заведомо некорректные данные и проверьте, что приложение прямо об этом сообщает, а не падает молча.
Попробуйте, когда данных нет вообще. Пустые состояния делают в последнюю очередь и проверяют реже всего.
Как написать отчёт, по которому починят
Три предложения, без технической лексики. Что вы делали, по порядку. Что вы ожидали. Что произошло вместо этого. «Я заполняю форму и нажимаю «Сохранить», ожидаю увидеть запись в списке — список пуст, пока я не перезагружаю страницу»: это указывает прямо на дефект и не требует толкования.
И это тоже проверка. Записанная один раз, она может выполняться после каждого следующего изменения.
Что делать, если по вашему отчёту никто ничего не предпринимает
Самое частое разочарование в этой роли — найти настоящую проблему и наблюдать, как она висит без движения. Обычно дело не в том, что вам не верят, а в том, что в отчёте недостаточно информации, чтобы кто-то мог начать.
Этот разрыв закрывают три вещи. Укажите, под каким аккаунтом и в каком окружении это произошло: баг, который проявляется только у одного типа пользователей, — это другой баг. Укажите, воспроизводится ли он каждый раз или время от времени: у плавающих и стабильных проблем совершенно разные причины, и знание этого экономит час. И явно напишите, чего вы ожидали: в половине случаев спор оказывается о требовании, а не о коде, и это стоит вскрыть пораньше.
Ничего из этого не требует технической лексики. Но именно это отличает отчёт, который просто рассортируют, от отчёта, по которому починят.
Как сделать, чтобы проверки пережили вас
Ограничение в тестировании без навыков разработки — никогда не квалификация, а то, что человек способен перепроверить лишь ограниченный объём. Если описать сценарий обычным языком и запускать его автоматически, этот потолок исчезает — и никому не нужно осваивать фреймворк.
Для всего этого не нужен терминал. Создайте проект в панели управления TestSprite, опишите проверку обычным языком и укажите своё приложение. Разработчики в вашей команде при желании могут делать то же самое из командной строки, которая лежит в репозитории CLI.
Два пути, и выбор на самом деле о том, кто владеет пайплайном. Подключение GitHub App из панели управления вообще не требует изменений в вашем репозитории, потому что реагирует на деплой, который ваша сборка и так выпускает. Добавление шага GitHub Actions помещает проверку в репозиторий, где её смотрят на ревью наравне с остальной сборкой.
Как TestSprite превращает ваши проверки в нечто постоянное
Вы описываете сценарий так же, как объяснили бы его коллеге, а TestSprite прогоняет его на приложении. Ни тестового кода, ни фреймворка, ни терминала. Создайте проект в панели управления, укажите свой продукт и напишите те самые три предложения: что вы делали, что ожидали и что должно быть верно после этого.
Дальше проверка запускается при каждом изменении. Четыре проверки с этой страницы перестают быть тем, что вы повторяете руками, и становятся записью, которая продолжает работать, пока вы заняты другим.
Польза здесь конкретная: ваше знание о том, как всё должно работать, перестаёт жить только в вашей голове — именно это делает ваш вклад видимым для остальных и сохраняет его после того, как вы переключитесь на следующую задачу.
Нужно ли мне учиться программировать?
Нет. Опишите сценарий обычным языком. Ваша ценность — в знании того, как должно быть, а это не навык программирования.
Как понять, что моя проверка настоящая?
Намеренно сломайте то, что проверяете, и убедитесь, что проверка падает. Это одна минута и единственное доказательство, что она вообще к чему-то подключена.
Что делать, если разработчики отмахиваются от моего отчёта?
Используйте три предложения. От конкретной последовательности действий с описанным ожиданием отмахнуться намного труднее, чем от «оно не работает».
Тестировать до изменения или после?
И то, и другое. Проверка, существовавшая до изменения, показывает, сломало ли оно что-нибудь, — и это более ценное направление.
Что проверить в первую очередь, если можно только одно?
Сделайте действие и перезагрузите. На этом продукты спотыкаются чаще, чем на чём-либо ещё, а занимает это пять секунд.
То, что вы не читаете код, здесь преимущество.
Тестирование ПО без навыков разработки ловит ложь, путаницу и допущение — три вещи, которых ревью кода структурно не видит. Перезагружайте, заходите со второго аккаунта, делайте намеренно неправильно, пробуйте на пустоте — и записывайте проверки, чтобы они жили дольше одной сессии.