Автор: Кристин Джеквони (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-скрипт тогда? Это просто текстовый документ, внутри которого написан набор команд! Это не обязательно должны быть «сложные» команды, которые делают что-то супер-навороченное. Это любые команды, которые вы выполняете в консоли.
Автор: Майкл Болтон (Michael Bolton) Оригинал статьи Перевод: Ольга Алифанова
Приятель, дружба с которым только началась, ведет тренинги по развитию навыков для начинающих тестировщиков. Сегодня он сказал, что его студенты начинают проект, включающий тест-дизайн, тест-техники и запуск тестов. Есть ли у тебя совет для них, спросил он? Вот мой ответ.
Тест-дизайн, тест-техники и запуск тестов – классные вещи. Я бы предпочел "выполнение тестов" "запуску тестов" – мой вариант показывает, что тест – это деятельность, активно выполняемая человеком, адаптирующимся по ходу дела. "Запуск тестов" звучит как рецепт или запрограммированный набор инструкций.
Я бы советовал начать с выполнения тестов. Но этот совет может несколько смутить тех, кто убежден, что тестирование имеет дело только с неким (почти) готовым продуктом и нацелено на поиск ошибок кода. В Rapid Software Testing мы смотрим на вопрос шире: тестирование – это процесс оценки продукта путем его изучения через опыт, исследование и эксперименты, включающие до некоторой степени вопросы, наблюдения, моделирование, вмешательства, и т. д.
