не не не, .вы со своими проверками на ресайзинг окна, на размер картинки, на формат картинки ушли уже не туда.
Для простоты я привел пример только одной конкретной строчки требований на уникальность имени файла, которую вам надо проверить. Вот у вас есть требование:
Если в базе данных уже есть картинка с таким именем, то загружать картинку новую нельзя (для простоты даже опустим требования к ошибке. Просто она должна быть в каком то виде, вам надо именно протестировать уникальность)
Объясните на этом конкретном примере, в чем именно будет отличие работы двух разных тестировщиков с целью проверки соответствия требованиям и с целью найти баги? в чем отличие подходов? в чем отличие кейсов? в чем отличие результатов тестирования? ну и самое главное, по вашему мнению, в чем минус цели по поиску багов?
Как я писал уже, лично по моему мнению отличие тут именно в "настроении", один подход более позитивный, другой более негативный по настрою. Но суть и результат тестирования будут одинаковыми
ну вы же сами в конце пишете: "Надо настроиться на то, чтобы проверить ВСЕ" и при этом пишите, что задача найти ВСЕ баги вас не устраивает, так как она не конечна.
А разве "проверить ВСЕ" конечная задача? Нет, проверить ВСЕ не возможно, так как вы, как минимум, не сможете воспроизвести все комбинации железа и программного обеспечения, которые будут у пользователей на компьютерах и которые могут повлиять на работоспособность разработанного продукта
" Если вы ставите цель "проверить на соответствие требованиями", то автоматически эта цель достижима если достижимы цели:
"требования известны"
"требования полны"
"требования непротиворечивы"
"требования покрыты тест кейсами"
"тест кейсы пройдены" "
Тоже самое будет, если поставить цель "Найти баги". Как человек найден баги, если у него нет требований? Скорей всего никак. Для оформления бага надо знать ожидаемый результат.
А для того, чтобы получить ожидаемый результат, надо чтобы требования были известны, полны, непротиворечивы. Если какие то в голову приходят идеи/улучшения/критика текущего функционала/интерфейса, это доносится аналитику и если аналитик согласится и внесет это в требования, тогда они так же тестируются
Как я уже писал, цель "проверить соответствие требованиям" - слишком узкая и вот она как раз таки не подразумевает, что требования должны быть полными.
К примеру, у вас есть сайт, на который пользователи заходят, загружают картинку с компьютера и она сохраняется в базе с тем именем, с которым загружено.
Требования звучат так: нельзя загружать картинку, если в базе уже есть картинка с таким именем.
Если идти с целью "проверить соответствие требованиям", то достаточно нескольких кейсов, например: а) в базе нет картинки с таким именем, значит загрузить новую можно б) в базе есть картинка с таким именем, загрузить новую нельзя. В целом, требования проверены, можно отдавать в прод
Если идти с целью найти баги, то естественно надо первые кейсы два проверить (когда картинка есть и картинки нет). А раз подошли к задаче уже с критическим настроем, то сразу в голову приходят мысли о том, как можно это все сломать и где разраб накосячить мог. Например, что будет, если два пользователя начали одновременно загружать картинки с одинаковым именем? Или например, я по опыту знаю, что в начале и конце строк обычно обрезаются лишние пробелы, а не накосячил ли с этим разраб? и что вообще имел ввиду аналитик под фразой "с таким же именем"? а если регистр разный? а если загрузка с разных устройств/браузеров, на которых разная кодировка? а если в названии вставится какой то спец символ, который поломает проверку? а не накосячил ли разраб с проверкой пустых имен и файлов с названием null.[расширение]
Вы почему то под целью тестирования "найти баги" подразумеваете, что тестировщик не будет вообще смотреть требования, а будет как обезьянка тыкать кнопки рандомно, лишь бы что то сломать
На самом деле, при собеседовании, если так человек ответил про цель, то не валить его надо, а задать уточняющий вопрос, что он под этим подразумевает и как он баги искать будет
Если это не совсем зеленый джун, то он вам правильно ответит, что "найти все баги" - это значит обеспечить так, чтобы наш продукт полностью соответствовал требованиям, а так же запросам пользователей (это например, если видите косяк в требованиях или знаете, как улучшить пользовательский опыт, то с предложением об улучшении идете к вышестоящему)
Так что, цели "обеспечить соответствие требованиям" и "найти все баги" это одно и тоже, но только разное настроение у этих определений.
Проверить соответствие требованиям - более позитивное определение, которое подразумевает, что у нас все отлично все работает и всего лишь надо проверить, что отрабатывает корректно по требованиям
Найти все баги - негативное определение, которое сразу уже настраивает тестировщика на то, что в нашем продукте баги точно есть и их нужно лишь найти. Для этого надо вычитывать требования и тщательно искать несоответствия
Последнее определение лично мне больше нравится, так как более настроено на плодотворную работу. Хотя, как я и писал уже много раз, оба определения по смыслу означают одно и тоже: проверка соответствия требованиям. Отличие лишь в том, с каким настроением к этой работе подойдем
Еще раз поясню. У вас почему то мышление как у джуна или мидла, что для вас "готовность релиза к проду == соответствие требованиям".
Такая установка как у вас приемлема, только если вы работаете в компании, которая занимается аутсорсом тестирования. То есть, приходит какой то внешний заказчик, приносит вам требования и ваша задача протестировать продукт по этим требованиям и отдать его заказчику. А что уж дальше происходит с продуктом вам пофиг, вы перекидываете ответственность на того, кто вам требования дал
Если вы работаете в обычной компании, которая не аутсорсом занимается, а сама придумывает/разрабатывает/тестирует/поддерживает продукт, то для такого тестировщика главной целью должно быть не "лишь бы требования соблюсти и в прод выкинуть", а цель должна быть в разработке качественного продукта
Может на написание этих требований поставили джуна аналитика, а я тестировщик с 10 летним опытом и глубоким знанием своего продукта и своих пользователей? а может опытный аналитик, но писал требования после жесткого запоя?
Цель хорошего тестировщика не требования формально соблюсти, а выпустить качественный продукт (для чего вообще придется потрудится и сначала все баги из требований вычистить)
Это как спор о курице и яйце. Оба утверждения верны
1) цель тестирования, проверка соответствия требованиям (а как это проверить? правильно, читая требования и ища нескостыковки в реализации)
2) Цель тестирования - поиск багов (а как это проверить? правильно, читая требования и ища несостыковки в реализации)
Оба утверждения верны, нельзя считать ошибкой, если кандидат на собеседовании назвал то определение, которое вам меньше нравится.
При этом, лично мне нравится именно второе определение, что цель тестирования это поиск багов. Я объясню:
В первом утверждении говорится, что цель тестирования это проверка соответствия требованиям. Это подразумевает, что мы на первое место ставим именно требования, до буковки вчитываемся в него и досконально тестируем все кейсы, которые описаны в требованиях. В остальном, придумывание каких то других кейсов, выходящих за рамки требований, на втором плане и не так уж важны
Во втором утверждении, когда цель тестирования это поиск багов. Сразу подразумевается критическое мышление и к реализации и К ТРЕБОВАНИЯМ! Тут уже больше опираешься на знание продукта, знание его конечного пользователя и опираешься именно на это и тестирование начинается именно с поиска багов в самих требованиях. В данной парадигме требования это не конституция и не библия, на которую надо опираться и принимать за чистую монету. В данной парадигме требования это тоже часть нашего продукта, которая тоже скорей всего содержит какие то баги, несостыковки, функционал, неудобный для конечного пользователя
Поэтому, у меня мнение отличное от вашего. Я думаю, чем выше уровень тестировщика, тем больше он должен быть нацелен на поиск ошибок (опираясь на знание конечного пользователя), а не тупо брать за чистую монету требования и проверять соответствие реализации
не не не, .вы со своими проверками на ресайзинг окна, на размер картинки, на формат картинки ушли уже не туда.
Для простоты я привел пример только одной конкретной строчки требований на уникальность имени файла, которую вам надо проверить. Вот у вас есть требование:
Если в базе данных уже есть картинка с таким именем, то загружать картинку новую нельзя (для простоты даже опустим требования к ошибке. Просто она должна быть в каком то виде, вам надо именно протестировать уникальность)
Объясните на этом конкретном примере, в чем именно будет отличие работы двух разных тестировщиков с целью проверки соответствия требованиям и с целью найти баги? в чем отличие подходов? в чем отличие кейсов? в чем отличие результатов тестирования? ну и самое главное, по вашему мнению, в чем минус цели по поиску багов?
Как я писал уже, лично по моему мнению отличие тут именно в "настроении", один подход более позитивный, другой более негативный по настрою. Но суть и результат тестирования будут одинаковыми
ну вы же сами в конце пишете: "Надо настроиться на то, чтобы проверить ВСЕ" и при этом пишите, что задача найти ВСЕ баги вас не устраивает, так как она не конечна.
А разве "проверить ВСЕ" конечная задача? Нет, проверить ВСЕ не возможно, так как вы, как минимум, не сможете воспроизвести все комбинации железа и программного обеспечения, которые будут у пользователей на компьютерах и которые могут повлиять на работоспособность разработанного продукта
"
Если вы ставите цель "проверить на соответствие требованиями", то автоматически эта цель достижима если достижимы цели:
"требования известны"
"требования полны"
"требования непротиворечивы"
"требования покрыты тест кейсами"
"тест кейсы пройдены"
"
Тоже самое будет, если поставить цель "Найти баги". Как человек найден баги, если у него нет требований? Скорей всего никак. Для оформления бага надо знать ожидаемый результат.
А для того, чтобы получить ожидаемый результат, надо чтобы требования были известны, полны, непротиворечивы. Если какие то в голову приходят идеи/улучшения/критика текущего функционала/интерфейса, это доносится аналитику и если аналитик согласится и внесет это в требования, тогда они так же тестируются
Как я уже писал, цель "проверить соответствие требованиям" - слишком узкая и вот она как раз таки не подразумевает, что требования должны быть полными.
К примеру, у вас есть сайт, на который пользователи заходят, загружают картинку с компьютера и она сохраняется в базе с тем именем, с которым загружено.
Требования звучат так: нельзя загружать картинку, если в базе уже есть картинка с таким именем.
Если идти с целью "проверить соответствие требованиям", то достаточно нескольких кейсов, например: а) в базе нет картинки с таким именем, значит загрузить новую можно б) в базе есть картинка с таким именем, загрузить новую нельзя.
В целом, требования проверены, можно отдавать в прод
Если идти с целью найти баги, то естественно надо первые кейсы два проверить (когда картинка есть и картинки нет). А раз подошли к задаче уже с критическим настроем, то сразу в голову приходят мысли о том, как можно это все сломать и где разраб накосячить мог.
Например, что будет, если два пользователя начали одновременно загружать картинки с одинаковым именем? Или например, я по опыту знаю, что в начале и конце строк обычно обрезаются лишние пробелы, а не накосячил ли с этим разраб?
и что вообще имел ввиду аналитик под фразой "с таким же именем"? а если регистр разный? а если загрузка с разных устройств/браузеров, на которых разная кодировка? а если в названии вставится какой то спец символ, который поломает проверку? а не накосячил ли разраб с проверкой пустых имен и файлов с названием null.[расширение]
Вы почему то под целью тестирования "найти баги" подразумеваете, что тестировщик не будет вообще смотреть требования, а будет как обезьянка тыкать кнопки рандомно, лишь бы что то сломать
На самом деле, при собеседовании, если так человек ответил про цель, то не валить его надо, а задать уточняющий вопрос, что он под этим подразумевает и как он баги искать будет
Если это не совсем зеленый джун, то он вам правильно ответит, что "найти все баги" - это значит обеспечить так, чтобы наш продукт полностью соответствовал требованиям, а так же запросам пользователей (это например, если видите косяк в требованиях или знаете, как улучшить пользовательский опыт, то с предложением об улучшении идете к вышестоящему)
Так что, цели "обеспечить соответствие требованиям" и "найти все баги" это одно и тоже, но только разное настроение у этих определений.
Проверить соответствие требованиям - более позитивное определение, которое подразумевает, что у нас все отлично все работает и всего лишь надо проверить, что отрабатывает корректно по требованиям
Найти все баги - негативное определение, которое сразу уже настраивает тестировщика на то, что в нашем продукте баги точно есть и их нужно лишь найти. Для этого надо вычитывать требования и тщательно искать несоответствия
Последнее определение лично мне больше нравится, так как более настроено на плодотворную работу. Хотя, как я и писал уже много раз, оба определения по смыслу означают одно и тоже: проверка соответствия требованиям. Отличие лишь в том, с каким настроением к этой работе подойдем
Еще раз поясню. У вас почему то мышление как у джуна или мидла, что для вас "готовность релиза к проду == соответствие требованиям".
Такая установка как у вас приемлема, только если вы работаете в компании, которая занимается аутсорсом тестирования. То есть, приходит какой то внешний заказчик, приносит вам требования и ваша задача протестировать продукт по этим требованиям и отдать его заказчику. А что уж дальше происходит с продуктом вам пофиг, вы перекидываете ответственность на того, кто вам требования дал
Если вы работаете в обычной компании, которая не аутсорсом занимается, а сама придумывает/разрабатывает/тестирует/поддерживает продукт, то для такого тестировщика главной целью должно быть не "лишь бы требования соблюсти и в прод выкинуть", а цель должна быть в разработке качественного продукта
Может на написание этих требований поставили джуна аналитика, а я тестировщик с 10 летним опытом и глубоким знанием своего продукта и своих пользователей? а может опытный аналитик, но писал требования после жесткого запоя?
Цель хорошего тестировщика не требования формально соблюсти, а выпустить качественный продукт (для чего вообще придется потрудится и сначала все баги из требований вычистить)
Это как спор о курице и яйце. Оба утверждения верны
1) цель тестирования, проверка соответствия требованиям (а как это проверить? правильно, читая требования и ища нескостыковки в реализации)
2) Цель тестирования - поиск багов (а как это проверить? правильно, читая требования и ища несостыковки в реализации)
Оба утверждения верны, нельзя считать ошибкой, если кандидат на собеседовании назвал то определение, которое вам меньше нравится.
При этом, лично мне нравится именно второе определение, что цель тестирования это поиск багов. Я объясню:
В первом утверждении говорится, что цель тестирования это проверка соответствия требованиям. Это подразумевает, что мы на первое место ставим именно требования, до буковки вчитываемся в него и досконально тестируем все кейсы, которые описаны в требованиях. В остальном, придумывание каких то других кейсов, выходящих за рамки требований, на втором плане и не так уж важны
Во втором утверждении, когда цель тестирования это поиск багов. Сразу подразумевается критическое мышление и к реализации и К ТРЕБОВАНИЯМ! Тут уже больше опираешься на знание продукта, знание его конечного пользователя и опираешься именно на это и тестирование начинается именно с поиска багов в самих требованиях. В данной парадигме требования это не конституция и не библия, на которую надо опираться и принимать за чистую монету. В данной парадигме требования это тоже часть нашего продукта, которая тоже скорей всего содержит какие то баги, несостыковки, функционал, неудобный для конечного пользователя
Поэтому, у меня мнение отличное от вашего. Я думаю, чем выше уровень тестировщика, тем больше он должен быть нацелен на поиск ошибок (опираясь на знание конечного пользователя), а не тупо брать за чистую монету требования и проверять соответствие реализации
да как-то и не удивительно уже, ожидаемое поведение от яндекса