На сегодняшний день многие проекты, имеющие сложную разнообразную функциональность, характеризуются очень короткими промежутками между релизами. В таких случаях приходится часто выполнять большое количество повторяющихся проверок (регрессионных тестов). Возможно, этот факт и является главной (хотя и не единственной) движущей силой активного развития автоматизации тестирования. Все больше компаний в сфере IT принимают решение оптимизировать процесс тестирования, сократив затратные по времени и финансам действия.
При этом автоматизация является довольно молодым направлением. Опытных специалистов, владеющих соответствующими навыками, как правило, не хватает. Зачастую встает задача подготовить таких специалистов самостоятельно внутри компании в разумные сроки. Однако, освоение автоматизации предъявляет высокие требования к технической подготовленности тестировщика, так как от него требуется читать и писать программный код, редактировать конфигурационные файлы, читать логи и т. д. В этой статье речь как раз пойдет о том, какие именно шаги можно предпринять для достижения нужного уровня технической подготовленности такого специалиста.
Мне пришлось осваивать автоматизацию «с нуля», т. е. не имея академического образования в сфере IT, навыков программирования и практики работы в смежных «технических» направлениях (например, в системном администрировании). Теперь, уже имея опыт написания тестов на двух языках программирования (Python и Java) и продолжая совершенствоваться в сфере автоматизации, я дам рекомендации, как приобрести нужные знания и опыт.
В прошлом месяце я участвовал в конференции DevOps в Тель-Авиве. Я делал заметки об интересных вещах, про которые рассказывали люди – как и многие на конференции – и затем убрал блокнот – как делают, опять же, многие после конференции.
Вчера, просматривая блокнот (вроде бы я хотел посмотреть, что мне еще нужно сделать из моих бесконечных списков "надо сделать"), и наткнулся на заметки с конференции. Среди рисунков и почеркушек было предложение, за которое я зацепился взглядом. Я написал его и затем позабыл, но когда вновь увидел его, оно снова привлекло мое внимание.
Вот что там было написано:
Сложность – это тоже баг. Сложность повышается и будет продолжать повышаться.
Под этим предложением были заметки о презентации этого спикера.
Он был основателем/программистом/гиком/директором из Силиконовой Долины, и он рассказывал, как, с его точки зрения, повышается сложность программных продуктов, и как она будет повышаться в будущем.
Суть его речи сводилась к тому, что компании, занимающиеся разработкой ПО, должны выбрать, кто будет справляться с этой сложностью. Он смотрел на это с точки зрения DevOps, и поэтому сказал, что варианта тут три – разработка, IT или конечные пользователи.
Проще говоря, приложения должны делать больше: разговаривать с другими приложениями, чтобы что-то сделать, делать это быстрее, делать это в разнообразных окружениях. Мы делаем все больше и больше (не считая сна и отдыха, которых у нас все меньше и меньше).
Так вот обстоят дела, и кто-то должен "заплатить штраф" за эту повышающуюся сложность, а этот штраф может понести только одна из трех вышеперечисленных сторон.
Справляться со сложностью можно в качестве части процесса разработки, создавая более сложные алгоритмы и хитрые коды, чтобы управляться с повышающейся сложностью.
Частично эта задача может лечь на IT, деплоящим и настраивающим систему так, чтобы она могла справляться с повышенной сложностью.
И, наконец, все то, с чем не справились два предыдущих кандидата, уходит к конечным пользователям, которым надо разбираться с более сложными процессами установки и настройки, и менее дружелюбными приложениями.
В конце презентации он объяснил, что сложность – это игра с нулевой суммой, и в процесс разработки ПО должно входить решение, кто будет справляться со сложностью.
Если вы задумались над внедрением автоматизации, вам стоит обратить внимание на записи выступлений с конференции CEE SECR “Разработка ПО”. В своих докладах специалисты рассказали о том, почему такая необходимость возникла на их на проектах, с чего они начинали процесс автоматизированного тестирования, а также о применяемых в работе инструментах.
Разработка системы автоматизированного тестирования при помощи фреймворка Protractor для web-приложений
Становление процесса автоматизированного тестирования в интернет-магазине ОКЕЙ
Лично я не разработчик, я получал образование по информатике, знаю пару вещей о том, как пишется код, но я абсолютно, совершенно точно не разработчик. Это как знать, как готовится еда, но не быть поваром. Люди, которые встречали меня лично, возможно, помнят эту аналогию, которой я, возможно, им до смерти наскучил (простите меня!).
С другой стороны, я постоянно талдычу, что автоматизация тестирования – это разработка ПО, и должна восприниматься как таковая. Так что же, спросите вы, как так случилось, что я работаю в автоматизации тестирования, но не считаю себя разработчиком? И, что еще более важно, разве автоматизация тестирования не должна быть уделом разработчиков, если это действительно область разработки ПО? Недавние статьи и презентации, которые я видел, заставили меня об этом задуматься.
Начнем с второго, более важного вопроса: должна ли автоматизация быть уделом разработчиков?
Мобильные телефоны вошли в нашу жизнь повсеместно, и распоследний захудалый сервис имеет собстственное приложение. Да даже если не имеет – значит, у их сайта отзывчивый дизайн и его можно использовать при плохой связи, а не только на большом экране с оптоволоконным соединением. Как тестировщик сайтов или приложений на Андроид/Айфоне/ВинФоне, вы должны изобразить из себя реального пользователя – то есть иметь один или несколько смартфонов, как минимум тот, которым чаще всего пользуются ваши потребители. Не забываем и о ручном, и об автоматизированном тестировании. Вдруг у вас нет миллиарда евро, долларов или фунтов на покупку всех возможных смартфонов для тестирования? Будете ли вы полагаться на инструменты разработчика Chrome для браузера, зная, что разработчики и так "по-быстренькому" протестили с их помощью свою работу?
Базовые техники тест-анализа, такие как “классы эквивалентности” или “граничные значения” каждый тестировщик понимает интуитивно, даже если никогда и не читал теорию данных методик. Поэтому, когда мы рассказываем о них на курсе Школы Тест-Аналитиков, многие участники считают, что это очевидно. Совершенно ясно, что нужно взять хоть одно значение параметра из каждого диапазона и лучше подробнее проверить границы.
Но что, если диапазон и границы заданы не для параметра, а для итога работы программы?
Вот реальные примеры:
Дата окончания договора рассчитывается автоматически от даты заключения с добавлением продолжительности договора. Но в зависимости от года окончания договора он хранится в разных хранилищах и имеет разные условия расторжения.
Программа обработки изображений позволяет изменить качество и размер изображения, но если у выходного изображения размер будет больше 3 MB или произведение сторон будет больше 16 мегапикселей, то получить изображение можно будет только через внешнюю ссылку на хранилище.
Назначенные в таск-трекере на одного человека задачи не должны превышать 8 часов за сутки ( или уж хотя бы 24 часа за сутки, так и быть!)
То есть границы у нас есть на результат, а для тестирования-то мы указываем значения только тех параметров, которые мы можем впрямую задать программе. Вот тут даже наши ученики начинают спотыкаться!
Как получить оптимальное покрытие тестами продукта, учитывая границы результата работы ПО или границы промежуточных результатов?
Чтобы не упустить ничего важного в этом случае нужно:
провести анализ на выявление таких границ у результатов работы
продумать какие наборы значений параметров могут дать нам проверку нужных границ
при использовании стандартных техник составления тестов ( например, Pairwise, доменный анализ) сразу выполнить коррекцию данных так, чтобы минимальным числом тестовых наборов тем не менее покрыть как границы самих параметров, так и границы результатов работы.
На словах звучит несложно, но когда в курсе Школы Тест-Аналитиков ученики делают это всё первый раз на реальном продукте, подводных камней оказывается много. Именно эту домашку некоторые участники переделывали более 10 раз! Зато потом остаётся “ощущение, что у меня был сломан мозг, а мне его вправили!” (со слов Гильмановой Элины, выпускницы нашего тренинга).
Если вы хотите проверить на себе, так это или нет, мы будем рады видеть вас в списке участников очередной группы курса Школы Тест-Аналитиков, которая начнет работу 25 января.
Перед самым новым годом создатели печатного издания Tester’s Life подготовили 4 номера журнала в формате .epub (адаптивный) для публикации на bookmate, для просмотра на Apple ibooks и ведущих ридерах на ОС android.
Если до сего дня вы не успели ознакомиться с этими номерами в печатном виде, можно сделать это сейчас, не откладывая в долгий ящик. Издания в электронном формате вы найдете здесь.
При тестировании Android-приложений можно часто столкнуться с проблемами, возникающими при переходе приложения из одного состояния в другое. Так, например, нередки утечки памяти при сворачивании и разворачивании приложения, или краши после ухода телефона в спящий режим.
Конечно, такие баги так или иначе находятся, даже если их не искать специально. Однако для обеспечения действительно высокого качества тестируемых приложений нужно чётко осознавать, почему подобные ошибки возникают, и как их искать. А для этого необходимо понимать, как происходит процесс изменения состояний в Android.
Android-программистам эта тема хорошо известна под названием Android Activity Lifecycle, или жизненный цикл операции. Конечно, тестировщикам, даже продвинутым, вовсе необязательно разбираться в данном вопросе полностью, однако базовое его понимание может сильно упростить жизнь и ускорить тестирование. Для того, чтобы показать, как это работает, мы записали небольшое видео.
Если бы я не был фанатом шопинга через сеть ранее, я стал бы им несколько лет назад, стоя в очереди в большом универсальном магазине в час пик леденящей Черной Пятницы в районе западных гор. Мы с женой прибыли незадолго до полуночи, чтобы избежать основной толпы у дверей, уверенные, что то, что нам нужно, еще будет в магазине.
Этого не было.
В попытке оправдать ночное стояние у дверей, лед, снег и агрессивных водителей по дороге к магазину, мы купили пару дешевых детских пижам, уродливые носки, и куклу в помятой коробке. С нашим грузом мы проследовали в конец магазина и встали в бесконечную очередь ожидать расплаты за покупки, которые мы на самом деле не хотели совершать.
Мы ждали час или два, и я понял, что я прекрасно мог воспользоваться онлайн-магазином через свой Android-телефон. Еще до того, как мы дошли до кассы, я заказал все, что нам было изначально нужно. На будущий год я провел Черную Пятницу, завернувшись в одеяло, с кружкой горячего шоколада в одной руке и ноутбуком в другой. Мои ожидания насчет опыта работы онлайн постоянно растут.
Ожидания от онлайн-опыта постоянно растут
Вспоминая этот опыт, я понимаю, что опыт покупок онлайн был очевидно лучше, нежели физически в магазине, но он не был идеален. Сайт не был оптимизирован для мобильных телефонов, и несколько раз мне приходилось начинать все сначала, потому что сайт выдавал мне ошибку.
Сегодняшние потребители, конечно, чувствуют себя намного лучше, когда делают покупки онлайн – сайты чисты от лишней информации, в них легко ориентироваться, и они оптимизированы под мобильные устройства. Если ожидания не оправдываются, то найти сайт, который их оправдает, займет всего несколько кликов мыши. Это особенно верно в праздники, когда покупатель не любит ждать и ожидает, что все будет работать как следует.
Мы, как разработчики, дизайнеры и тестировщики, обязаны как профессионалы предоставлять нашим пользователям наилучший возможный опыт, когда они взаимодействуют с нашим онлайн-представительством. Если мы не можем этого добиться, особенно во времена высокого трафика (например, в праздники) – это неизбежно выльется в отток потребителей и повлияет на доходы компании.
очень маленькое (0,00000000000000000000000000001);
...
Тестировщики кивают головами и говорят — «Все понятно!». А потом им предлагают строковое поле и все, ступор о_О
Что вводить в строку? Символы русские, английские, спецсимволы, циферки, перемешал — готово! Но так и робот может проверить, тестировщик то зачем?)) И как вы отловите баги, когда имя “Иван” считается некорректным, потому что распространенное? (А такое бывает — пруфлинк, поиск по «Иванов Иван Иванович»)
Тренер Ольга Назина подготовила пример тестирования поля «Имя» для своих студентов — смотрите и вдохновляйтесь! :) Столько уникальных для поля тестов, а ведь казалось бы, простая строка...
Это выдержка из лекции про классы эквивалентности курса «Техники и инструменты поиска и оформления дефектов». Без знания о классах эквивалентности и граничных значениях никуда, особенно при поиске багов. Поэтому мы сделали отдельную тему для отработки навыка. Приходите, будет интересно :)
Автор: Джоэл Монтвелиски (Joel Montvelisky)
Оригинал статьи: 
Оригинал статьи: 
