представь себе страницу ютуба, покрой автотестом проигрывание видео

И в чем сложность, собственно?

звучит так, как буд-то им некогда, может это правда?

Если нет времени сейчас, его не будет и потом. Это аксиома.

Если нет времени сейчас, его не будет и потом. Это аксиома.

Потом его не будет ещё больше

в том что видео может рассыпаться на квадраты, иметь брак по звуку, иметь в конце концов неправильный аспект и много чего еще

в том что видео может рассыпаться на квадраты, иметь брак по звуку, иметь в конце концов неправильный аспект и много чего еще

Это разные зоны ответственности , если че

Плеер тут не при чем

Если нет времени сейчас, его не будет и потом. Это аксиома.

++

Плеер тут не при чем

не всегда

в том что видео может рассыпаться на квадраты, иметь брак по звуку, иметь в конце концов неправильный аспект и много чего еще

Окей, предположим. У вас есть N форматов, N языков, N разрешений и прочее.

Потратить два месяца на автоматизацию этого быстрее, чем 10 раз пройти регрессию на всем этом зоопарке.

Убеждался что фраза "давайте сейчас потерпим, а потом реализуем все как следует", может говориться кварталами :)

Убеждался что фраза "давайте сейчас потерпим, а потом реализуем все как следует", может говориться кварталами :)

годами

"веками"

Знаю достаточно много ребят, которые автоматизировали плееры.

Потратить два месяца на автоматизацию этого быстрее, чем 10 раз пройти регрессию на всем этом зоопарке.

ребятушки, я не против разумной автоматизации, то что надо смотреть глазами оставьте ручникам :)

Убеждался что фраза "давайте сейчас потерпим, а потом реализуем все как следует", может говориться кварталами :)

Нет ничего более постоянного, чем временное.

ребятушки, я не против разумной автоматизации, то что надо смотреть глазами оставьте ручникам :)

Всё, что надо проверять со стабильной регулярностью проще автоматизировать, чем доверять человеку.

Но вообще конечно не поспорить с тем фактом, что на поддержку автоматизации тратятся силы и нужно обладать скиллами. Иначе это все может только усложнить ситуацию в проекте.

Дальше уже вопрос cost\value.

Я бы ни в коем случае не стал доверять человеку тестировать корректность проигрывания видео\аудио.

Если, конечно, это критично для бизнеса.

int blech (int j) { j = j -1; // should be j = j + 1 j = j / 30000; return j; } Какие 4 инпута помогут найти скрытые баги? принимает int J потом отнимает 1 и делит на 30000 и просто считает и выдает результат, при условии что мы считаем на 16 битной системе то минимальное значение моэет быть -32768 а макс 32767

@azshoo скажи свое мнение

Если, конечно, это критично для бизнеса.

честно говоря даже и не знаю как можно автоматизировать просмотр видео роботом, если видео зашифровано...

если только захват с экран и анализ косвенного результата

скриншоты раз в N секунд и perfect pixel ?

пефект пиксель не прокатит

Да вариантом, на самом деле, довольно много. Начиная от считывания output и валидации оного.

Ну если есть отдел разработки плеера, то у них должны быть наработки как все это тестировать

В любом случае, у машины тут явно больше интрументов для валидации, чем у убогонького человека.

@azshoo скажи свое мнение

Там в конце книжки глава с ответами есть.

В любом случае, у машины тут явно больше интрументов для валидации, чем у убогонького человека.

есть ситуации, когда присутствуют потери пакетов, но визуально это незаметно. считаем проблемой?

Там в конце книжки глава с ответами есть.

спасибо!

Да вариантом, на самом деле, довольно много. Начиная от считывания output и валидации оного.

в аутпуте абракадбра, видео то зашифровано, поэтому в этом случае можно только проверить, что оно есть и нормальный статус ответа

в аутпуте абракадбра, видео то зашифровано, поэтому в этом случае можно только проверить, что оно есть и нормальный статус ответа

Ещё раз. Автотест можешь валидировать всё то же самое, что получает пользователь, если брать самый end-to-end сценарий.

На каком уровне это считывать - на уровне image recognition на view, рендеринга всего этого дела или ниже - зависит от конкретных реализаций.

Так или иначе, если вы даете пользователю картинку и звук - робот более точно отвалидирует и качество картинки, и качество звука.

эх, ежели бы было всё так просто, а то и звук переменый и битрейт тоже :)

Всё, на самом деле, предельно просто. Вопрос тестовых данных и корректных точек ассерта.

еще и конвертация одного и того же видео 2 раза подряд может давать разные результаты незаметные глазу, но отличающиеся для роботов

еще и конвертация одного и того же видео 2 раза подряд может давать разные результаты незаметные глазу, но отличающиеся для роботов

Да, и в этом смысл не проверять это глазами.

наверное у меня проблемы с фантазией, но всё что тут советовали не подошло для тестирования видео роботами, может конечно я криворучка :)

наверное у меня проблемы с фантазией, но всё что тут советовали не подошло для тестирования видео роботами, может конечно я криворучка :)

так никаких конкретных технических реализаций предложено не было

int blech (int j) { j = j -1; // should be j = j + 1 j = j / 30000; return j; } Какие 4 инпута помогут найти скрытые баги? принимает int J потом отнимает 1 и делит на 30000 и просто считает и выдает результат, при условии что мы считаем на 16 битной системе то минимальное значение моэет быть -32768 а макс 32767

от того, что инт принимается функцией, не говорит, что если ты передаешь longint - он будет обрабатываться корректно

другими словами, передавая 236523652786527385627385623785 ты можешь убить систему

хорошо один раз убили, какие еще 3 варианта ну помимо того что мы изменим одну цифру в лонгинт'е

другими словами, передавая 236523652786527385627385623785 ты можешь убить систему

Но, если я правильно понимаю судь заданного вопроса, это никак не поможет найти скрытый баг.

в моей книге в конце не было ответов

в моей книге в конце не было ответов

Кругом обман. ;[

По поводу некрасивых формочек. Если интерфейс сильно снижает скорость работы или может привести к ошибочным действиям пользователя - можно смело заводить баг с нормальным приоритетом. Если нет - надеяться на упорство UI дизайнера или тягу к прекрасному человека, который стоит выше. Если пользователей несколько десятков тысяч и больше - тут и наведение красоты может иметь высокий приоритет. А вообще и разработчикам и тестировщикам для общего развития стоит почитать про ux

Я самые эпичные ошибки UI/ux печатаю в качестве мемов и клею себе на стену Разработчики заходят, смеются и ещё раз вспоминают про эту задачу. Когда их исправляют - снимаю

Да и не только про UI, просто не сильно важные для заказчика, но раздражающие меня

Это хорошо когда ты вернуть таск можешь, а тут лид QA поставил оценку 8 из 10 и сказал, что форма нормальная

И сказал отдаем заказчику

То неловкое чувство когда у тебя скилл качества прокачан больше чем у твоего лида

То неловкое чувство когда у тебя скилл качества прокачан больше чем у твоего лида

+

Ну оно часто и правильно, на команде в целом висит еще километр задач, и вылизывать каждую форму нет времени, а может он просто уже устал все за всеми фиксить.

А может это просто не приоритет для бизнеса. Имхо дело QA это донести информацию до команды о состоянии продукта

А потом уже совместно с командой решается приорити каждой проблемы. Кстати форма страшная, но для 1С прокатит, надо на весь продукт смотреть. Я бы поставила пару миноров если функциональность работает.

Выпуск про тестирование API наконец-то вышел из карантина! radio-qa.com/api-testing/

http://radio-qa.com/personal-efficience/

ERROR: S client not available

Матерь божья, коучи по личной эффективности на радиокуа. Т.т

Матерь божья, коучи по личной эффективности на радиокуа. Т.т

Модная тема чо )

Привет всем )

Привет

чёт не понял. На сайте Радио стоит Фидбек от Р.Савина, а если перейти на его вебстраницу - там предлагают пройти курс How to become..... за авторством Р.Савенкова.. это два разных человека ?

кажется, это разные фамилии

Вопрос такой. Вот пишу я автотесты по REST API. И задумался. Например. Есть апи изменения профиля. И там есть возможность изменить себе пол. Как будет правильнее? Написать два теста которые изменят пол "туда" и потом "обратно" ? Или написать один тест и рандомно выбирать из доступных значений ?

update метод идемпотентный, он каждый раз должен быть успешным

на что бы ты не менял, он должен при правильных сболюденных условиях завершаться одинаково: апдейтить модель

Апдейтить то апдейтит. И на данном этапе нет проверок что смена пола поменяла что-то еще

для update нет понятия "туда и обратно" - есть сохранил стейт или нет :) я бы написал 1 тест и рандомно выбирал из доступных значений

Вопрос такой. Вот пишу я автотесты по REST API. И задумался. Например. Есть апи изменения профиля. И там есть возможность изменить себе пол. Как будет правильнее? Написать два теста которые изменят пол "туда" и потом "обратно" ? Или написать один тест и рандомно выбирать из доступных значений ?

если зависимостей от поля никаких Точно нет: то наверное достаточно отправлять "не активное" - что бы проверять смену А если есть зависимости и какие-то хуки/колбеки на это поле: то надо проверять все )

если зависимостей от поля никаких Точно нет: то наверное достаточно отправлять "не активное" - что бы проверять смену А если есть зависимости и какие-то хуки/колбеки на это поле: то надо проверять все )

даже если пользователь отправляет активное - метод должен работать одинаково

другое дело, что на фронтенде это можно разруливать, убирая (дизейбля) кнопку сохранения формы

Вопрос такой. Вот пишу я автотесты по REST API. И задумался. Например. Есть апи изменения профиля. И там есть возможность изменить себе пол. Как будет правильнее? Написать два теста которые изменят пол "туда" и потом "обратно" ? Или написать один тест и рандомно выбирать из доступных значений ?

там жеж API : какой фронтеэнд и блокировка-дизейблом ? )

я про то, что для теста API не должно быть никакой разницы в плане кода ответа, как апдейтить М: на М или на Ж

ну а вдруг есть ?) типа апдейт на то же значение: Все ок а н адругой: необходимо отправить второй запрос или какое-нибудь подтверждение или еще какая магия Бизнесс-логики ?)

какая например

мы точно про rest api говорим? :)

Матерь божья, коучи по личной эффективности на радиокуа. Т.т

Серьезно? Всё, это дно

Ну я пока вижу что это просто запись в базу. Записалось М или Ж

я бы проверил что в респонсе вернулось заданное значение и все.

а если не возвращает, то можно сделать get profile и там чекнуть пол

Если мы говорим про написание тест сьютов, то я бы не стал проверять результат rest метода другим rest методом.

Канонично проверять состояние БД через ORM фикстуры, все лучше и быстрее. А так получается не изолированное тестирование, а интеграционное. При том, что ты делаешь проверку на другой метод, полагаясь на его "истинность" и правдивость

добры люди скиньте все что у вас есть по работе на тест-дизайнера

google.com - держи

Канонично проверять состояние БД через ORM фикстуры, все лучше и быстрее. А так получается не изолированное тестирование, а интеграционное. При том, что ты делаешь проверку на другой метод, полагаясь на его "истинность" и правдивость

о. а вот где про это почитать ?

Вообще у меня пока такое себе. Интеграционное. Ну типа проект маленький и все такое.

не подскажу, это моё личное мнение. Его можно оспорить :) но по факту создавать контекст для высокоуровнего (API) теста за счет БД (low-level layer) и в БД же проверять результат при необходимости - кажется мне более правильным подходом.