10 способов как не надо тестировать высоконагруженный...

* “Утром деньги, вечером стулья” — острая нехватка времени на написание функциональных автотестов из-за большого количества ручного тестирования. * “Firefox наше всё” — классическая схема работы “разработка проверяет в FF, а тестирование во всех браузерах” не всегда эффективна, когда есть дисбаланс между числом разработчиков и тестировщиков в команде. * “Специалист узкого профиля” — автоматизированные тесты долго не пишутся из-за того, что тестировщик не знает языка программирования. * “У нас все готово” — во время деплоя возникают ошибки, деплой идет долго, баги фиксятся по ходу релиза; смежные команды/заказчики/партнеры не знают о смене работы функционала, добавления полей и т.п. * “И жнец и жрец” — задача долго не проходила этап тестирования, из-за того, что разработчики чинили верстку, а не верстальщики. * “Всё как на картинке” — тестирование не может определить специфические баги в верстке, такие как отсутствие тени или закругленности углов, РМ тоже. * “Незаменимый человек” — один человек прорабатывает требования перед планированием, никто кроме самого человека не знает требований. * “Без вопросов” — из-за размытых требований тестирование не может выявить критичные баги, отсутствие информации о технических нюансах не позволяет группе тестирования указать их. * “Перфекционизм” — чрезмерное “вылизывание” перед релизом затягивает выход очередной версии продукта. * “Грузи, всё вывезет” — от релиза к релизу с добавлением новых фич скорость работы сервиса снижается.