Поделитесь, пожалуйста, своими мыслями насчет инструмента для автоматизации тестирования в проекте.
Входные данные:
Есть большое веб-приложение, которое живет уже около трех лет, и все еще продолжает обрастать новыми фичами. Написан проект на java + java script для UI + postgres.
Есть три человека, которые хотят развиваться в направлении автоматизации тестирования, уровень знаний у всех - "новичок". Один человек пишет сейчас автотесты на python для backend, и еще двое время от времени пишут автотесты для UI на java + selenium + testNG.
Я сам - один из тех, кто пишет на java. Недавно в проекте началось движение в сторону более глубокого внедрения автоматизации. Возник вопрос - какой инструмент для этого выбрать? Вопрос был назначен на меня, плюс поступило предложение присмотреться к такому инструменту, как Squish.
Почитав немного про Squish, я как-то не нашел его привлекательным, так как какой-либо более-менее исчерпывающей информации даже на английском языке, я не нашел, а на русском языке - так вообще можно сказать ничего про него нет.
С моей точки зрения при текущих обстоятельствах надо продолжать автоматизировать на python + java, т.е. часть тестов будет на python, часть на java. Возможно, как-то разделить их, например, на python - backend, на java - UI.
Кто какие мысли может высказать по этому поводу?
Какой инструмент для тестирования на Ваш взгляд наиболее подходящий?
Что Вы можете сказать про Squish?
Как Вы смотрите на то, что в одном проекте для автоматизации будет использоваться два языка программирования (python + java)?
Если кто-то еще случайно не познакомился с творчеством Призрака aka Ленского, то крайне рекомендую цикл "Бета-тестеры". Я этот цикл регулярно перечитываю. Приятные рассказы, да и советы по профессии проскакивают интересные. Например:
Да и вообще, когда речь идет о «защите от игрока», у события может быть лишь две вероятностные оценки: «возможно» и «невозможно». Никаких «очень сложно», или «кому это надо», или «обломаются», или даже «ни один дурак на такое не пойдет».
Во многом этот цикл вдохновлял меня на цикл "Байки для оруженосца".
Когда я только начинал тестировать, моя должность обозначалась как "Тестировщик". С тех пор прошло много лет, и я побывал как тестировщиком, так и QA-специалистом. Моя предыдущая должность называлась "Старший QA-аналитик", а нынешняя – "Старший инженер по тестированию". В официальных коммуникациях я всегда использую точное название своей должности, но вне их я представляюсь как тестировщик. Я горжусь этим званием и тем, что оно для меня значит. Уже долгое время я протестую против "QA-специалиста", потому что это название кажется мне глуповатым. К сожалению, его популярность растет. К еще большему сожалению, мне кажется, что люди, представляющиеся как QA, ставят QA выше и главнее тестирования. Проблема в том, что когда они описывают, что же такое "обеспечение качества", они на самом деле говорят о добросовестном, компетентном тестировании.
Тест-менеджмент – это наука, содержащая множество формальных моделей, техник и подходов.
Тест-менеджмент – это искусство, опирающееся на особенности каждого конкретного организатора.
Эффективный процесс тестирования возможен только на стыке науки и искусства. Поэтому, в этом курсе собраны все ключевые техники и модели, но оставлено место для творчества и поиска вашего уникального процесса тестирования.
Для кого этот курс?
Этот курс создан для ведущих тестировщиков и руководителей тест-команд. Если вы отвечаете за организацию тестирования на проекте, то этот курс – именно то, что поможет вам достичь максимального результата.
Все домашние работы выполняются на примере вашего рабочего проекта. Если у вас такового нет, то мы можем предложить вам взять наш проект с группой тестировщиков. Наши специалисты помогут вам набрать команду, подобрать инструментарий и проконтролировать ход тестирования проекта. Таким образом, вы сможете закрепить на практике полученные знания и получить практическую пользу от курса, даже если у вас пока что нет своей команды.
Помимо участия в проекте по тестированию, от вас так же потребуется достаточно времени на обучение: в среднем, это 4-6 часов в неделю, но при небольшом опыте в тестировании может быть и больше. Если в данный момент ваша рабочая загрузка слишком высокая, мы советуем отложить обучение до того светлого будущего, когда у вас появится достаточно времени.
Планирую обновление Jenkins’a c 1.6 на 2.6 и один из пунктов плана апгрейда: “Составить тест-план обновления Jenkins’a”. В данный план пока что попали следующие пункты:
1) Проверить, что работают все основные тестовые джобы, которые гоняют UI и API тесты на разных стендах
2) Убедиться, что работают все обновленные плагины
3) Проверить специфичные джобы, которые редко используются, но всё же должны работать
Указывал пункты в порядке убывания по важности. Есть ли какие-то еще пункты, которые нужно добавить и протестировать после обновления на новую версию? Даже если они кажутся вам банальными и из разряда “капитан очевидность”, всё равно назовите, вдруг я про них забыл. Да и не верю я, что тест-план по тестированию Jenkins'a после обновления с 1.6 на 2.6 версию может состоять из 3 пунктов.
В конце мая в Самаре прошел очередной ITsubbotnik EPAM, который собрал 240 участников. Это конференция для опытных специалистов, на которой эксперты ЕРАМ рассказывают об основных трендах, проблемах и их решениях в разработке и тестировании ПО.