Стоит задача получить сертификаты по hp0-m101(hp alm).
В интернете информации очень мало.
Кто сертифицировался - поделитесь информацией по чему готовились?
Кроме юзер гайдов что еще изучали? Посещали ли курсы?
У официалов обучение стоит каких то космических денег, у сертифицированных вендоров недорого, но без гарантий. Собственно нужно даже не обучение работе с инструментом, а именно подготовка к сертификации.
В работе используем этот инструмент, но работать и сертифицироваться - разные вещи.
Все мы когда-то были новичками: в тестировании или в другой сфере – не важно. Мы одинаково спотыкались, блуждали в поисках правильного пути и далеко не всегда быстро находили решение. Порой у нас опускались руки от многократных ошибок, и в голове прочно утверждалась мысль: «Я – неудачник и все делаю не так!».
Я хорошо помню свой самый первый проект с реальными задачами, свои большие от страха глаза, когда мне поручили составление тестов. Я совершенно не знала, с чего начинать. И больше всего меня мучило не абстрактное «как это делается?», а «как это сделать правильно?».
С тех пор прошло почти три года, я многому научилась – самостоятельно и с помощью замечательных коллег, с которыми мне посчастливилось работать. А еще за все это время я успела неоднократно побывать в роли наставника новичков, которые приходили в нашу компанию, и стать одним из тренеров курса «Школа успешных тестировщиков» Натальи Руколь.
Наставничество в «Лаборатории Качества», регулярная проверка домашних заданий и мой собственный опыт на старте карьеры сформировали ряд принципов, которым я стараюсь следовать при подготовке начинающих тестировщиков.
Этот курс предназначен для обучения тестировщиков программированию на языке С# (для тех, кого интересует программирование на Java у нас есть другой курс).
Да, именно тестировщиков. Обучение программированию не сводится только к изучению языка программирования. Построение правильной архитектуры, использование фреймворков и библиотек, владение инструментами разработки и отладки -- это тоже часть “умения программировать”. Поэтому в этом курсе детально рассматриваются именно те возможности языка и вспомогательных библиотек, которые наиболее востребованы при разработке автотестов, в том числе при тестировании веб- и windows-приложений через пользовательский интерфейс.
Весь изучаемый материал будет демонстрироваться на одном сквозном примере -- мы будем разрабатывать на языке C# автоматизированные тесты для веб-приложения, используя Selenium WebDriver. Начав с простого теста, записанного “рекордером”, мы будем постепенно усложнять архитектуру тестового набора, добавлять и усиливать проверки в тестах, дополнять тесты генераторами тестовых данных. Основной акцент будет сделан не на алгоритмы, а на изучение различных полезных библиотек и фреймворков, а также шаблонов проектирования, позволяющих организовать код автоматизированных тестов таким образом, чтобы его было легко модифицировать и расширять.
У многих тестировщиков, а также и у многих менеджеров, при звуке слов "автоматизация тестирования" в мозгу возникает идиллическая картинка в стиле научно-фантастических романов: роботы выполняют рутинную и тяжёлую работу, а человек занимается интеллектуальным или творческим трудом.
Но это никакая не фантастика, это вполне реально и достижимо!
Да, можно освободить тестировщиков от выполнения некоторых типовых задач, переложив эту работу на плечи роботов. Таких рутинных действий тестировщик совершает больше, чем кажется на первый взгляд. Автоматизировать можно не только собственно выполнение тестов, но и подготовку тестового стенда, генерацию тестовых данных большого объёма или высокой сложности, помощь в проверке результатов, полученных при ручном тестировании (сравнение текстов, картинок), создание отчётов или иных документов.
Однако нельзя просто пойти и купить робота, который начнёт немедленно приносить вам пользу. Можно либо взять "универсального" робота и обучить его, либо взять конструктор и собрать узкоспециализированный автомат для решения ваших конкретных задач.
Процесс внедрения автоматизации – это как раз и есть процесс создания или обучения роботов.
Внедрение автоматизации затрагивает многие стороны процесса разработки. Это отнюдь не чисто инженерная задача, требующая только владения инструментами автоматизации и навыками программирования.
Прежде чем перейти к технической части, необходимо выбрать оптимальную стратегию внедрения и дальнейшего развития автоматизированных тестов. Нужно скоординировать работы по автоматизациями с деятельностью специалистов по ручному тестированию, потому что предстоит провести отбор тестов для автоматизации, а может быть и переработку этих тестов. Предстоит также согласовать свои действия с разработчиками, а может быть даже договориться о специальных доработках тестируемого приложения для более удобной автоматизации.
Ну и конечно без инженеров в этом деле не обойтись. Правильно выбрать средства автоматизации, интегрировать с инструментами групповой работы (баг-трекер, сервер непрерывной интеграции, системы отчётности) – при решении этих технических задач талант инженера-автоматизатора может раскрыться в полной мере.
Но главная опасность подстерегает впереди – рано или поздно станет ясно, насколько оправданным и экономически целесообразным оказалось внедрение автоматизации в тестирование. Нужно будет оценить достигнутые результаты и принять новые решения относительно дальнейшего развития систем автоматизации.
Чтобы научить вас правильно планировать процесс внедрения автоматизации, успешно решать технические задачи и адекватно оценивать текущее состояние процесса
мы разработали тренинг, особенность которого заключается в том, что его ведут два тренера – "менеджер" и "инженер".
Это позволит вам увидеть проблемы, которые возникают при внедрении автоматизации тестирования, с двух разных (можно даже сказать противоположных) точек зрения.
Тренинг будет полезен всем, кто внедряет с нуля или улучшает текущие подходы к организации автоматизированного тестирования: тест-менеджерам, специалистам по автоматизации и тест-дизайнерам, взаимодействующим с группой автоматизации.
На правах рекламы, ну а может и не рекламы. А может просто рассказ чем занимаюсь
В свободное время я участвую в отечественном проекте Strategium, это пошаговая гексагональная стратегия, с тематикой научной фантастики. Игры против ботов пока что нет, только против реальных игроков. На обдумывание хода даётся 30 часов, поэтому можно делать ходы когда удобно. Одна из игр, вдохновившая автора на создание - это шахматы, что сразу заметно в игре.
Игра находится в стадии альфа-тестирования. Недостатка в багах не бывает.
Я доброволец, деньги за тестирование не получаю. За продвижение игры тоже денег не получаю. Я верю в будущее проекта. Я играю и заодно тестирую, заношу баги. Вот тема форума где можно посмотреть какого типа бывают баги, ну и по скриншотам видно что за игра: http://www.runiwar.ru/forum/101-795-139
Дополнительная информация в разделе Дайджест в игровом клиенте.
Почему я этим занимаюсь? Это реальная стратегия, заставляющая думать, это не модные сейчас тайм-киллеры. Мне всегда было интересно тестирование видео-игр, но в этой индустрии никогда не удавалось поработать, наверное из-за низких зарплат в этой области. Я фанат таких стратегий как Цивилизация, Panzer General, шахматы. А тут совпало всё - и тестирование игр, и умная стратегия, да ещё и можно играть на мобильном! Считаю что люди должны иметь возможность играть в умные игры и развивать этим свою логику - а не просто убивать время.
Играть можно на: Android, ChromeOS и андроид эмуляторах
Хочу поделиться с вами своей историей и узнать ваше мнение на этот счет.
Итак, я работаю в компании чуть больше 2-х лет и это моя первая работа в качестве тестировщика (это я к тому что мне не с чем сравнивать). За это время никаких особых изменений в процессе не происходило, продукт разрабатывался, тестировался, баги писались и фиксились, релизы выходили практически всегда без факапов. Работы было много всегда и времени на развитие не хватало. В команде были как джуны и миддлы, так и синьеры, но ранжирование было чисто субьективным. И вот в один момент руководство решило сделать ранжирование не субъективным, а чисто объективным. Были придуманы требования на каждый ранг, которые очень сильно отличались от того, с чем сотрудники фактически работали, то есть миддл, например, должен был теперь не только мануалить, следить за документацией и джунами, а еще и автоматизировать процесс тестирования. Соответственно, если ты не умеешь автоматизировать, то пора учиться. Но объем работы никто не уменьшал, дополнительных людей не нанимал и, более того, чтобы заниматься автоматизацией нужно "выбивать" на это время. Хотя менеджмент очень неохотно идет на такие уступки и утверждает, что сотрудники должны обучаться автоматизации в свое личное время.
Если в двух словах, то с точки зрения менеджмента процесс должен выглядеть так - продолжайте выполнять те же задачи, а дома обучайтесь автоматизации и потом "выбивайте" время на ее развитие в компании.
Что вы думаете по поводу такой организации процесса обучения? Как налажен этот процесс в вашей компании (компаниях, в которых вы работали ранее)?
Очень хочется услышать людей с большим опытом работы в разных компаниях.
Те, кто посмотрят мои публикации, увидят очень странные вопросы с моей стороны и очень хорошие ответы со стороны комментаторов.
В компании, которой я работаю, использовали webforms и Web UI Telerik для написания менеджера по управлению продуктом(сервером и клиентами нижнего уровня). К добавок к этому использовали структуру из фреймсетов и фреймов для реализации web морды.
Об автоматизации тестирования на момент создания сиего чуда природы некто не задумывался, поэтому написали не очень удобное приложение с точки зрения написания UI тестов.
Следовательно прибавив к этому IIS Microsoft и самописный сервер( на WCF) для обработки запросов(не прошедший оптимизацию скорости работы и траты ресурсов) наша компания получила довольно таки громоздкую, прожорливую систему.
Я думаю многие опытные тестеры догадаются о подводных камнях, которые мешают написанию UI тестов. А именно это скорость работы, то есть ожидания(Wait) и все что с ними связано.
Я столкнулся с проблемой того что время транзакций по времени между IIS и самописным сервером(даже при выполнение тестов в UnitHTML) не являются постоянными и выполняются с очень большим разбросом времени( от 5 до 180 сек).
Это ужасно, так как перед запуском тестов я использую xml файл для конфигурирования браузера(в том числе и UnitHTML). В этом файле указываются все необходимые настройки плюс Wait-ы.
Тест зачастую валились из за истечения времени. Я долго боролся с этой проблемой пытаясь ее решить изящным способом. В результате опустился до рекурсии
public IList<IWebElement> FindToSetSystemParametersForSearch()
{
try
{
new WebDriverWait(driver, TimeSpan.FromSeconds(60)).Until(ExpectedConditions.ElementIsVisible(By.XPath("XPath")));
return this.driver.FindElements(By.XPath("XPath"));
}
catch (WebDriverTimeoutException e)
{
return FindToSetSystemParametersForSearch();
}
}
Такое решение работает, и мне за такое надо по отрывать руки, так как это решение в корне не правильною Я это понял когда пришел утром и увидел что выполнение тестов зависло, чего и следовало ожидать.
Настала пора еще одного такого вопроса:
Кто то может что то подсказать по решению этой проблемы?
Имеются две переменные, которые надо завести как переменные Regular Expression Extractor, помогите указать поля Regular Expression и Template. (регулярные выражения)
Вот примеры значения,которые принимают переменные: