Друзья, сегодня выпала возможность отвечать на вопросы на долгоиграющую тему «Как стать Тестировщиком, каковы перспективы, и что необходимо, чтобы попасть в эту сферу.»

Как водится в начале любых мнениеизложений или презентаций, дам краткую (очень краткую) информацию о себе:
Работаю в QA два с половиной года. За это время сменил три компании, поработал на разных проектах. Много общался с основателями компаний и организаторами тренингов/конференций/семинаров. Проводил собеседования и следил за развитием рынка.

Следовательно, приведённое ниже мнение является лишь результатом личных наблюдений.



Разделю пост следующие части:
1. Наблюдения

• Почему отрасль Тестирования низкоквалифицирована?
• Личный опыт
• «Принцип Свитчера» и его влияние на QA

2. Возможные решения

Немало копий поломано в вопросе о том, как следует проверять адрес электронной почты (например, habrahabr.ru/post/175329), но позвольте предоставить вам немного статистики с реального проекта.

Довольно часто среди начинающих (и даже не очень) тестировщиков приходится слышать: «вот если бы я умел писать автотесты, я бы…». Как правило этим «если бы» ребята и ограничиваются. На вопрос: «А почему не учишься писать?» чаще всего отвечают: «Программирование это не мое». Действительно, тем для кого программирование темный лес, погрузиться в мир автотестов довольно затруднительно, ведь скрипт сам себя не напишет. В этой статье я хотел бы поговорить о том, как из ручного тестировщика стать крутым автотестером.

HTML код до и после работы Билайна. Найдите отличия!

Недавно я написал две статьи про оператора связи Билайн:
Билайн автоматически добавляет тулбар с поиском Mail.Ru
Билайн автоматически добавляет тулбар и изменяет дизайн сайтов

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

Теперь оператор связи меняет атрибут src у тега iframe и фреймы перестают работать!

Любой маломальски опытный QA-инженер (или в простонародье тестировщик) сможет сходу назвать пяток различных видов тестов: удобство пользователя, дымовое, нагрузочное, регрессионное, конфигурационное, тестирование взаимодействия и т.д. Какие-то виды тестирования используются редко, например нагрузочное, почаще применяется тестирование удобства пользователя, о таких экзотических видах, как конфигурационное тестирование или тестирование взаимодействия, многие вообще слышали только в книгах Канера и Фолка «Тестирование программного обеспечения» и никогда не использовали в работе. Но есть вид тестирования, про который можно сказать совершенно четко: его делал каждый. Я говорю о регрессионном функциональном тестировании. Этот вид теста, пожалуй, является одним из наиболее важных, нудных и трудоемких.

Пару месяцев назад в протоколе TLS обнаружили уязвимость, которая получила название Logjam. Проведенные исследования показали, что большое число серверов подвержено этой уязвимости, так как, применяя защищенные соединения, используют типичные и наиболее распространенные простые ключи шифрования размером 512 бит. Ранее, такой длины вполне могло хватить для защиты соединения клиента с сервером. На сегодняшний же день, проведены исследования по вычислению наиболее распространенные ключей. Host-tracker предлагает функционал, который позволяет моментально проверить данную уязвимость.

«Горячая» и часто обсуждаемая сегодня тема оптимизации конверсии привела к безусловной популяризации А/Б-тестирования, как единственного объективного способа узнать правду о работоспособности тех или иных технологий/решений, связанных с увеличением экономической эффективности для онлайн-бизнеса.

За этой популярностью скрывается практически полное отсутствие культуры в организации, проведении и анализе результатов экспериментов. В Retail Rocket мы накопили большую экспертизу в оценке экономической эффективности от систем персонализации в электронной коммерции. За два года был отстроен идеальный процесс проведения A/Б-тестов, которым мы и хотим поделиться в рамках этой статьи.

Привет Хабр! Сегодня предлагаем вашему вниманию третью часть цикла статей, посвящённого HP StormRunner Load. Предыдущие части: I и II.



В этой части поговорим про анализ результатов.

Лето только начинается, но это не повод прекращать учиться. Предлагаем вам ознакомиться с очередной порцией знаний в рамках проекта «Лекции Техносферы». Цель курса — ознакомить студентов с актуальными методологиями тестирования и обеспечения качества современных веб-приложений. Курс позволит слушателям получить достаточные знания для овладения и применения на практике эффективных приемов построения процесса тестирования и обеспечения качества.

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

Привет, Хабр! Мы стараемся поддерживать разработчиков инструментами, технологиями, информацией и вниманием. Одно из направлений нашей деятельности — программа Google Developers Launchpad, система поддержки стартапов и разработчиков приложений. Она была не так давно запущена в мире и практически сразу пришла и в Россию.

В рамках этой программы мы предоставляем различные возможности: как бизнес-услуги, PR-продвижение, так и технические вещи. Например, доступ к сервису Firebase, расширенный доступ к Google Maps API, к инструментам тестирования и тому подобное. Мы также даём возможность командам один на один пообщаться с экспертами Google, которые могут оценить дизайн и инфраструктуру приложения, посоветовать, как лучше реализовывать те или иные функции или оптимизировать приложение.

Программа перспективная и ряд российских проектов уже прошел или сейчас проходит через неё. Вместе с проектом AppTractor.ru мы отобрали шесть участников Launchpad и поговорили с ними об их работе.

Последняя пятница апреля не стала исключением для встречи сообщества любителей языка Python. В этот раз спикеры на Python Meetup поделились следующими темами:

• Grail: шаги для ваших Python-тестов
• Rest сервисы на Flask
• GUI приложение за пять минут

Видео и ссылки на презентации под катом. Приятного просмотра!

Главная цель данной статьи – помочь преодолеть страх, который возникает у тестировщиков ПО (как начинающих, так и опытных) к предстоящему интервью в связи с незнанием грядущего.

Второстепенная цель – собрать воедино основные вопросы, которые, вероятней всего, будут заданы на собеседовании. Как у начинающего тестировщика, у меня уже скопился определенный опыт подготовки к собеседованиям на данную должность, и я могу заметить, что даже специализированные QA форумы не справляются с этой целью, а может и не ставят ее перед собой вообще.

Перечень вопросов разумеется не окончательный и не претендует на образцовость, а выступает лишь своеобразным ориентиром при подготовке специалистов с тестирования ПО.

Продолжаем серию статей, посвященных HP StormRunner Load.
Первую часть вы можете почитать здесь

УПРАЖНЕНИЕ 2. Создание скрипта HP TruClient

РОЛЬ: Инженер производительности
В этом упражнении мы рассмотрим нагрузочный тест с использованием HP TruClient – агента записи, подключаемого к браузеру Firefox.

Что представляет собой HP TruClient?

HP TruClient – это передовой механизм записи, который подключается к браузеру Firefox (существует также версия TruClient для Internet Explorer, версия для Chrome находится в стадии разработки), чтобы записывать ваши действия в ходе навигации по браузеру. TruClient создает скрипт этих действий, запуск которого может быть воспроизведен несколькими виртуальными пользователями. Число таких пользователей затем может быть увеличено, чтобы создать требуемую нагрузку на сервер.
Скрипты HP TruClient отличаются от некоторых других типов скриптов, поскольку они более реалистично отражают действия пользователя браузера. Скрипт на основе API (Application Programming Interface) точно воспроизводит нагрузку на сервер, но не содержит всех тех задач, которые могут быть возложены на сервер с точки зрения человека, использующего браузер.
Преимущество скриптов TruClient заключается в том, что их гораздо проще создавать и поддерживать. Браузеры (и TruClient) автоматически выполняют корреляцию данных конкретной сессии, в то время как в скриптах HTTP/HTML она должны быть тщательно запрограммирована. Оба типа записей формируют необходимую нагрузку, однако HP TruClient создает более простую имитацию реальных пользователей и их полного взаимодействия с браузером.
Единственный недостаток, характерный для скриптов HP TruClient, связан с масштабируемостью. При воспроизведении записи API на сервере требуется очень небольшое количество ресурсов (процессора и памяти). Это означает, что на данном аппаратном обеспечении можно запустить больше таких виртуальных пользователей, чем виртуальных пользователей TruClient. Тем не менее, учитывая низкую стоимость облачных генераторов нагрузки, использование скриптов TruClient может оказаться вполне выгодным.

Добрый день!
При unit-тестировании часто сталкиваешься с необходимостью заполнять сложные объекты, чтобы возвращать их со стороны заглушек или наоборот — давать их на вход методам и тестам. Некоторые разработчики игнорируют get-set конвенции Java, а даже если геттеры и сеттеры есть, то заполнение объекта достаточно сложной структуры порой требует больше кода, чем сам тест. Это анти-паттерн Excessive Setup, и хочется научиться с ним бороться. В этой статье я расскажу, как с помощью библиотеки PODAM заполнять объекты быстро и красиво, продолжая идеи разумной рандомизации как входных данных для тестов, так и данных, возвращаемых заглушками — покажу на примерах, пороюсь в исходниках.
Итак, чтобы долго не думать, но и не заниматься миром животных, сгенерим страну.

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

Когда мы решили завести на своих сайтах онлайн-чат, мы не очень ясно понимали, какой у него должен быть функционал. Единственное, что мы сразу четко понимали: это не будет чатик, куда любой случайный посетитель сможет написать «эй, есть кто живой?». И не такой, где отвечать на сообщения посетителей будет девочка-консультант, толком не разбирающаяся в технических особенностях нашего продукта.

Сегодня мы поговорим о «низкоуровневых» кирпичиках нашего проекта — о демонах.
Хоть это и не очевидно, но практически весь функционал сайта во многом зависит от работы этих программ. Игра в “Знакомства”, поиск новых лиц, центр внимания, обмен сообщениями, статусы, геолокация и многие другие вещи завязаны на тот или иной демон. Так что можно сказать, что они помогают людям по всему миру общаться и находить новые знакомства. Одновременно на сайте могут работать и взаимодействовать между собой несколько десятков демонов. Их корректное поведение является очень важной задачей, поэтому мы решили покрывать основной функционал демонов автотестами.

В Badoo этим занимается специальный отдел. И сегодня мы расскажем о том, как у нас проходит процесс разработки этой критически важной части сайта и выполнение автотестов. Эта область достаточно специфичная и материала много, поэтому мы подготовили структурированный обзор всего процесса, чтобы разобраться в нем смогли все, кому интересно.

В качестве VCS у нас используется Git, для непрерывной интеграции — TeamCity, а в роли баг-трекера выступает JIRA. Для тестирования мы используем PHPUnit. Разработка демонов, как и остального сайта, ведется по принципу «фича ― ветка». Для того чтобы понять, что это, мы рассмотрим проекции нашего flow на Git и на JIRA.

Я провожу собеседования на тестировщиков. У меня иногда болит голова.

Долго собирался написать статью… И вот, наконец, выполнил свое намерение. Вопросы, поднимаемые в статье, обсуждались уже не раз и не два, но усердные поиски компиляции ответов на эти вопросы так и не увенчались успехом. Но, как подсказывает мой опыт, такая компиляция очень нужна. Прежде всего она требуется юниорам, ибо в сети по запросу «тестирование» на них (соискателей) обрушивается огромный объем информационного мусора, который плохо структурирован и часто противоречит сам себе.

Добрый день!

Вчера, отвечая, кажется, в шестой раз на этот вопрос, твёрдо решил, что пришло время для написания статьи. Сразу отмечу – это исключительно моё видение, с которым, уверен, добрая половина мира автоматизаторов не согласится, – мой рецепт несколько сложнее, чем «почитать про тулзу», «поставить тулзу», «использовать тулзу», «написать в резюме, что умеешь пользоваться тулзой».

Эта статья полезна не только для мануальных тестировщиков, желающих автоматизировать свои рутинные проверки, но и для бизнеса и HR-ов, которые ввиду отсутствия каких-либо общепринятых критериев, как правило, понятия не имеют кто есть QA Automation Engineer и в большинстве случаев принимают решение на основании «хороший человек».

Бывает ещё хуже – руководитель/PM/etc… приходят к своим мануальным тестировщикам и говорят: «слушай, а может мы автоматизируем наше тестирование – это сэкономит нам кучу времени и денег. Скажи, какие книги тебе нужны и какие курсы».

0. Начнём с ошибок, которые не надо допускать:

• Дайте мне книгу умную, которая всё за меня сделает
• Дайте мне курсы платные, которые всему меня научат
• Дайте мне форумы специализированные, которые ответят мне на все интересующие вопросы
• Дайте мне сертификацию полезную, с которой меня везде примут

Это всё хорошо, но лишь в дополнение к рецепту, который описан ниже. Ни в коем случае нельзя с этого начинать.

Back-end не всегда функционирует так идеально, как указано в API-спецификации. Например, кто-нибудь забывает внести обязательный параметр в JSON-строку выдачи или вместо «0» решает вписать null. Если такие данные проникают в мобильное приложение, последствия могут быть самые неприятные.
Сегодня я расскажу об инструменте, который используется для выявления таких случаев. Это Runscope.

Недавно вспомнилось мне, что есть такой сервис — StartSsl, который совершенно бесплатно раздаёт trusted сертификаты владельцам доменов для личного использования. Да и выходные попались свободные. В общем сейчас напишу, как в nginx настроить HTTPS, чтобы при проверке в SSL Labs получить рейтинг А+ и обезопасить себя от последних багов с помощью выпиливания SSL.

Итак, приступим. Будем считать, что у вы уже зарегистрировались на StartSsl, прошли персональную проверку и получили вожделенный сертификат. Для начала опубликую итоговый конфиг, а после этого разберу его.