Home

Автор: Андрей Шальнев

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

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

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

Мне пришлось осваивать автоматизацию «с нуля», т. е. не имея академического образования в сфере IT, навыков программирования и практики работы в смежных «технических» направлениях (например, в системном администрировании). Теперь, уже имея опыт написания тестов на двух языках программирования (Python и Java) и продолжая совершенствоваться в сфере автоматизации, я дам рекомендации, как приобрести нужные знания и опыт.

Автор: Джоэл Монтвелиски (Joel Montvelisky)

Оригинал статьи: http://qablog.practitest.com/complexity-also-a-bug/

Перевод: Ольга Алифанова

В прошлом месяце я участвовал в конференции DevOps в Тель-Авиве. Я делал заметки об интересных вещах, про которые рассказывали люди – как и многие на конференции – и затем убрал блокнот – как делают, опять же, многие после конференции.

Вчера, просматривая блокнот (вроде бы я хотел посмотреть, что мне еще нужно сделать из моих бесконечных списков "надо сделать"), и наткнулся на заметки с конференции. Среди рисунков и почеркушек было предложение, за которое я зацепился взглядом. Я написал его и затем позабыл, но когда вновь увидел его, оно снова привлекло мое внимание.

Вот что там было написано:

Сложность – это тоже баг. Сложность повышается и будет продолжать повышаться.

Под этим предложением были заметки о презентации этого спикера.

Он был основателем/программистом/гиком/директором из Силиконовой Долины, и он рассказывал, как, с его точки зрения, повышается сложность программных продуктов, и как она будет повышаться в будущем.

Суть его речи сводилась к тому, что компании, занимающиеся разработкой ПО, должны выбрать, кто будет справляться с этой сложностью. Он смотрел на это с точки зрения DevOps, и поэтому сказал, что варианта тут три – разработка, IT или конечные пользователи.

Проще говоря, приложения должны делать больше: разговаривать с другими приложениями, чтобы что-то сделать, делать это быстрее, делать это в разнообразных окружениях. Мы делаем все больше и больше (не считая сна и отдыха, которых у нас все меньше и меньше).

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

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

Частично эта задача может лечь на IT, деплоящим и настраивающим систему так, чтобы она могла справляться с повышенной сложностью.

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

В конце презентации он объяснил, что сложность – это игра с нулевой суммой, и в процесс разработки ПО должно входить решение, кто будет справляться со сложностью.

Если вы задумались над внедрением автоматизации, вам стоит обратить внимание на записи выступлений с конференции CEE SECR “Разработка ПО”. В своих докладах специалисты рассказали о том, почему такая необходимость возникла на их на проектах, с чего они начинали процесс автоматизированного тестирования, а также о применяемых в работе инструментах.

Разработка системы автоматизированного тестирования при помощи фреймворка Protractor для web-приложений

Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ

Оригинал статьи: http://www.ontestautomation.com/should-test-automation-be-left-to-developers/

Автор: Баз Дийкстра (Bas Dijkstra)

Перевод: Ольга Алифанова

Лично я не разработчик, я получал образование по информатике, знаю пару вещей о том, как пишется код, но я абсолютно, совершенно точно не разработчик. Это как знать, как готовится еда, но не быть поваром. Люди, которые встречали меня лично, возможно, помнят эту аналогию, которой я, возможно, им до смерти наскучил (простите меня!).

С другой стороны, я постоянно талдычу, что автоматизация тестирования – это разработка ПО, и должна восприниматься как таковая. Так что же, спросите вы, как так случилось, что я работаю в автоматизации тестирования, но не считаю себя разработчиком? И, что еще более важно, разве автоматизация тестирования не должна быть уделом разработчиков, если это действительно область разработки ПО? Недавние статьи и презентации, которые я видел, заставили меня об этом задуматься.

Начнем с второго, более важного вопроса: должна ли автоматизация быть уделом разработчиков?

Я бы ответил "да".

И "нет".

Вышел выпуск рассылки за первую половину января, его содержание доступно по ссылке.

Как всегда в выпуске рассылки собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Оригинал статьи: https://www.lyontesting.fr/en/how-to-test-on-smartphones-without-smartphones/

Автор: Стефан Колсон (Stephane Colson)

Перевод: Ольга Алифанова

Мобильные телефоны вошли в нашу жизнь повсеместно, и распоследний захудалый сервис имеет собстственное приложение. Да даже если не имеет – значит, у их сайта отзывчивый дизайн и его можно использовать при плохой связи, а не только на большом экране с оптоволоконным соединением. Как тестировщик сайтов или приложений на Андроид/Айфоне/ВинФоне, вы должны изобразить из себя реального пользователя – то есть иметь один или несколько смартфонов, как минимум тот, которым чаще всего пользуются ваши потребители. Не забываем и о ручном, и об автоматизированном тестировании. Вдруг у вас нет миллиарда евро, долларов или фунтов на покупку всех возможных смартфонов для тестирования? Будете ли вы полагаться на инструменты разработчика Chrome для браузера, зная, что разработчики и так "по-быстренькому" протестили с их помощью свою работу?

Базовые техники тест-анализа, такие как “классы эквивалентности” или “граничные значения” каждый тестировщик понимает интуитивно, даже если никогда и не читал теорию данных методик. Поэтому, когда мы рассказываем о них на курсе Школы Тест-Аналитиков, многие участники считают, что это очевидно. Совершенно ясно, что нужно взять хоть одно значение параметра из каждого диапазона и лучше подробнее проверить границы.

Но что, если диапазон и границы заданы не для параметра, а для итога работы программы?

Вот реальные примеры:

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

• Программа обработки изображений позволяет изменить качество и размер изображения, но если у выходного изображения размер будет больше 3 MB или произведение сторон будет больше 16 мегапикселей, то получить изображение можно будет только через внешнюю ссылку на хранилище.

• Назначенные в таск-трекере на одного человека задачи не должны превышать 8 часов за сутки ( или уж хотя бы 24 часа за сутки, так и быть!)

То есть границы у нас есть на результат, а  для тестирования-то мы указываем значения только тех параметров, которые мы можем впрямую задать программе. Вот тут даже наши ученики начинают спотыкаться!

Как получить оптимальное покрытие тестами продукта, учитывая границы результата работы ПО или границы промежуточных результатов?

Чтобы не упустить ничего важного в этом случае нужно:

1. провести анализ на выявление таких границ у результатов работы

2. продумать какие наборы значений параметров могут дать нам проверку нужных границ

3. при использовании стандартных техник составления тестов ( например, Pairwise, доменный анализ) сразу выполнить коррекцию данных так, чтобы минимальным числом тестовых наборов тем не менее покрыть как границы самих параметров, так и границы результатов работы.

На словах звучит несложно, но когда  в курсе  Школы Тест-Аналитиков ученики делают это всё первый раз на реальном продукте, подводных камней оказывается много. Именно эту домашку некоторые участники переделывали более 10 раз! Зато потом остаётся “ощущение, что у меня был сломан мозг, а мне его вправили!”  (со слов Гильмановой Элины, выпускницы нашего тренинга).

Если вы хотите проверить на себе, так это или нет,  мы будем рады видеть вас в списке участников очередной группы курса  Школы Тест-Аналитиков, которая начнет работу 25 января.

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

Перед самым новым годом создатели  печатного издания Tester’s Life подготовили 4 номера журнала в формате .epub (адаптивный) для публикации на bookmate, для просмотра на Apple ibooks и ведущих ридерах на ОС android.

Если до сего дня вы не успели ознакомиться с этими номерами в печатном виде, можно сделать это сейчас, не откладывая в долгий ящик. Издания в электронном формате вы найдете здесь.