Что пишут в блогах

Подписаться

Онлайн-тренинги

Загружаются...

Конференции


Гейзенбаг - большая техническая конференция для тестировщиков
4 июня 2017, Санкт-Петербург + online-трансляция

Разделы портала

Про инструменты

Лучшие вакансии

.
Не ручной, не автоматизатор, а неведома зверушка
02.02.2017 10:46

Автор: Виктор Славчев (Viktor Slavchev)

Оригинал статьи: http://mrslavchev.com/2017/01/09/the-non-manual-unautomated-tester/

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

Я борюсь с разделением тестирования на ручное и автоматизированное фактически с тех самых пор, как сам начал тестировать, то есть уже три года. Я неоднократно менял "стороны", возможно, разделяя ложные ожидания, которые и сейчас преследуют людей на обеих сторонах этой баррикады. В итоге я решил для себя лично, что я не буду выбирать сторону, что тестирование – это что-то выше того подхода, который мы используем, чтобы заниматься им. Иногда я разговариваю с людьми и они спрашивают меня, ручной я тестировщик или автоматизатор. Я объясняю, что я не подхожу ни под одно определение этих "сторон", и рассказываю о своем отношении к тестированию. Но частенько я подмечаю проблему.

Ручное и автоматизированное тестирование превратились из описания вакансии в способ, которым тестировщики описывают, чем занимаются.

Подробнее...
 
Wanted: Test Engineer (Automated testing)
31.01.2017 17:09

Мы – американская компания DealerSocket и один из самых успешных проектов на рынке автоиндустрии в США. 31% всех автомобилей США продаются с использованием разработанного нами программного обеспечения. У нас есть Центры Разработки в США и в России. Головной офис находится в Сан-Клементе (Калифорния). Мы создаем и обслуживаем сайты для таких компаний, как Jaguar Cars, Volkswagen Konzern, Mercedes-Benz и т.д.

Прямо сейчас нам нужен Тест Инженер в офис в Калининграде (единственный офис в России). По обязанностям – 95% автоматизация тестирования.

Наши технологии: Codeception, Selenium WebDriver, PHP, TeamCity, Vagrant, Git.

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

У нас: белая зарплата, ДМС, гибкий график, курсы английского в офисе, поездки на конференции, компенсация занятий спортом, а по воскресеньям мы играем в баскетбол.

О вакансии: https://moikrug.ru/vacancies/1000022376
О компании: http://dealersocket.com/
О Калининградском офисе: http://www.dealerfire.com/dealersocket-kaliningrad/

 
Бросьте костыли!
31.01.2017 10:57

Автор: Майкл Болтон (Michael Bolton)

Оригинал статьи: http://www.developsense.com/blog/2017/01/drop-the-crutches/

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

Эта статья – адаптация моих последних твитов. По ссылкам – ответы на некоторые из ваших вопросов. Как всегда, вопросы и комментарии приветствуются.

Дополнение: в ответ на заданные вопросы, вот что я думаю про "тест-кейсы" в контексте этой статьи: тест-кейсы – это формально структурированные, четкие, процедурные, явные, документированные тест-идеи, направленные на подтверждение известного. Мое беспокойство в этом плане прямо пропорционально уровню серьезности, с которой подходят к этим вещам в определенном кейсе или тест-стратегии

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

Мы также согласились, что тест-кейсы часто ведут к подмене целей. Вместо тщательного исследования продукта цель трансформируется в "закончить тест-кейсы". Менеджеры обычно спрашивают, как там тестирование, но имеют в виду совершенно другое. Они почти всегда подразумевают "как там дела у продукта?". Но как мне кажется, тестировщики часто интерпретируют "как там тестирование" как "закончили ли вы тест-кейсы", что еще больше смещает цель тестирования.

Конечно, вопрос "как там тестирование" – важная часть истории тестирования из трех частей, особенно если проблемы продукта не дают нам изучить его глубже. Но, как правило, это не та часть истории, с которой мы хотели бы начинать. По моему опыту как программного менеджера и как тестировщика, вот что волнует менеджера в первую очередь:

Есть ли в продукте проблемы, которые угрожают своевременному успешному завершению проекта?

Подробнее...
 
Освоение автоматизации тестирования для тех, кто не имеет опыта программирования
30.01.2017 11:37

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

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

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

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

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

Подробнее...
 
Сложность – тоже баг
26.01.2017 11:05

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробнее...
 
С чего начать внедрение автоматизации? подборка докладов с CEE SECR “Разработка ПО”
25.01.2017 12:14

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

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

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

Подробнее...
 
Должна ли автоматизация быть уделом разработчиков?
24.01.2017 12:14

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

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

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

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

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

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

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

И "нет".

Подробнее...
 
Магнит: Вакансии тестировщиков в Омске и Краснодаре
23.01.2017 18:14

«Магнит» — одна из ведущих розничных сетей по торговле продуктами питания в России, лидер по количеству магазинов и территории их размещения.

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

Вакансии тестировщиков открыты в Омске и Краснодаре. "Магнит" заинтересован как в опытных сотрудниках, так и в начинающих специалистах.

Открыты следующие вакансии:

Ведущий специалист по тестированию ПО, Краснодар

Главный специалист по автотестированию программного обеспечения, Краснодар

Специалист по тестированию программного обеспечения, Краснодар

Присоединяйтесь к команде "Магнита"!

 
Новости тестирования за январь
23.01.2017 12:24

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

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

 
Как тестировать на мобильных телефонах, не имея телефонов?
20.01.2017 11:52

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

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

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

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

Подробнее...
 
Как тестировать граничные значения результата работы ПО?
19.01.2017 14:38

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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