Мы тоже не шашкой махали, думали, пробовали. Если совсем насмерть сократить мысль статьи, то между «с оценкой сроков» и «без оценки сроков, но вдвое быстрее, чем если бы оценивали» мы — в продуктовой разработке — выбрали второе. Самая важная часть статьи, на мой взгляд, после слов «серия упражнений в разработке».
Легко. *Видео, где я 20 секунд смотрю дифф кода, потом прогоняю руками 1 кейс, который действительно нужно прогнать*
Я не собираюсь соревноваться с машиной в том, в чем она явно лучше.
Еще раз, в чем предмет спора?
Вы считаете, что автоматизировать уже можно всё? Как долго вы будете писать скриншотные тесты, которые не пропустят все ошибки верстки, которые пропустит тест с видео? Еще примеров того, что автоматизировать нельзя? Сколько человеко-тысячелетий потрачено на код, который разработчики писали, забыв спросить «а зачем?»…
Какая тут мне может быть польза от ручного тестировщика?
Для тестирования апи, как правило, выделенный тестер не нужен. Но область знаний того самого «ручного» тестировщика помогла бы тратить меньше времени на тесты бесполезные и больше — на полезные.
Для такого небольшого приложения, где можно быстро написать 50 e2e кейсов и запускать их настолько регулярно в режиме отладки тестировщик мог бы спросить, а нужны ли тесты вообще…
Кстати, на текущем уровне развития автоматизации 50 тестов через браузер вручную прогнать быстрее живым человеком.
Вы поменяли предмет спора. Я не говорил, что автоматизация не нужна. Я говорил, что сейчас закодированные тесты тестирование заменить не способны в большинстве случаев.
Я не предполагаю, я точно знаю, что в 4 случаях из 5 автоматизированный сценарий дороже, чем ручной тестировщик. Потому как к этому сценарию прилагается «автоматизатор», который, как правило, умеет писать сценарии, а пользу — не умеет.
Сейчас уже наверное можно автоматизировать любое или почти любое тестирование.
Тестирование это чуть сложнее, чем клики. Всё еще не автоматизируется «думать» и «оценка рисков». Плохо поддается автоматизации стандартная проблема тестовых фреймворков — эффективность тестового набора.
Проектов по тотальной автоматизации с не отрицательным ROI всё еще меньше, чем один на десять.
Я допускаю, что «тотальная» автоматизация возможна в заказной разработке, где клиенту продаются часы, а не качество, но если вы автоматизируете тестирование своего продукта за свои деньги, то заявления будут намного менее безапелляционными.
Следует довести до него, что разработчики являются просто людьми, а всем людям свойственно ошибаться. Отдел QA должен компенсировать это естественное человеческое свойство разработчиков, действуя как защита от ошибок, влияющих на клиентов.
и
Отдел обеспечения качества (QA) занимается поиском багов в ПО.
Сдается мне, и автор текста, и переводчик слабо представляют себе и процесс разработки и роль QA в нем.
В обычном рабочем режиме вся ветка прогоняется вручную по 800+ тест-кейсам. Полная команда тестировщиков делает у нас штатное регрессионное тестирование за две недели.
Многие, чтобы не отвлекаться от работы, разбирает свою почту несколько раз за день. Совсем другое дело мессенджеры. Реакция на сообщения в мессенджерах куда выше. И было решено подключить бота к нашему мессенджеру. Бот шлёт оповещения о статусе код-ревью как для автора пулл-реквеста, так и призывает людей поревьюить. Очень удобно.
Отвлекать в мессенджере — мерзко. Повышать культуру работы с почтой, конечно же, намного сложнее.
Вы озвучили одну проблему — новые сотрудники со временем не становились ревьюерами, из-за этого старые имели сверхнагрузку. Остальное не проблемы, а факты и особенности, не влияющие на скорость.
Вопрос: вы изменили скорость, добавили квадриллион напоминалок. Как поменялось качество ревью?
Простите, вы считаете, что SDET это роль, которая пишет тесты?
SDET, у эппла и мелкомягких, которые заявляют, что они придумали эту роль, занимаются не автоматизацией тестирования, а автоматизацией процессов, работой над тестируемостью и обеспечением качества. Это две большие разницы, QC и дописыванием за разработчиками тестов они не заняты.
То, о чем писали вы — это недоразработчик, ну или чернорабочий в IT.
Последняя книга Канера, которую я читал, издана в 2013, «Foundations of Software Testing».
В статье ребята имеют в виду «Lessons Learned in Software Testing», издана в 2001.
Вы имеете в виду второе издание «Testing Computer Software».
Основы и база тестирования мало поменялись за 30 лет. Теории инженерного эксперимента больше пятидесяти, базе программирования около шестидесяти, а современный русский язык разменял вторую сотню. Так что всё норм.
1. Почему регрессионные автоматизированные тесты используются после объединения веток, а не до?
2. У вас есть выделенные автоматизаторы? Это же не эффективно, почему тестеры не учатся кодить? Или почему этим не занимаются программисты?
3.
Огонь! На каком количестве задач считали?
4.
Уволили? Перепрофилировали? Если не секрет, куда?
Я бы согласился с «нужно пытаться» или «стоит прикладывать усилия». Но «уже можно».
*Видео, где я 20 секунд смотрю дифф кода, потом прогоняю руками 1 кейс, который действительно нужно прогнать*
Я не собираюсь соревноваться с машиной в том, в чем она явно лучше.
Еще раз, в чем предмет спора?
Вы считаете, что автоматизировать уже можно всё? Как долго вы будете писать скриншотные тесты, которые не пропустят все ошибки верстки, которые пропустит тест с видео? Еще примеров того, что автоматизировать нельзя? Сколько человеко-тысячелетий потрачено на код, который разработчики писали, забыв спросить «а зачем?»…
Для тестирования апи, как правило, выделенный тестер не нужен. Но область знаний того самого «ручного» тестировщика помогла бы тратить меньше времени на тесты бесполезные и больше — на полезные.
Для такого небольшого приложения, где можно быстро написать 50 e2e кейсов и запускать их настолько регулярно в режиме отладки тестировщик мог бы спросить, а нужны ли тесты вообще…
Кстати, на текущем уровне развития автоматизации 50 тестов через браузер вручную прогнать быстрее живым человеком.
Вы поменяли предмет спора. Я не говорил, что автоматизация не нужна. Я говорил, что сейчас закодированные тесты тестирование заменить не способны в большинстве случаев.
Тестирование это чуть сложнее, чем клики. Всё еще не автоматизируется «думать» и «оценка рисков». Плохо поддается автоматизации стандартная проблема тестовых фреймворков — эффективность тестового набора.
Проектов по тотальной автоматизации с не отрицательным ROI всё еще меньше, чем один на десять.
Я допускаю, что «тотальная» автоматизация возможна в заказной разработке, где клиенту продаются часы, а не качество, но если вы автоматизируете тестирование своего продукта за свои деньги, то заявления будут намного менее безапелляционными.
и
Сдается мне, и автор текста, и переводчик слабо представляют себе и процесс разработки и роль QA в нем.
Получается концепция «раньше» и «позже» существует? Я об этом.
А вот выполнение полезных, но неинтересных работ как способ получения некоего ценного и ограниченного ресурса — мне нравится.
К пункту один, вы трекаете рабочее время?
А как часто?
Отвлекать в мессенджере — мерзко. Повышать культуру работы с почтой, конечно же, намного сложнее.
Вы озвучили одну проблему — новые сотрудники со временем не становились ревьюерами, из-за этого старые имели сверхнагрузку. Остальное не проблемы, а факты и особенности, не влияющие на скорость.
Вопрос: вы изменили скорость, добавили квадриллион напоминалок. Как поменялось качество ревью?
А ведь есть такая штука, как электронная почта.
У вас:
Разработчик сам не способен, ему нужен секретарь?
SDET, у эппла и мелкомягких, которые заявляют, что они придумали эту роль, занимаются не автоматизацией тестирования, а автоматизацией процессов, работой над тестируемостью и обеспечением качества. Это две большие разницы, QC и дописыванием за разработчиками тестов они не заняты.
То, о чем писали вы — это недоразработчик, ну или чернорабочий в IT.
В статье ребята имеют в виду «Lessons Learned in Software Testing», издана в 2001.
Вы имеете в виду второе издание «Testing Computer Software».
Основы и база тестирования мало поменялись за 30 лет. Теории инженерного эксперимента больше пятидесяти, базе программирования около шестидесяти, а современный русский язык разменял вторую сотню. Так что всё норм.
Жаль, что перестали.
На jug не очень, не мой формат.