Фраза прекрасная. В ней есть все: оптимизм, вера в код и вполне человеческое желание нажать "Опубликовать" уже сегодня.

Заказчика тоже можно понять. Продукт почти готов, разработчики уверены, все открывается, кнопки нажимаются. И тут появляется тестирование, которое со стороны легко принять за дополнительное время и деньги на проверку того, что вроде бы и так работает.

Вот только QA - это не человек, который еще раз нажимает те же кнопки.

У разработчика вектор один: собрать систему так, чтобы она работала. У тестировщика - обратный: найти, где и при каких условиях она перестанет работать.
И чем раньше ошибки встретятся в проекте, тем меньше шансов, что роль тестировщика внезапно достанется пользователю уже после релиза.

Это как с парашютом: до прыжка проверяют все, что можно проверить. Оставлять тестирование на момент свободного падения - стратегия эффектная, но не очень практичная.

С релизом примерно так же.

Ошибки тоже бывают разные. Где-то на старом смартфоне съехала верстка. Неприятно, но мир переживет. А где-то пользователь дважды нажал "Оплатить", интеграция с 1С не ожидала такой инициативы, и заказ потерялся в базе.
Пользователь вообще редко ведет себя строго так, как для него задумали. Нажимает дважды, возвращается назад, закрывает окно в самый неподходящий момент. Иногда кажется, что исключительно из исследовательского интереса.

Поэтому в Bulltech QA подключается еще на этапе требований. Тестировщик смотрит прототипы, затем реализацию и заранее задает те самые вопросы: "А что будет, если..?"

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

Сомневаетесь в надежности своего продукта? Давайте проведем аудит и найдем слабые места до того, как их заметят ваши клиенты.

Бультех в Telegram | MAX | ВКонтакте | VC | Behance

#услуги