Ну если тестировщик не создает багов — то это плохой тестировщик.
Баги есть всегда, вот выявлять большинство из них — в этом и есть работа тестировщика. Предотвращать их появление — это уже работа QA.
Главное уметь находить правильный сценарий воспроизведения, а баг репорты можно писать по шаблону, в этом, на мой взгляд, нет ничего сложного.
Спасибо за ответы, под третьим пунктом имелись ввиду печатные формы, а именно библиотеки для сравнения выгружаемых файлов с шаблонами печатных форм. Например PDFutil или подобные инструменты.
Добрый день, спасибо за статью, очень содержательно. Особенно удивили и порадовали масштабы проекта.
Вопрос по мониторингу, как-то отслеживаете тенденции по отчетам автотестов за длительный промежуток времени?
И по разбору ошибок, есть ли какая то интеграция с баг-трекерами и TMS-системами? И в среднем сколько уходит времени на разбор и документацию результатов?
И самый последний вопрос — дополнительно какими инструментами пользуетесь для проверки соответствия выгружаемых ПФ шаблонам?
Спасибо за статью.
У меня есть пара вопросов по статье и по организации работы:
1. Подскажите пожалуйста в статье не упоминания о unit тестах, как и в каком объеме они у вас используются, и влияют ли на конечное количество сценариев UI и API тестов?
2. Очень интересно какие вы используете среды запуска тестов, например тестирование в облаке, тестирование в докер контейнерах. Как при этом выглядит кроссплатформенное и кроссбраузерное тестирование?
3. Вы писали «Для автоматизации SDET инженеры выбирают ключевые, часто используемые сценарии работы пользователя с продуктом» — можете подсказать, на основе чего идет выбор сценариев для автоматизации, берутся частые баги из трекера, берутся строгие сценарии из документации, либо происходит еще какое-то внутреннее согласование с аналитиками проекта/ручными тестировщиками?
Спасибо за статью, добавил в избранное.
Очень жду вторую часть с техническими аспектами, особенно про сравнение файлов и интеграцию с ELK.
Также хотелось бы узнать технологии и фреймворки(помимо тех, которые называли), которые используются на проекте.
Михаил, спасибо за ответы и за статью.
В любом случае в последнее время редко выкладывают что то действительно полезное по тестированию. А этот подход хоть и спорный, но интересный и его можно развивать.
Подскажите куда можно устроиться руководителем отдела тестирования с такими навыками?
Postman знаю, Excel тоже…
Мне честно говоря кажется, что уж пусть лучше тестировщики научатся работать с Постманом и json, чем использовать какую-то надстройку из Excel.
Если нужна нормальная визуализация результатов — в том же Newman есть нормальные репортеры для Постмана, да даже для дженкинса плагины можно найти, где-то на хабре был недавно пост…
В общем Postman инструмент полезный, но данная реализация со временем быстро станет неактуальной.
Масштабировать сложно, поддерживать тоже сложно — например появится у вас десяток другой новых параметров в запросе, или логика интеграции какая нибудь сложная — что вы будете с Excel файлом делать — каждый раз вручную менять?
Да, простите, посмотрел первую часть…
Но все равно, странно, я понимаю, когда в компаниях небольшого масштаба отсутствуют тестировщики, потому что и не нужны как прослойка.
Но в таких масштабных проектах это все таки странно, пусть закрытая система, пусть пользователи сотрудники компании, пусть там старый, побитый интерфейс…
Просто удивительно слышать о внедрении системы автоматизированного тестирования в компании, где нет специалистов по ручному тестированию(ни в коем случае не хочу обидеть ваших аналитиков)…
"… к аналитикам и по совместительству тестировщикам" — это как???
Ты сегодня аналитик, а завтра тестировщик?
Как бы это немного разные профессии в принципе…
Таки да, поддерживаю предыдущего оратора. Чет многовато терминов и вот этого эльфийского «PBR-встречи», «feature-team» и т.д… Новичку уж точно не разобраться в статье…
Вопросы:
Кто был инициатором введения данной методики тестирования и какие стадии согласования вам пришлось пройти? Потому что бывает очень чопорное руководство, до которого не достучаться без предъявления очевидных преимуществ и выгоды…
Были ли те кто против? И как их лечили?
Спасибо за развернутое описание системы автотестов… Это действительно очень хороший уровень на мой неопытный взгляд… Меня немного смутил пример сравнение кода на Selenium Java… Уж больно топорный пример с actions и webdriver wait… Вроде как много библиотек типа selenide и т.д., которые позволяют очень сильно сократить данный пример… Хотя я не спорю для разработчика js проще писать на js, да и отладка на мой взгляд там более удобная…
А подскажите — как у вас с масштабируемостью e2e тестов? Если в этом плане сравнивать с java — есть ли какие то проблемы?
Ну вообще вы с такой идее можете обратится в какую нибудь контору по сбору статистики типа Instat — она российская, может быть их даже ваша инициатива заинтересует(ну или позаимствуют идею как обычно)). Из бесплатных статистических сайтов могу выделить ru.whoscored.com(там много данных, можно наверное даже парсить оттуда), sports.ru и прочие русские аналоги… Стоимость можно брать с transfermarket — достаточно авторитетный сайт.
Тут наверное не по стоимости можно ориентироваться а по пресловутому xG — оно стабильнее как то
Можно еще взять параметры как: Игра дома или в гостях(дома повышает вероятность судя по статистике), серия из последних матчей(если у команды несколько подряд проигрышей, то вероятность проигрыша увеличивается), необходимо учитывать травмы игроков, в том числе и основных, интенсивность матчей(наверное), в конце сезона турнирное положение(мотивированные команды играют лучше). Можно взять еще не статистические факторы(при увольнении/смене тренера, тоже есть отличие в игре, меняется тактика и т.д.). Можно учитывать громкие трансферы, в какой то степени бюджет клубов для постоянно обучающейся модели. Короче много можно придумать, дерзай) Очень просто и понятно для меня по крайней мере написано
По мне так это сугубо субъективный набор утилит для пользователя macOS… Как минимум стоило упомянуть Soap Ui, Appium, Fiddler + всевозможные библиотеки для автоматизации Android приложений… Все равно спасибо, если буду заниматься автоматизацией для ios буду иметь ввиду…
«например возможность поиска по словам в напечатанном тексте.» — То есть они выпустили офисное приложение в котором отсутствует такая функциональность??)
Тут просто как получилось… Тот, чье имя нельзя называть — увидел презентацию НАСА по Луне, позвонил такой Рогозину и говорит… Дмитрий! У нас есть планы? — Он такой щечками затряс, -Да...! конечно есть, но нужен миллион на презентацию!..
Ну блин, вряд ли Пентагон за импортозамещение, как некоторые, значит и качество Hololens и сопутствующего оборудования как минимум неплохое, что в свою очередь говорит о том, что все свои разработанные плюшки они не показывают широкой публике… Хотя там по сути получается 4790 за один шлем, и железо в нем должно быть топовым…
Спасибо, еще бы где-нибудь найти хорошую русскоязычную статью, о том как logstash и elasticsearch настроить для обработки java логов(например проект автотестов или простой локальный wildfly сервер с отчетами)…
Баги есть всегда, вот выявлять большинство из них — в этом и есть работа тестировщика. Предотвращать их появление — это уже работа QA.
Главное уметь находить правильный сценарий воспроизведения, а баг репорты можно писать по шаблону, в этом, на мой взгляд, нет ничего сложного.
Вопрос по мониторингу, как-то отслеживаете тенденции по отчетам автотестов за длительный промежуток времени?
И по разбору ошибок, есть ли какая то интеграция с баг-трекерами и TMS-системами? И в среднем сколько уходит времени на разбор и документацию результатов?
И самый последний вопрос — дополнительно какими инструментами пользуетесь для проверки соответствия выгружаемых ПФ шаблонам?
У меня есть пара вопросов по статье и по организации работы:
1. Подскажите пожалуйста в статье не упоминания о unit тестах, как и в каком объеме они у вас используются, и влияют ли на конечное количество сценариев UI и API тестов?
2. Очень интересно какие вы используете среды запуска тестов, например тестирование в облаке, тестирование в докер контейнерах. Как при этом выглядит кроссплатформенное и кроссбраузерное тестирование?
3. Вы писали «Для автоматизации SDET инженеры выбирают ключевые, часто используемые сценарии работы пользователя с продуктом» — можете подсказать, на основе чего идет выбор сценариев для автоматизации, берутся частые баги из трекера, берутся строгие сценарии из документации, либо происходит еще какое-то внутреннее согласование с аналитиками проекта/ручными тестировщиками?
Очень жду вторую часть с техническими аспектами, особенно про сравнение файлов и интеграцию с ELK.
Также хотелось бы узнать технологии и фреймворки(помимо тех, которые называли), которые используются на проекте.
В любом случае в последнее время редко выкладывают что то действительно полезное по тестированию. А этот подход хоть и спорный, но интересный и его можно развивать.
Postman знаю, Excel тоже…
Мне честно говоря кажется, что уж пусть лучше тестировщики научатся работать с Постманом и json, чем использовать какую-то надстройку из Excel.
Если нужна нормальная визуализация результатов — в том же Newman есть нормальные репортеры для Постмана, да даже для дженкинса плагины можно найти, где-то на хабре был недавно пост…
В общем Postman инструмент полезный, но данная реализация со временем быстро станет неактуальной.
Масштабировать сложно, поддерживать тоже сложно — например появится у вас десяток другой новых параметров в запросе, или логика интеграции какая нибудь сложная — что вы будете с Excel файлом делать — каждый раз вручную менять?
Но все равно, странно, я понимаю, когда в компаниях небольшого масштаба отсутствуют тестировщики, потому что и не нужны как прослойка.
Но в таких масштабных проектах это все таки странно, пусть закрытая система, пусть пользователи сотрудники компании, пусть там старый, побитый интерфейс…
Просто удивительно слышать о внедрении системы автоматизированного тестирования в компании, где нет специалистов по ручному тестированию(ни в коем случае не хочу обидеть ваших аналитиков)…
Ты сегодня аналитик, а завтра тестировщик?
Как бы это немного разные профессии в принципе…
Вопросы:
Кто был инициатором введения данной методики тестирования и какие стадии согласования вам пришлось пройти? Потому что бывает очень чопорное руководство, до которого не достучаться без предъявления очевидных преимуществ и выгоды…
Были ли те кто против? И как их лечили?
А подскажите — как у вас с масштабируемостью e2e тестов? Если в этом плане сравнивать с java — есть ли какие то проблемы?
Тут наверное не по стоимости можно ориентироваться а по пресловутому xG — оно стабильнее как то