Провокационный вопрос: если 56% багов от неправильно понятых требований, и неправильно может понять как разработчик, так и тестировщик, значит ли это, что е2е автотест, заменяющий ручной прогон, не гарантирует успеха, если тесты внимательно не посмотрит аналитик? UPD. Снимается, досмотрел до встречи трёх амиго.
Молодой человек чтобы обсуждать что-то основательно - надо чтобы в докладе была идея и хорошие мысли Пока что в этом докладе только салат из кусков различных идей из интернета, книг и прочего - ничего из этого не связано с реальной работой Самый очевидный пример того что автор далёк от тестирования это 41я минута и пример того как приложение тестировалось набиванием неправильных тестовых данных в базу. На реальном проекте тестировщику бы объяснили что он не прав, а не хвалили какой он молодец как он красиво делает
Автор я. Реальная работа есть - мои проекты. Иначе откуда бы взялся доклад? В начале доклада я сказала, почему мы не рассматриваем сдвиг на примере промышленного приложения. Я бы не успела показать сдвиг от начала до конца. Частично согласна с комментарием, что в реальной жизни возможно не стали бы набивать базу некорретными тестовыми данными. И это касается именно e2e сценариев. И я этот пример использовала, как один из наиболее ярких и понятных тестировщикам, даже джунам. И при этом я все-равно считаю, что на уровне юнит-тестов все-равно должна стоять "защита от дурака" и такие тесты, проверяющие корректность содержащихся данных в БД должны быть. Эти тесты являются ведь еще и спецификацией к коду и продукту.
Вредных докладов не бывает. Любая информация ведет либо к ошибке либо к успеху. И на том и на другом можно учиться. Хотя я так и не понял, зачем для всего этого вводили новый термин. Идея такая же как у Канера в 80-х, чем раньше тестируем - тем дешевле цена ошибки. Разница с ТДД только в том что код рефакторить не хочется? Это ошибка планирования. Функция слишком большая и делает много? Это ошибка архитектуры. Как тестировать такую функцию с данными? Прототипирование по классам эквивалентности входных данных. Вобщем - я не согласен с докладом во многом, по сути это получился доклад о видимости автора на влияние различных (по большой части человеческих) факторов в своем проэкте, которое не несет полезной иформации для других слушателей. Так вот - доклад не вредный, просто из-за неприменимости к нашему опыту - он просто для нас не интересный и бесполезный. Но именно для автора он пользу принесет большую позволив переосмыслить и систематизировать свои знания со временем. Плюс полтора часа работать на публику довольно сложно и девушка вполне с этим справляется. Хоть и тема так себе (именно по моему мнению), но представление отличное. Хотел бы я уметь говорить полтора часа, но к сожалению сказанное мной в основном ограничивается парой предложений. Презентацию из такого не сделаешь.
Спасибо за доклад! Хочется больше детальных материалов по SLT
Настя, это отличный доклад.
Спасибо за отличный доклад .
Провокационный вопрос: если 56% багов от неправильно понятых требований, и неправильно может понять как разработчик, так и тестировщик, значит ли это, что е2е автотест, заменяющий ручной прогон, не гарантирует успеха, если тесты внимательно не посмотрит аналитик?
UPD. Снимается, досмотрел до встречи трёх амиго.
Идеальный мир.
Ужасный и вредный доклад, полностью оторванный от реальности.
Нужны аргументы, а не пустословить
Это прекрасный пример как должно быть и как у некоторого кол-ва команд это действительно работает
Молодой человек чтобы обсуждать что-то основательно - надо чтобы в докладе была идея и хорошие мысли
Пока что в этом докладе только салат из кусков различных идей из интернета, книг и прочего - ничего из этого не связано с реальной работой
Самый очевидный пример того что автор далёк от тестирования это 41я минута и пример того как приложение тестировалось набиванием неправильных тестовых данных в базу. На реальном проекте тестировщику бы объяснили что он не прав, а не хвалили какой он молодец как он красиво делает
Автор я. Реальная работа есть - мои проекты. Иначе откуда бы взялся доклад?
В начале доклада я сказала, почему мы не рассматриваем сдвиг на примере промышленного приложения. Я бы не успела показать сдвиг от начала до конца.
Частично согласна с комментарием, что в реальной жизни возможно не стали бы набивать базу некорретными тестовыми данными. И это касается именно e2e сценариев.
И я этот пример использовала, как один из наиболее ярких и понятных тестировщикам, даже джунам. И при этом я все-равно считаю, что на уровне юнит-тестов все-равно должна стоять "защита от дурака" и такие тесты, проверяющие корректность содержащихся данных в БД должны быть. Эти тесты являются ведь еще и спецификацией к коду и продукту.
Вредных докладов не бывает. Любая информация ведет либо к ошибке либо к успеху. И на том и на другом можно учиться. Хотя я так и не понял, зачем для всего этого вводили новый термин. Идея такая же как у Канера в 80-х, чем раньше тестируем - тем дешевле цена ошибки. Разница с ТДД только в том что код рефакторить не хочется? Это ошибка планирования. Функция слишком большая и делает много? Это ошибка архитектуры. Как тестировать такую функцию с данными? Прототипирование по классам эквивалентности входных данных.
Вобщем - я не согласен с докладом во многом, по сути это получился доклад о видимости автора на влияние различных (по большой части человеческих) факторов в своем проэкте, которое не несет полезной иформации для других слушателей.
Так вот - доклад не вредный, просто из-за неприменимости к нашему опыту - он просто для нас не интересный и бесполезный. Но именно для автора он пользу принесет большую позволив переосмыслить и систематизировать свои знания со временем. Плюс полтора часа работать на публику довольно сложно и девушка вполне с этим справляется. Хоть и тема так себе (именно по моему мнению), но представление отличное. Хотел бы я уметь говорить полтора часа, но к сожалению сказанное мной в основном ограничивается парой предложений. Презентацию из такого не сделаешь.
@@ArturKorobeynyk смотри вон какой комментарий написал) Напиши речь, подготовься и тоже сможешь так