Home

Автор: тренер курса “English for QA engineers” Татьяна Рыжова (компания “Лаборатория Качества”)

Когда я училась в инязе, у нас в рамках общего курса английского была такая под-дисциплина как домашнее чтение: каждый должен был выбрать себе произведение из англо-американской литературы для чтения в оригинале и каждый месяц отчитываться по прочитанному. Понятно, что это всегда  было вроде пересказа сюжета с некоей художественной интерпретацией. Но кроме этого нам нужно было работать с лексикой и грамматикой, которую автор использует в своем нарративе. Задания по грамматике формулировались примерно так: “Вот как хотите, а к концу следующего месяца вам нужно в своей книге найти минимум 20 предложений со структурой Future Perfect Passive” (требуемая структура менялась каждый месяц, естественно). И мы читали и искали. И каждый раз, находя требуемую формулировку (существование которой в нормальной жизни для меня было до этого момента спорным) в тексте, я испытывала просто щемящий восторг от осмысления того, зачем нас всему этому учат (ну, если Фицджеральд так метко вставляет этот Perfect Passive в уста персонажа, значит и мне пригодится). С тех пор привычка читать не только с целью получения удовольствия и информации, но и с целью нахождения грамматических паттернов в текстах вошла в повседневный обиход.

Автор статьи: Артем Холевко, Максилект.

Текст подготовлен по материалам внутреннего семинара Максилект.

Снифферы - это инструменты, позволяющие перехватывать, анализировать и модернизировать все запросы, которые через них проходят. Они полезны, когда из потока нужно извлечь какие-либо сведения или создать нужный ответ сервера. Так можно проводить модульное тестирование продукта, в котором есть и бэк, и фронт, и разные команды со своей версионностью.

В этой статье я расскажу об основных функциях снифферов, которые могут быть полезны QA. Попробую не вдаваться в теорию, а сфокусироваться на практике. Наиболее популярными представителями анализаторов трафика сейчас являются WhireShark, Fiddler и Charles Proxy. Об удобстве интерфейсов и функционале каждого из них можно рассуждать долго, учитывая все плюсы и минусы. Но здесь я отдал предпочтение Charles, поскольку сам им активно пользуюсь. Буду рассказывать на его примере.

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Когда я впервые устроилась автоматизатором, меня наняла компания, где до меня не было QA-инженера. Я никогда раньше не занималась автоматизацией, однако убедила компанию, что моих базовых знаний Java хватит, чтобы разобраться. Это было задолго до появления чудесных ресурсов вроде Test Automation University, поэтому я потратила много времени и сил на метод проб и ошибок, прежде чем автоматизировала тесты, которые бы запускались и проходили. Мои тесты были длинными, нестабильными, их было тяжело поддерживать, и они были переполнены неявными ожиданиями и дупликацией кода – но это были мои тесты, и я получала большое удовольствие, разбираясь с автоматизацией самостоятельно.

Затем компания наняла нового разработчика, и менеджер решил, что будет здорово, если он изучит наше ПО, изучая мои тесты. Не советуясь со мной, разработчик полностью их переписал. Меня это задело, пока я не поглядела в тесты и не увидела, что он реорганизовал их, применяя модели и методы page object так, что дупликация кода исчезла. Тесты стало так легко поддерживать! Тогда я узнала, что лучше сотрудничать, а не тащить все самостоятельно, потому что другие могут обладать отсутствующими у нас навыками.

Автор статьи: Юлия Колесникова, Mobile QA в компании Vivid Money, телеграм канал — t.me/vivid_tech

Оригинальная публикация

Меня зовут Юля, и я Mobile QA в компании Vivid Money.

В тестировании уже давно — столько всего интересного видела. ​ Но как показывает практика, проблемы и заботы у всех одинаковые. Разница только в анализе, подходах и реализации решений.

В этой статье я расскажу, КАК ОБЛЕГЧИТЬ ЖИЗНЬ ТЕСТИРОВЩИКУ ВО ВРЕМЯ РЕГРЕССА!

Расскажу по порядку:

1. Наши процессы (для полноты картины)

2. Основную проблему

3. Анализ

4. Методы решения, с полученными результатами

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Если вас просят фокусироваться на тест-кейсах и тест-инструментарии, помните: тест-кейсы не находят баги. Баг находит тестировщик, а тест-кейс может сыграть роль в нахождении бага (спасибо Прадипу Сундарараджану за четкую формулировку).

Схожим образом автоматизированные проверки тоже багов не находят. Баг находит тестировщик, а проверка может сыграть роль в поиске бага.

Тест-инструмент не находит багов. Это делает тестировщик, а инструмент может сыграть роль в нахождении бага.

Автор: Ольга Назина (Киселёва)

Система контроля версий (от англ. Version Control System, VCS) — это место хранения кода. Как dropbox, только для разработчиков!

Она заточена именно на разработку продуктов. То есть на хранение кода, синхронизацию работы нескольких человек, создание релизов (бранчей)... Но давайте я лучше расскажу на примере, чем она лучше дропбокса. Всё как всегда, история с кучей картиночек для наглядности ))

А потом я подробнее расскажу, как VCS работает — что значит "создать репозиторий", "закоммитить и смерджить изменения", и другие страшные слова. В конце мы пощупаем одну из систем VCS руками, скачаем код из открытого репозитория.

Автор: Никола Оуэн (Nicola Owen)
Оригинал статьи
Перевод: Ольга Алифанова

Я размышлял над этой статьей с тех пор, как увидел обсуждение в Министерстве Тестирования. Честно говоря, мне было сложно его интерпретировать – как можно точно описать важные навыки?

Чтобы структурировать свои мысли, я переформулировал "Важные навыки для тестирования" в вопрос, какие навыки полезны отличному тестировщику.

Оригинальная публикация

Привет, меня зовут Иван, я работаю руководителем горизонтали автоматизаторов в Skyeng. Занимаюсь менеджментом ресурсов автоматизаторов, внедряю процессы, которые упрощают работу ребят, пишу инструменты для команды (слак-бот, всякие интеграции с TMS и др.), менторю начинающих автоматизаторов и, иногда, пишу авто-тесты.

Ручные тестировщики и начинающие автоматизаторы из компании часто спрашивают у меня, как им определиться с дальнейшим развитием. Я выделил 7 проблем, с которыми сталкивался сам, постарался рассказать, как боролся с ними и как можно обратить некоторые из своих слабых сторон на пользу себе и окружающим. Учиться на своих ошибках — хорошо, а на чужих — еще лучше. Надеюсь, мой рассказ поможет вам пойти вторым путем :)