Можете, пожалуйста, рассказать немного подробнее про ваш опыт использования Zalenium. В статье вы пишете, что он тоже не без проблем, с чем именно вы столкнулись? Тяжелое Java-прошлое в нем, ресурсоемкость...?
Спасибо еще раз.
Codeception пробовали/использовали — отказались по причине внутреннего для него meta-языка (например, $I->see('Home')), который нам совсем не подходит. Из-за этого пришлось писать обвязку над Codeception, которая дает возможность писать на «чистом» PHP, что в совокупности, архитектурно не очень хорошее решение.
Gherkin — не про нас, тоже навязывает свой мета-язык, который нам не близок.
Если для метрики покрытия используется кол-во описанных, но не реализованных тест кейсов, то как избежать следующей ситуации: Функциональность добавилась, тесты нет => покрытие осталось прежним…
Тут вы абсолютно правы, если функциональность добавилась и QA-специалист не добавил в систему todocase или не написал тест, то покрытие останется прежним, по-другому можно сказать, что данная функциональность не была добавлена в регрессионные проверки.
Во первых хочу отметить, что действительно не каждая функциональность должна добавляться в регрессию, это зависит от многих факторов, а во вторых, в этом вопросе мы доверяем тестировщикам, они лучше всех знают когда в систему UI-тестирования нужно добавить тест или «заявку на покрытие» — todocase. Наша система, как и любая другая требует работы по актуализации :)
Прошу прощения, пропустил слово при ответе на первый вопрос: Тесты на Production проходят практически всегда так, как мы и ожидаем — это результат большой работы.
samizdam, спасибо!
1. «Вы тесты на проде выполняете? Зачем?»
Да, мы выполняем специальный комплект тестов на Production. В первую очередь это нужно для того, чтобы гарантированно предоставлять нашим клиентам высокий уровень сервиса. Production-окружение имеет ряд отличий от наших stage-систем, как на «железном» уровне, так и на уровне контента, поэтому выполнение тестов полностью оправдано и нас отдельно радует то, что тесты на Production практически всегда так, как мы и ожидаем — это результат большой работы.
2. «Насколько я понял вы написали собственную реализацию приёмочных UI-тестов поверх webdriver для phpunit? И не совсем понятно тогда, что за отчёт генерится, о каком покрытии здесь речь…»
В основе нашей системы лежит PHPUnit, при помощи него осуществляется непосредственный запуск каждого теста. В статье не идет речь про компонент PHP_CodeCoverage, мы формируем отчет о покрытии проекта UI-тестами и строим его на основе тех данных, которые несут сами тесты в своем описании при помощи специальных лейблов.
nizkopal, спасибо!
1. «Насколько вы ему доверяете? Откуда берется понимание, что действительно все кейзы так или иначе описаны в тестах?»
Доверяем мы ему настолько, что на данный момент это наш единственный способ подсчета метрики покрытия UI-тестами. Про понимание того, что все кейсы описаны в тестах: Понимание основано на том, что тесты и описание к ним хранятся в одном месте, т.е у нас просто нет дублирующей системы хранения тест-кейсов, если QA-специалисту нужно добавить в систему регрессионный тест, то он так или иначе идет в код и в нем может сразу создать тест или написать описание с минимальной «заготовкой» под тест. И замечу, что у нас нет цели добавить в систему все кейсы, мы очень гибко подходим к каждому проекту и формируем для проектов именно то покрытие, которое им необходимо, не тратя лишние ресурсы.
2. «Не думали ли вы про приоритезацию кейзов? Чисто интуитивно кажется, что todo на тест покупки должен «бить» по покрытию больше, чем todo теста на клик какой-нибудь мало популярной ссылки в футере.»
При постановке задач на расширение покрытия приоритет todocase, конечно, играет роль, QA-специалист в большинстве случаев сам может принять решение по приоритетам, поэтому чаще всего приоритеты мы в описание не пишем, но делать это можно.
3. «Этот показатель как-то влияет на ваши процессы? Если он падает, о чем это вам говорит? Есть ли у него какой-то минимум, после которого весь отдел автоматизации дружно начинает работать по ночам?»
Начну с того, что желаемый процент покрытия проекта изначально согласовывается с менеджером продукта и на этот процесс выделяются необходимые ресурсы. Если процент покрытия в проекте падает, то чаще всего это означает то, что новые функциональные возможности в команде создаются без процесса актуализации тестового покрытия, что является нарушением производственного процесса. Поэтому QA-специалисты в первую очередь разбираются с этой проблемой, а затем планомерно (без авралов и работы по ночам) увеличивают процент покрытия до необходимого значения.
Можете, пожалуйста, рассказать немного подробнее про ваш опыт использования Zalenium. В статье вы пишете, что он тоже не без проблем, с чем именно вы столкнулись? Тяжелое Java-прошлое в нем, ресурсоемкость...?
Спасибо еще раз.
Gherkin — не про нас, тоже навязывает свой мета-язык, который нам не близок.
Тут вы абсолютно правы, если функциональность добавилась и QA-специалист не добавил в систему todocase или не написал тест, то покрытие останется прежним, по-другому можно сказать, что данная функциональность не была добавлена в регрессионные проверки.
Во первых хочу отметить, что действительно не каждая функциональность должна добавляться в регрессию, это зависит от многих факторов, а во вторых, в этом вопросе мы доверяем тестировщикам, они лучше всех знают когда в систему UI-тестирования нужно добавить тест или «заявку на покрытие» — todocase. Наша система, как и любая другая требует работы по актуализации :)
1. «Вы тесты на проде выполняете? Зачем?»
Да, мы выполняем специальный комплект тестов на Production. В первую очередь это нужно для того, чтобы гарантированно предоставлять нашим клиентам высокий уровень сервиса. Production-окружение имеет ряд отличий от наших stage-систем, как на «железном» уровне, так и на уровне контента, поэтому выполнение тестов полностью оправдано и нас отдельно радует то, что тесты на Production практически всегда так, как мы и ожидаем — это результат большой работы.
2. «Насколько я понял вы написали собственную реализацию приёмочных UI-тестов поверх webdriver для phpunit? И не совсем понятно тогда, что за отчёт генерится, о каком покрытии здесь речь…»
В основе нашей системы лежит PHPUnit, при помощи него осуществляется непосредственный запуск каждого теста. В статье не идет речь про компонент PHP_CodeCoverage, мы формируем отчет о покрытии проекта UI-тестами и строим его на основе тех данных, которые несут сами тесты в своем описании при помощи специальных лейблов.
1. «Насколько вы ему доверяете? Откуда берется понимание, что действительно все кейзы так или иначе описаны в тестах?»
Доверяем мы ему настолько, что на данный момент это наш единственный способ подсчета метрики покрытия UI-тестами. Про понимание того, что все кейсы описаны в тестах: Понимание основано на том, что тесты и описание к ним хранятся в одном месте, т.е у нас просто нет дублирующей системы хранения тест-кейсов, если QA-специалисту нужно добавить в систему регрессионный тест, то он так или иначе идет в код и в нем может сразу создать тест или написать описание с минимальной «заготовкой» под тест. И замечу, что у нас нет цели добавить в систему все кейсы, мы очень гибко подходим к каждому проекту и формируем для проектов именно то покрытие, которое им необходимо, не тратя лишние ресурсы.
2. «Не думали ли вы про приоритезацию кейзов? Чисто интуитивно кажется, что todo на тест покупки должен «бить» по покрытию больше, чем todo теста на клик какой-нибудь мало популярной ссылки в футере.»
При постановке задач на расширение покрытия приоритет todocase, конечно, играет роль, QA-специалист в большинстве случаев сам может принять решение по приоритетам, поэтому чаще всего приоритеты мы в описание не пишем, но делать это можно.
3. «Этот показатель как-то влияет на ваши процессы? Если он падает, о чем это вам говорит? Есть ли у него какой-то минимум, после которого весь отдел автоматизации дружно начинает работать по ночам?»
Начну с того, что желаемый процент покрытия проекта изначально согласовывается с менеджером продукта и на этот процесс выделяются необходимые ресурсы. Если процент покрытия в проекте падает, то чаще всего это означает то, что новые функциональные возможности в команде создаются без процесса актуализации тестового покрытия, что является нарушением производственного процесса. Поэтому QA-специалисты в первую очередь разбираются с этой проблемой, а затем планомерно (без авралов и работы по ночам) увеличивают процент покрытия до необходимого значения.