Текст подготовлен по материалам внутреннего семинара Максилект.
Снифферы - это инструменты, позволяющие перехватывать, анализировать и модернизировать все запросы, которые через них проходят. Они полезны, когда из потока нужно извлечь какие-либо сведения или создать нужный ответ сервера. Так можно проводить модульное тестирование продукта, в котором есть и бэк, и фронт, и разные команды со своей версионностью.
В этой статье я расскажу об основных функциях снифферов, которые могут быть полезны QA. Попробую не вдаваться в теорию, а сфокусироваться на практике. Наиболее популярными представителями анализаторов трафика сейчас являются WhireShark, Fiddler и Charles Proxy. Об удобстве интерфейсов и функционале каждого из них можно рассуждать долго, учитывая все плюсы и минусы. Но здесь я отдал предпочтение Charles, поскольку сам им активно пользуюсь. Буду рассказывать на его примере.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Когда я впервые устроилась автоматизатором, меня наняла компания, где до меня не было QA-инженера. Я никогда раньше не занималась автоматизацией, однако убедила компанию, что моих базовых знаний Java хватит, чтобы разобраться. Это было задолго до появления чудесных ресурсов вроде Test Automation University, поэтому я потратила много времени и сил на метод проб и ошибок, прежде чем автоматизировала тесты, которые бы запускались и проходили. Мои тесты были длинными, нестабильными, их было тяжело поддерживать, и они были переполнены неявными ожиданиями и дупликацией кода – но это были мои тесты, и я получала большое удовольствие, разбираясь с автоматизацией самостоятельно.
Затем компания наняла нового разработчика, и менеджер решил, что будет здорово, если он изучит наше ПО, изучая мои тесты. Не советуясь со мной, разработчик полностью их переписал. Меня это задело, пока я не поглядела в тесты и не увидела, что он реорганизовал их, применяя модели и методы page object так, что дупликация кода исчезла. Тесты стало так легко поддерживать! Тогда я узнала, что лучше сотрудничать, а не тащить все самостоятельно, потому что другие могут обладать отсутствующими у нас навыками.
Меня зовут Юля, и я Mobile QA в компании Vivid Money.
В тестировании уже давно — столько всего интересного видела. Но как показывает практика, проблемы и заботы у всех одинаковые. Разница только в анализе, подходах и реализации решений.
В этой статье я расскажу, КАК ОБЛЕГЧИТЬ ЖИЗНЬ ТЕСТИРОВЩИКУ ВО ВРЕМЯ РЕГРЕССА!
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Если вас просят фокусироваться на тест-кейсах и тест-инструментарии, помните: тест-кейсы не находят баги. Баг находит тестировщик, а тест-кейс может сыграть роль в нахождении бага (спасибо Прадипу Сундарараджану за четкую формулировку).
Схожим образом автоматизированные проверки тоже багов не находят. Баг находит тестировщик, а проверка может сыграть роль в поиске бага.
Тест-инструмент не находит багов. Это делает тестировщик, а инструмент может сыграть роль в нахождении бага.
Система контроля версий (от англ. Version Control System, VCS) — это место хранения кода. Как dropbox, только для разработчиков!
Она заточена именно на разработку продуктов. То есть на хранение кода, синхронизацию работы нескольких человек, создание релизов (бранчей)... Но давайте я лучше расскажу на примере, чем она лучше дропбокса. Всё как всегда, история с кучей картиночек для наглядности ))
А потом я подробнее расскажу, как VCS работает — что значит "создать репозиторий", "закоммитить и смерджить изменения", и другие страшные слова. В конце мы пощупаем одну из систем VCS руками, скачаем код из открытого репозитория.
Автор: Никола Оуэн (Nicola Owen) Оригинал статьи Перевод: Ольга Алифанова
Я размышлял над этой статьей с тех пор, как увидел обсуждение в Министерстве Тестирования. Честно говоря, мне было сложно его интерпретировать – как можно точно описать важные навыки?
Чтобы структурировать свои мысли, я переформулировал "Важные навыки для тестирования" в вопрос, какие навыки полезны отличному тестировщику.
Привет, меня зовут Иван, я работаю руководителем горизонтали автоматизаторов в Skyeng. Занимаюсь менеджментом ресурсов автоматизаторов, внедряю процессы, которые упрощают работу ребят, пишу инструменты для команды (слак-бот, всякие интеграции с TMS и др.), менторю начинающих автоматизаторов и, иногда, пишу авто-тесты.
Ручные тестировщики и начинающие автоматизаторы из компании часто спрашивают у меня, как им определиться с дальнейшим развитием. Я выделил 7 проблем, с которыми сталкивался сам, постарался рассказать, как боролся с ними и как можно обратить некоторые из своих слабых сторон на пользу себе и окружающим. Учиться на своих ошибках — хорошо, а на чужих — еще лучше. Надеюсь, мой рассказ поможет вам пойти вторым путем :)
В современном мире тестирование API становится неотъемлемой частью тестирования продукта в целом. Если раньше приложение взаимодействовало только со своим сервером, то в наши дни ни одно приложение не обходится без общения с сервисами метрик, социальными сетями и другими приложениями. Это общение происходит через API - специальный интерфейс, через который программы общаются друг с другом.
Соответственно, кратно растет спрос на специалистов, которые будут тестировать эти API.
Так как API нужно для общения именно программ, его не получится протестировать через какой-то пользовательский интерфейс. Лучшим подходом будет автоматизация тестирования API с помощью написанной нами программы. Python является идеальным выбором для этого. Он дает невероятную гибкость в создании сценариев тестирования с одной стороны, и не переусложняет создание и поддержку проекта с другой.
На курсе мы изучим все с нуля - от скачивания и установки нужных программ и библиотек до создания собственного фреймворка, с помощью которого мы напишем множество тестов. Итоговый проект, который вы напишите на курсе, можно будет закинуть на Github, использовать на работе или приложить к своему резюме.
Для прохождения курса нужно общее представление о том, как писать код на любом языке программирования - что такое условие IF, для чего нужны циклы и как создать класс. Всему остальному мы научим.
Курс исключительно практический - мы создали для него свой API, который и будем тестировать на протяжении всего курса. Плюс, вас ждет множество домашних заданий, которые будут проходить тщательное код-ревью.
И то, и другое — интерпретаторы командной строки в линуксе. То есть если вы откроете командную строку и введете любую команду, да хоть:
cd /home
То именно интерпретатор ее расшифрует и скажет компьютеру «он хочет перейти в директорию /home». Компьютер ведь не понимает команды на русском / английском языке. Ему нужны байтики. Этим и занимается интерпретатор — переводом с «нашего» на «компьютерный» язык.
Так что «cd /home» — это shell-команда! Или bash. Смотря какой интерпретатор установлен в вашей системе. В каждой операционной системе установлен интерпретатор по умолчанию. У них есть какие-то различия, но есть и набор базовых команд, которые понимают все: cd, mv, cp, ls…(в винде эти команды немного другие)
А что такое shell-скрипт тогда? Это просто текстовый документ, внутри которого написан набор команд! Это не обязательно должны быть «сложные» команды, которые делают что-то супер-навороченное. Это любые команды, которые вы выполняете в консоли.
