Тестировщики часто сталкиваются с багами, которые зависят от окружения. Иногда приходится долго настраивать все необходимые программы, чтобы проверить какую-то функциональности или запустить автотесты. А уж переезд с одной машины на другую — вечная боль.
Благо, некоторое время назад появился Docker — среда для контейнеризации софта, позволяющая легко создавать и передавать отдельные контейнеры с софтом, которые работают везде одинаково. Долгое время Docker был популярен только среди DevOps, но в последнее время он все чаще используется в тестировании.
И действительно, ведь можно один раз настроить все нужные приложения, положить их в свои контейнеры — а потом запускать где угодно и сколько угодно раз. Это значительно сокращает время тестирования и повышает его удобство.
Про устройство Docker и его преимущества вы можете узнать из видео:
А если вы хотите узнать больше — подписывайтесь на наш youtube-канал и приходите на курс “Docker: инструменты тестировщика”, где вы всего за 2 недели сможете научиться работать с этим инструментом на достаточном для QA уровне.
В этом разделе мы поговорим о популярном тренде, который называется ‘публичные облака’. Несмотря на огромную пользу, которую дают описанные выше технологии виртуализации и контейнеризации, нам все еще необходимы вычислительные ресурсы. Компании приобретают дорогие сервера или арендуют дата-центры, но в таком случае необходимо сделать расчеты (иногда нереалистичные) того, как много ресурсов нам понадобится, будем ли мы их использовать 24/7 и для каких целей. Например, для production требуется работающий круглосуточно сервер, но нужны ли нам аналогичные ресурсы для тестирования в нерабочее время? Это также зависит от типа выполняемого тестирования. Примером могут быть нагрузочные/стрессовые тесты, которые мы планируем прогонять в нерабочие часы, чтобы получить результаты на следующий день. Но, определенно, круглосуточная доступность серверов не требуется для end-to-end авто-тестов и в особенности для сред ручного тестирования. Для таких ситуаций было бы хорошо получать столько ресурсов, сколько необходимо по требованию, использовать их и прекращать платить, когда они больше не нужны. Более того, было бы прекрасно получать их моментально, сделав несколько кликов мышкой или запустив пару скриптов. Для этого и используются публичные облака. Давайте посмотрим на определение: “The public cloud is defined as computing services offered by third-party providers over the public Internet, making them available to anyone who wants to use or purchase them. They may be free or sold on-demand, allowing customers to pay only per usage for the CPU cycles, storage, or bandwidth they consume”.
В настоящее время специальность DevOps является одной из наиболее востребованных в IT-индустрии. Если вы откроете популярные сайты по поиску работы и зададите фильтр по зарплатам, то увидите, что вакансии, связанные с DevOps, находятся в начале списка. Однако важно понимать, что это в основном относится к позиции ‘Senior’, что подразумевает, что кандидат обладает высоким уровнем навыков, знанием технологий и инструментов. К этому также прилагается высокая степень ответственности, связанная с бесперебойной работой production. Однако мы стали забывать, что такое DevOps. Изначально это не был какой-то конкретный человек или департамент. Если поискать определения этого термина, то мы найдем много красивых и правильных существительных, таких как методология, практики, культурная философия, группа концептов и так далее.
Автор: Джош Грант (Josh Grant) Оригинал статьи Перевод: Ольга Алифанова
Начиная серию статей, рассказывающих о чудесных возможностях Pytest, я решил начать с широко известного плагина для работы с тестами на основе браузеров. Этот плагин имеет говорящее имя pytest-selenium.
Автор: Энджи Джонс (Angie Jones) Оригинал статьи Перевод: Ольга Алифанова
Разработка на основе поведения, также известная как BDD – это основанная на примерах методология для разработки ПО. Ключевой момент в BDD – это совместная деятельность Бизнеса, Разработки и Тестировщиков. Эти участники также известны как "Три товарища".
Начиная работу над новой фичей, три товарища собираются вместе и пишут примеры использования этой фичи. Обсуждая эти примеры, они приходят к общему пониманию того, как фича должна себя вести в различных сценариях.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Все, кто работает с системами контроля версий – например, с Git, - рано или поздно сталкиваются с конфликтом слияния. Если вы новичок в Git, то вот простой пример конфликта слияния:
Мастер-ветка содержит файл с текстом:
"Кристин Джеквони была здесь 22 мая 2019".
Прюнелла и Джо выкачивают себе по версии этой мастер-ветки. Прюнелла создает ветку по имени "Прюнелла", а Джо – ветку по имени "Джо".
Джо обновляет файл в ветке, и теперь там вот что:
"Кристин Джеквони была здесь 22 мая 2019.
Джо Шмое был здесь 23 мая 2019".
Джо создает пулл-реквест для своих изменений, и они одобряются и вливаются в мастер-ветку.
Вскоре после этого Прюнелла обновляет файл в своей ветке, и теперь там вот что:
Решил написать свое мнение касательно того, заменит ли автоматизация тестирования, собственно, тестировщиков. Прежде всего потому, что довольно часто слышу подобное мнение среди Junior QA, кто только делает свои первые шаги в тестировании и уже боится, что чего-то не успел.
Справедливости ради, подобное мнение бытует и среди ребят постарше. Довольно часто считается, что автоматизация — чуть ли не единственный путь развития ручного тестировщика. Обо всем этом и многом другом под катом.
Небольшое уточнение, прежде чем мы начнем. Вся речь далее будет идти о функциональных автотестах. Это именно UI-тесты, которые не стоит в данном контексте путать с unit-тестами. Последние всегда писались и должны писаться разработчиками, а где это не так — это предмет уже совсем другого обсуждения.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Множество статей, постов и презентаций посвящено фреймворкам и стратегиям автоматизаци. Однако даже самые надежные фреймворки автоматизации не исключат нужду в исследовательском тестировании. Мы всегда будем сталкиваться с ситуациями, в которых понадобится генерация длинного текста для проверки текстовых полей или кодировки строки в HTML для тестирования на межсайтовый скриптинг. В этот раз я поделюсь пятнадцатью любимыми бесплатными инструментами, которые упрощают и ускоряют тестирование.
