Спасибо за наводку, интересно.
HAR мы вытягиваем с помощью экстеншена для Firefox и средствами performance logs для Chrome. Решение хорошо описано у ребят из https://sitespeed.io
Я вот прямо сейчас глянул на то, что Mozilla предлагает — не уверен, что так можно сделать, например, в Selenoid (может, невнимательно смотрел).
Интересный функционал. Мы рассматривали BugReplay, но в итоге просто иногда записываем видео (когда надо) и почти всегда пишем HAR. Этого вполне достаточно (пока).
Но как мы знаем, аппетит приходит во время еды и пока функционала нет, то его никто и не просит.
Вы это расширение где-то опубликовали?
Аналогичный пример у меня с Варшавой был. Телефон сеть потерял и повёл через центр города вместо объезда.
Вариантов немного — (1) возиться с телефоном на обочине (2) ехать по знакам и рисковать проскочить нужные повороты (3) ехать через центр и потерять часик.
Увы, выбрал третье. Хорошо бы учитывать среднюю "заложенность" дорог для прокладывания маршрута.
Но программа отличная, всё равно спасибо :)
Простите, а вы как и чем топите? У меня в Лондоне 40 фунтов в месяц отопление (газовое) + электричество. А дома здесь далекооо не самые энергоэффективные.
если бы там только "ф" было. Gh произносится девятью вариантами — аф, оф, эф, ау, оу, у, э, ап, ок, ох и "шва" (ну, название у звука такое).
Честно, я не по памяти это перечислял. А вот примеры по памяти могу.
Пока не получилось, наверное.
Лично моё мнение, что в довольно близкой перпективе вполне можно будет научить нейросеть писать автотесты или юнит-тесты.
Ручное тестирование / QA- немного другая вещь, тут больше работы с материальными объектами и общения с людьми, чем непосредственного взаимодействия с кодом.
Документация — это боль всегда, причем сильно зависит от компании и инструментов. Опыт в написании документации для одной компании, может быть вполне неприменим для другой, как минимум потому, что у них нет confluence.
Документация по проекту — да, а документация по тому, как тестировать проект — нет. Часто ооочень многими недооценивается факт того, что не весь функционал в проекте тестируется в один клик. И как быстро объяснить кому-то что и как можно протестировать? А новому сотруднику? А если вы сами забыли? А если документации на проекте в принципе нет (читайте — стартап)? Это забота QA создавать подобные заметки, которые потом перерастут в документацию.
Не подскажите, зачем manual QA нужен mind map?
Визуализация и организация данных, которые в виде графов выглядят лучше, чем в текстовом. Так же, как и везде :)
Вопрос о том, как описывать задачи и баги почти на 100% лежит на трекинговой системе.
И да, и нет. Если у вас есть поле description, как вы там опишете какую-то багу? Когда 15 человек на проекте заводят баги с текстом вида "кнопка не работает" — у вас голова опухнет ходить к каждому и спрашивать: "так какая кнока не работает? и КАК она не работает? по enter? по click?" Запись видео, скриншотов, гифок в разных средах, браузерах и операционных системах. Если работаете с вебом, то BugReplay и т.п.
работа с VCS для мануальщика разве нужна?
Сделаю круглые глаза. Абсолютно нужна. Как минимум надо знать git и mercurial хотя бы на базовом уровне. Да вы самому себе упростите жизнь, если научитесь ими пользоваться.
безопасность
Вас же по голове никто не бьёт развиваться в "кросс-доменной" области? То, что вы можете найти не только XSS, но и что-то посерьёзнее (и, более того, знаете как это быстро и эффективно искать) — очень даже большая польза.
А если вы не веб тестируете, а андроид? а iOS? ууу… поле непаханное.
Разве таким не должен заниматся QA team lead?
А если вы единственный человек на проекте? Manual QA может вполне вырасти до QA team lead. Вам не надо уметь писать код для этого, поверьте.
А manual QA нужно уходить в кросс-доменную область?
QA — в принципе кросс-доменная область. Там есть тестирование, обеспечение качества, контроль качества. Если хотите остаться только в тестировании — развивайте навыки и обогащайте знаяния в инструментарии. Знайте слабые и сильные стороны различных браузеров. Тестируете андроид? Какие устройства идут без установленного google play market, а ваше приложение должно бы работать в этой стране? и так далее, и тому подобное.
Грамотный тестировщик — специалист миллиона навыков.
умение строить вести QA в миллионе тонкостей: как писать документацию и держать её хоть как-то актуальной, mind maps, как описывать задачи / баги, работа с VCS,… тысячи таких вопросов, которые выглядят мелкими, но ответов на которые дадут десятки
безопасность
интернационализация приложений / сайтов (тут не обойтись без хотя бы поверхностного представления о языках и культурах)
умение построить процесс QA, когда это требуется
умение отделять мух от котлет — как раз «Умение ориентироваться в приоритетах бизнеса» в словах автора — тоже дело опыта
Ответ будет длинным.
Совсем избавить UI-тесты от тавтологий, наверное, не получится. Причина как в раз в том, что же мы хотим проверить — мы хотим убедиться что поведения правильное или что поведение соответствует ожидаемому? Правильное поведение должно быть протестировано вручную или с помощью TDD, с привлечением документации или хотя бы с помощью здравого смысла и постановщика задачи. Протестировать то, что ожидаемое поведение не нарушено — это, по сути, регрессионное тестирование. В части задач (например, ежедневные выкладки) целенаправленно тесты пишутся именно таким образом.
Но можно убрать тавтологию в компонентах, на которые мы делим тест или проверяем. Например, мы знаем, что определённая компонента подвергается постоянным изменениям. Так ли нам важно проверять, что элемент <div id="test">new text</div> является div-ом, не достаточно ли проверять элемент #test? Кажется очевидным, но это пример простой. В реальных тестах всё довольно сложнее.
Ну, например, выпилил проверку того, всплывающее сообщение с каким текстом показывается после той или иной операции. Там нет текста, соответствующего ошибке? Значит, тест будет считать, что операция завершилась успешно и продолжать своё выполнение: ему нужно убедиться, что, например, покупка прошла и поменялись балансы. Поменялись? Отлично.
А проверку того, какое облачко будет показываться после покупки (например) — мы будем делать в тепличных условиях и проверять будем только это.
Короче. Порой надо проверять компоненты, а порой — сценарии. Если нужен сценарий, то выпиливайте подробную проверку компонент.
По-моему, так.
интересно. попробуем, спасибо.
Applitools стали популярны примерно полтора года назад. VRT (Visual regression testing) мы начали делать года четыре назад :)
Спасибо за наводку, интересно.
HAR мы вытягиваем с помощью экстеншена для Firefox и средствами performance logs для Chrome. Решение хорошо описано у ребят из https://sitespeed.io
Я вот прямо сейчас глянул на то, что Mozilla предлагает — не уверен, что так можно сделать, например, в Selenoid (может, невнимательно смотрел).
Интересный функционал. Мы рассматривали BugReplay, но в итоге просто иногда записываем видео (когда надо) и почти всегда пишем HAR. Этого вполне достаточно (пока).
Но как мы знаем, аппетит приходит во время еды и пока функционала нет, то его никто и не просит.
Вы это расширение где-то опубликовали?
Аналогичный пример у меня с Варшавой был. Телефон сеть потерял и повёл через центр города вместо объезда.
Вариантов немного — (1) возиться с телефоном на обочине (2) ехать по знакам и рисковать проскочить нужные повороты (3) ехать через центр и потерять часик.
Увы, выбрал третье. Хорошо бы учитывать среднюю "заложенность" дорог для прокладывания маршрута.
Но программа отличная, всё равно спасибо :)
Простите, а вы как и чем топите? У меня в Лондоне 40 фунтов в месяц отопление (газовое) + электричество. А дома здесь далекооо не самые энергоэффективные.
В Европе её покупают потому что:
в России ни один из этих пунктов (и все вместе) не могут финансово оправдать её покупку
К списку комбайнов — https://www.katalon.com/
если бы там только "ф" было. Gh произносится девятью вариантами — аф, оф, эф, ау, оу, у, э, ап, ок, ох и "шва" (ну, название у звука такое).
Честно, я не по памяти это перечислял. А вот примеры по памяти могу.
https://m.geektimes.ru/company/puzzleenglish/blog/296127/ вот же.
Пока не получилось, наверное.
Лично моё мнение, что в довольно близкой перпективе вполне можно будет научить нейросеть писать автотесты или юнит-тесты.
Ручное тестирование / QA- немного другая вещь, тут больше работы с материальными объектами и общения с людьми, чем непосредственного взаимодействия с кодом.
Вы про какой-то конкретный комментарий или "в принципе"?
Документация по проекту — да, а документация по тому, как тестировать проект — нет. Часто ооочень многими недооценивается факт того, что не весь функционал в проекте тестируется в один клик. И как быстро объяснить кому-то что и как можно протестировать? А новому сотруднику? А если вы сами забыли? А если документации на проекте в принципе нет (читайте — стартап)? Это забота QA создавать подобные заметки, которые потом перерастут в документацию.
Визуализация и организация данных, которые в виде графов выглядят лучше, чем в текстовом. Так же, как и везде :)
И да, и нет. Если у вас есть поле description, как вы там опишете какую-то багу? Когда 15 человек на проекте заводят баги с текстом вида "кнопка не работает" — у вас голова опухнет ходить к каждому и спрашивать: "так какая кнока не работает? и КАК она не работает? по enter? по click?" Запись видео, скриншотов, гифок в разных средах, браузерах и операционных системах. Если работаете с вебом, то BugReplay и т.п.
Сделаю круглые глаза. Абсолютно нужна. Как минимум надо знать git и mercurial хотя бы на базовом уровне. Да вы самому себе упростите жизнь, если научитесь ими пользоваться.
Вас же по голове никто не бьёт развиваться в "кросс-доменной" области? То, что вы можете найти не только XSS, но и что-то посерьёзнее (и, более того, знаете как это быстро и эффективно искать) — очень даже большая польза.
А если вы не веб тестируете, а андроид? а iOS? ууу… поле непаханное.
А если вы единственный человек на проекте? Manual QA может вполне вырасти до QA team lead. Вам не надо уметь писать код для этого, поверьте.
QA — в принципе кросс-доменная область. Там есть тестирование, обеспечение качества, контроль качества. Если хотите остаться только в тестировании — развивайте навыки и обогащайте знаяния в инструментарии. Знайте слабые и сильные стороны различных браузеров. Тестируете андроид? Какие устройства идут без установленного google play market, а ваше приложение должно бы работать в этой стране? и так далее, и тому подобное.
Грамотный тестировщик — специалист миллиона навыков.
Citymapper, кмк умеет такое
Мир-Кольцо было, теперь Мир-Бублик!
Забавно, но в соседней статье на хабре обсуждают очень близкую тему: https://habrahabr.ru/company/infopulse/blog/336110/#comment_10377980
Ответ будет длинным.
Совсем избавить UI-тесты от тавтологий, наверное, не получится. Причина как в раз в том, что же мы хотим проверить — мы хотим убедиться что поведения правильное или что поведение соответствует ожидаемому? Правильное поведение должно быть протестировано вручную или с помощью TDD, с привлечением документации или хотя бы с помощью здравого смысла и постановщика задачи. Протестировать то, что ожидаемое поведение не нарушено — это, по сути, регрессионное тестирование. В части задач (например, ежедневные выкладки) целенаправленно тесты пишутся именно таким образом.
Но можно убрать тавтологию в компонентах, на которые мы делим тест или проверяем. Например, мы знаем, что определённая компонента подвергается постоянным изменениям. Так ли нам важно проверять, что элемент
<div id="test">new text</div>является div-ом, не достаточно ли проверять элемент#test? Кажется очевидным, но это пример простой. В реальных тестах всё довольно сложнее.Ну, например, выпилил проверку того, всплывающее сообщение с каким текстом показывается после той или иной операции. Там нет текста, соответствующего ошибке? Значит, тест будет считать, что операция завершилась успешно и продолжать своё выполнение: ему нужно убедиться, что, например, покупка прошла и поменялись балансы. Поменялись? Отлично.
А проверку того, какое облачко будет показываться после покупки (например) — мы будем делать в тепличных условиях и проверять будем только это.
Короче. Порой надо проверять компоненты, а порой — сценарии. Если нужен сценарий, то выпиливайте подробную проверку компонент.
По-моему, так.
Да, пример в статье не идеальный, согласен
Скорее, "I know this feel, bro" (с)