Написать автотест гораздо проще и быстрее, чем искать неточность в уже написанном
Смотря, как написаны автотесты. Если по коду теста сложно понять, что пошло не так, то следует «посмотреть в глаза» автору такого автотеста.
Переключаться с автотестов на другие задачи приходилось очень часто. За час рабочего времени могут дернуть все — ПМ, разработчик, аналитик и прочие. После консультаций приходилось заново вливаться в разработку автотеста, что так же крадет ценное время.
Позволить отвлекать себя может только Senior, который может легко переключаться между контекстами. В любом случае — это не проблема автотестов.
автотест способен проверить только конкретные значения
Почему вы так решили? Автотест может проверить все возможные значения, заданные или случайные. Ровно также себя ведёт и ручной тестировщик.
Почему же ручные тестировщики не могут быть в полном объеме заменены автотестами?
По одной простой причине. Это разные сущности. Суть автоматизатора автоматизировать регулярно воспроизводимый сценарий. Ручной тестировщик при этом должен уметь исследовать причину появления ошибок / падения приложения.
Автотест делает POST /users. Ожидает 200, получает 500. Его задача отрапортовать об этом и не более того.
Когда у ручного тестировщика получается поймать пятисотую, то он должен пройтись по всем логам, посмотреть в код, если умеет, найти и понять причину ошибку, предложить варианты её исправления и завести задачу в Jira.
Если кратко, то не совсем корректно сравнивать iPhone и телефон на Android. iPhone — это прежде всего экосистема Apple. Хорошая или плохая, нравится или не нравится — другой вопрос.
Много раз приходилось ругаться с охранниками, которые хотели посмотреть мой чек и уже мой товар. Почему-то магазины хотят сэкономить на кассирах за мой счёт. Как только я оплатил товар и получил чек, ко мне не могут быть вопросов со стороны магазина. Это мой товар, а чек я имею права не брать.
Не скажу за всех, но у меня несколько раз было так, что я выкладываю в YouTube запись того, как я играю на барабанах под «минус» известные произведения. Через какое-то время приходит уведомление от YouTube в духе: «У вас в видео есть контент, защищённый авторским правом, но правообладатель не против этого. Вы не будете получать деньги с монетизации рекламы, но и ролик не будет удалён».
> Другими словами, вам достаточно приблизиться на 60 метров к ближайшему пользователю — и вы можете отправить сообщение кому угодно. Каждый юзер — нода в сети. Без интернета.
> Я правильно понимаю, что после этой доработки тест не заметит, что из шаблона случайно удалили кнопку добавления элемента в список todo?
Совершенно верно, однако на то, что кнопка Добавления элемента не пропадёт, должен будет другой тест. В итоге, если оба теста проходят, значит всё работает как и задумано.
Смотрите, если у вас есть тестовый сценарий «Удаление объекта», то для того, чтобы тест каждый раз мог удалить объект и тем самым проверить, что удаление работает корректно, тесту нужно сначала объект создать. Каким образом он будет создан — не столь важно.
Например, добавлен через БД или через API.
Проверка чего-то через DOM — это малая часть работы теста.
То, что Глеб (автор статьи в оригинале) называет App Action, по сути является precondition для теста, и правильно его делать самым быстрым способом. API, правка в БД, или функции самого приложения.
> при ленивом разговоре и не очень отчётливой артикуляции довольно похожими получаются звуки Д и Т
1. Я купил домик Толстого.
2. Я купил томик Толстого.
В вашем случае домик/томик запишутся как «tomux».
Не зная контекста, совсем не ясно, что имелось в виду.
Русский язык не дозволяет играться с произношением на письме.
> Если мы возьмем работу среднего программиста и среднего инженера по тестированию, то программисту приходится сильнее думать головой и решать более сложные задачи.
Несусветная глупость. Зачем такие статьи на Хабре пропускают?
Смотря, как написаны автотесты. Если по коду теста сложно понять, что пошло не так, то следует «посмотреть в глаза» автору такого автотеста.
Позволить отвлекать себя может только Senior, который может легко переключаться между контекстами. В любом случае — это не проблема автотестов.
Почему вы так решили? Автотест может проверить все возможные значения, заданные или случайные. Ровно также себя ведёт и ручной тестировщик.
По одной простой причине. Это разные сущности. Суть автоматизатора автоматизировать регулярно воспроизводимый сценарий. Ручной тестировщик при этом должен уметь исследовать причину появления ошибок / падения приложения.
Автотест делает POST /users. Ожидает 200, получает 500. Его задача отрапортовать об этом и не более того.
Когда у ручного тестировщика получается поймать пятисотую, то он должен пройтись по всем логам, посмотреть в код, если умеет, найти и понять причину ошибку, предложить варианты её исправления и завести задачу в Jira.
Если кратко, то не совсем корректно сравнивать iPhone и телефон на Android. iPhone — это прежде всего экосистема Apple. Хорошая или плохая, нравится или не нравится — другой вопрос.
Вы описали только работу с именем.
Её можно сильно упростить.
Два поля. Имя для документов и Имя для обращения к пользователю.
Имя для документов: Сергей Сергеевич Сергеев (как в паспорте)
Имя для обращения в письмах: Серёжа (да, я хочу, чтобы ко мне неформально обращались Серёжа.
Не нужно пытаться делить имя на составные части (ФИО).
Много раз приходилось ругаться с охранниками, которые хотели посмотреть мой чек и уже мой товар. Почему-то магазины хотят сэкономить на кассирах за мой счёт. Как только я оплатил товар и получил чек, ко мне не могут быть вопросов со стороны магазина. Это мой товар, а чек я имею права не брать.
Всё можно простить молодому российскому стартапу, но зачем же проект, созданный сугубо для программистов делать с русским интерфейсом?
https://www.hackerrank.com/domains/regex
Что не так со скрепышами?
К сожалению, Safari в iOS 15. Это жутко неудобно, надеюсь, что вернут возможность вернуть адресную строку туда, где ей место, т. е. вверху.
И адресная строка есть, и перевод есть, и вёрстка не сломалась.
Что не так с AMP?
Не скажу за всех, но у меня несколько раз было так, что я выкладываю в YouTube запись того, как я играю на барабанах под «минус» известные произведения. Через какое-то время приходит уведомление от YouTube в духе: «У вас в видео есть контент, защищённый авторским правом, но правообладатель не против этого. Вы не будете получать деньги с монетизации рекламы, но и ролик не будет удалён».
В наше время это называлось FIDO. :)
Совершенно верно, однако на то, что кнопка Добавления элемента не пропадёт, должен будет другой тест. В итоге, если оба теста проходят, значит всё работает как и задумано.
Смотрите, если у вас есть тестовый сценарий «Удаление объекта», то для того, чтобы тест каждый раз мог удалить объект и тем самым проверить, что удаление работает корректно, тесту нужно сначала объект создать. Каким образом он будет создан — не столь важно.
Например, добавлен через БД или через API.
То, что Глеб (автор статьи в оригинале) называет App Action, по сути является precondition для теста, и правильно его делать самым быстрым способом. API, правка в БД, или функции самого приложения.
1. Я купил домик Толстого.
2. Я купил томик Толстого.
В вашем случае домик/томик запишутся как «tomux».
Не зная контекста, совсем не ясно, что имелось в виду.
Русский язык не дозволяет играться с произношением на письме.
Несусветная глупость. Зачем такие статьи на Хабре пропускают?
Чем оно лучше Google Meet?