Что подталкивает нас к организации обучения? В первую очередь — потребность в качественном улучшении работы и повышении квалификации сотрудников. Как правило, и сами сотрудники заинтересованы в том, чтобы развиваться. Нередко, правда, выясняется, что человек не знает, куда. Он просто хочет расти, но не понимает, какой ему нужен рост — «горизонтальный» или «вертикальный».
На выходе бизнес, в первую очередь, хочет получить квалифицированных сотрудников — «спецназовцев» от мира тестирования. С какими проблемами мы сталкиваемся?
Класс, в котором описаны мои тестовые методы - наследуется от TestBase.
Буквально 2 часа назад IDEA перестала обновлять файл лога (log4j) и перестала делать скриншоты + через какое-то время поругалась на нехватку PermGen Space (изменила значение, перезапустилась). Просто место на диске - также чистила (хотя его и так достаточно).
Единственное, что я за это время изменила в базовом методе - добавила вывод в консуль сообщения в самом начале метода с аннотацией @AfterMethod, чтобы понять выполняется ли он в принципе.
Метод не вызывается вообще.
При том, что в итоговом классе - тоже аннотации TestNG, которые прекрасно работают (сами тесты запускаются и работают).
Тесты запускаю через запуск "группы", т.к. из кучи тестов мне надо было запустить лишь несколько "упавших ранее".
Пробовала перезапустить IDEA (и компьютер в целом), пробовала перекопмилить TestBase (в список файлов, которые не надо компилить он НЕ входит).
"Лог" заработал, просто обновляется не сразу.
@AfterMethod / @BeforeMethod и т.п. из базового класса по-прежнему игнорируются.
И оправданный ли это подход. Дело в том, что я хотел бы все тесты написать на JavaScript с библиотекой webdriver, а в UFT эти тесты запускать как внешние.
Дело в том, что отказаться от UFT Не могу, в договоре с заказчиками прописано данное условие.
Недавно в компании был открыт новый проект по разработке некого веб-приложения ("суперумного" интернет-магазина). Первые два этапа планируется выполнить в течение двух лет. Пока делается прототип, выполнено буквально две его сырые странички с фиксированными элементами управления на них. Этап архитектуры еще не завершен.
Соответственно меня поставили тестировщиком на этот проект.
На днях РП озадачил меня тем, что необходимо начать автоматизацию, т.к. проект длительный.
Я просто в шоке, т.к. прежде занималась только ручным тестированием (но очень даже неплохо, предыдущие проекты отличались минимальным количеством багов, найденных заказчиком). А так я даже языков программирования не знаю. За исключением Cи, с которых работала 4 года назад и ничего уже не помню.
В связи с необходимостью автоматизации, куча вопросов:
Как вы считаете, реально ли ручному тестировщику стать автоматизатором и сколько на это времени необходимо?
На какие инструменты стоит обратить внимание начинающему?
Стоит ли браться за такую задачу ручному тестировщику?
Также а стоит ли начинать автоматизацию на столь ранних этапах? у меня вот в голове живет стереотип, что автоматизированные тесты нужны прежде всего для регрессии и к ним приходят, когда проект уже достаточно зрел.
Короче, дела мои плохи. У нас в конторе всего один практикующийся автоматизатор и вряд ли его захотят подключить к моему обучению или к проекту(
В марте прошла конференция для уральских разработчиков, на которой одна из секций была посвящена тестированию. Чтобы расшевелить слушателей и вывести на диалог как можно больше людей, мы устроили выступление, на котором задавали вопросы участникам. Знакомство с тестировщиками, вопросы, интересующие местное сообщество, вполне ожидаемые ответы. С одним лишь исключением. Накануне эти же вопросы были заданы участнику коммьюнити с другого края света, признанному специалисту в области тестирования — Джеймсу Баху. Надо признать, это не только подогрело интерес аудитории, но и помогло взглянуть по-новому на некоторые привычные вещи в тестировании.
Представляю вашему вниманию текст и видеозапись интервью с Джеймсом Бахом.
Представительство американской компании с центральным офисом в Сан- Франциско и отделом разработки в Минске. Направление деятельности: собственные продукты. Разработка облачных сервисов, решающих проблему надежного и безопасного хранения электронных копий легальных документов, а также передачи их между организациями. Основной продукт компании распространяется по модели SAAS и ориентирован на сектор ипотечного кредитования. Сегодня сервисы компании используют три из десяти крупнейших банков США.
Проектов много - они небольшие и идут один за один или параллельно в рамках разработки одного продукта для американского ипотечного бизнеса.
Желательно, чтобы человек в ближайшей перспективе стал самостоятельным тестировщиком и мог полностью вести небольшие проекты, начиная с анализа и проработки требований, составления тестовой документации, тестирования, и заканчивая выпуском релиза в продакшн.
Требования:
·Опыт работы специалистом по тестированию от 2 лет
·Понимание процедурного программирования, понятие алгоритмов, знание скриптовых языков
·Желательно знание ООП
·Приветствуется наличие опыта разработки фреймворков
·Английский язык: Intermediate
·Проактивность, нацеленность на результат
·Законченное высшее образование
Обязанности:
·разработка, запуск, поддержка авто-тестов (JS) (желательно)
·участие в разработке фреймворка автоматизации (web - технология еще не выбрана, desktop: qt, js, java, xml).
Будет плюсом опыт написания авто-тестов под flash приложения.
Компания предлагает:
·Участие в разработке инновационных программных продуктов мирового уровня.
·Погружение в IT-бизнес США.
·Личностный рост.
·Профессиональный рост.
·Уникальная организация и атмосфера. Вы будете работать в небольшой тесно сплоченной компании с офисами, расположенными на трех континентах, в атмосфере доверия и уважения. Вы научитесь самостоятельно управлять своим временем и целями в условиях плоской организационной структуры.
·Отличная материальная компенсация с понятными перспективами её дальнейшего улучшения.
По всем вопросам пишите на почту: epesikova@itjob.by
При тестировании люого функционала мобильного приложения нужно ли проганять тесты как на портретном режиме так и на ландшафтном, если на одном из них проверил? В смысле логику работы проверять есть смысл в обоих режимах? Например, тестируем форму регистрации в портретном режиме. Нужно ли все те же тесты проводить в ландшафтном или можно просто проверить не нарушилась ли разметка и все ли поля на месте? просто где-то слышал или читал, что эти режими - это два "разных" приложения