Но для кратости сойдёт и негативные.

Вот мне больше нравится про значения

Глубже и понятнее

Правильный ответ на этот вопрос: unexpected.

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

ну есть еще разные испытания системы) у нас вон к примеру новое дроид приложение крашится если несколько раз быстро нажать на кнопку)

Это дефект

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

Т.е. в случае с авторизацией есть expected поведение - пользователь вбил валидный логин пароль -> авторизовался. Есть unexpected поведение -> и тут хренова туча кейсов, начиная от пустых инпутов и заканчивая подстановкой чужой куки авторизации.

а чо негативных?

если пользователь ошибся и ввел логин которого нет в базе или пароль, это тоже негативный кейс

нет никакого unexpected поведения. и то, что ты написал - это и есть главная причина моей локальной войнушки против терминологии

это очень позитивный кейс

самый позитивный из всех в чяте

но получается этой пары нет в базе

отлично, оно тебя не должно пустить - это экспектед поведение, пустит - баг

Если ты не согласен с общепринятой терминологией, и предпочитаешь называть негативные тесты не негативными - это сугубо твоя проблема.

А не проблема негативных тестов.

И мы должны это проверить сразу после валидных данных

а по поводу отсутствия интернета для приложения негативный кейс?

В зависимости от.

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

еслив приложение есть обработка отсутствия интенета и должен быть аллерт то тест негативный?

Если у тебя для отсутствия интернета есть свой позитивный флоу (делается то-то и то-то) - то позитивный. Если у тебя просто 404 на клиент приходит и всё, то негативный.

ещё раз - я утверждаю (и не только я, есть ещё разные дедушки разной степени фундаментальности), что термин "негативный сценарий" - это ложная дихотомия. равно как и "автоматизированное тестирование против ручного)

Я вроде это имел ввиду

Окей, пока во всем мире в рамках Computer Science учат, что error handling -> это обработка unexpected поведения, ваша точка зрения несостоятельна.

Дальше уже пофиг.

вот, видишь - ты играешь с ДАННЫМИ, а не с аутпутом. для сценария самым важным является аутпут. аутпут ВСЕГДА в любом сценарии является ОЖИДАЕМЫМ, мы не можем писать сценарии, ожидающиее неожиданного или плохого/некачественного результата

обработка анекспектед поведения - это позитивный тест эррор эндлинга

это вопрос трактовки - мы пишем "Негативный тест для логин диалога" или "позитивный для обработчика ошибок"?

Вообще-то input\output, но ладно. Негативные тесты пишутся на обработку ошибок и\или их ненарушение общего флоу.

это из флудилки про негативные тесты, йоу

это вопрос трактовки - мы пишем "Негативный тест для логин диалога" или "позитивный для обработчика ошибок"?

о, итог хорош

это не итог

сча я ещё моар ввалю

там просто Шу не идёт в этот чят и потому случилось там, но я считаю, что ето вопрос тестдизайна и надо сюды

да, кидай, интересно)

нет интерента должен быть аллерт, тогда это становится негативным

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

Йеп.

а тут позитивный был\

иди я не так понимать

ну есть приложухи которые и без интеренета норм работают)

Ну, если тебе в рамках приложения _необходимо_ подключение к интернету - то его отсутствие это негатив тест.

Если в зависимости от его наличия\отсутствия меняется поведение приложения -> это позитив тест.

С ожидаемым результатом

к прмеру есть оффлайн игра, а онлайн нужен только чтоб постить набранный скор

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

это проверка функционального требования функционала "ограничение работы в оффлайн режиме"

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

опиши покрытие, раздели функционалы

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

неважно ты назовёшь это "негативное" или "стрессовое"

кстати, стрессовое тестирование - всё негативное

ой ой - по моему тут смешали разные понятия

никто ничо не мешал )))

ой ой - по моему тут смешали разные понятия

а где смешали?

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

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

ну понятия Негативного и Позитивного тестирования с Техниками тест дизайна

я их наверное зацепил целиком

ну понятия Негативного и Позитивного тестирования с Техниками тест дизайна

Если бы смотрели внимательно, то, наверное поняли что там сначала даётся база, а потом уже про тест дизайн.

Соглашусь с Ромой... ЧТо негативные, что позитивные, результат один - корректное поведение системы

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

иначе покрывать тестами невозможно

ERROR: S client not available

"обязаны" я бы заменил на "желательно знают"

Вышел ГОСТ 25010-2015. Ура!

Если что: http://software-testing.ru/forum/index.php?/topic/34476-mitap-seminar-sovremennaia-klassifikatciia-vid/?p=158233

Звиняйте хловцы, но файл прикрепили в эту ветку, а не в отдельную.

Вышел ГОСТ 25010-2015. Ура!

эта штука для чего нибудь кроме тендеров нужна?..

Естественно. Это скелет вашего проекта. Контроль атрибута качества вы либо пишете в план проекта, либо в план управления рисками.

https://www.youtube.com/watch?v=R4byO4dqOHU

Расходимся

На основе этого документа (ГОСТ) вы пишете http://blog.shumoos.com/archives/267 И это очень сильно помогает.

Хм, раньше писали план тестирования и помещали в него *то что нужно*, теперь : *то что в ГОСТе* ? я не очень верю в такой подход... ... разве что это нужно для тендера.

Расходимся

Норм, спасибо за ссылку )

https://www.youtube.com/watch?v=R4byO4dqOHU

не увидел, как там assert выглядит ?

Расходимся

лихо!

Эх, во фри-версии можно только win10/chrome

Хм, раньше писали план тестирования и помещали в него *то что нужно*, теперь : *то что в ГОСТе* ? я не очень верю в такой подход... ... разве что это нужно для тендера.

Как бы это помягче сказать. Предшественик этого ГОСТ-а, ГОСТ 9126 включен в книгу Савина, тренинги Баранцева и т.д. Вчера на семинар пришло много профи в тестировании. Они крайне высоко оценивают ГОСТ 25010.

"обязаны" я бы заменил на "желательно знают"

нет, обязаны, не знают = вон из профессии

Не знают - надо узнавать и учиться, а не вон)

ну ответ был на "желательно". учиться само собой. просто это не опция, а мастхэв

кликеры ничем не обязаны

Расходимся

50 уе/мес, тестовый прогон 1 и всё расходимся, даже не интересно

надо создавать отдельный чат "обязанности тестировщика"

тестировщик слишком общее понятие конечно

им можно назвать и обезьяну и человека

тестирование - это ит-область, тестировщик - профессия в тестировании

правильнее - инженер тестирования

есть ещё тест-аналитик, есть ещё инженер по обеспечению качества

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

тест-аналитик - тоже

Разделяю боль романа. Многие тестировщики не знают протоколов и кучу еще всего. Пусть они не знают теорию в тестировании лучше, чем не знают про жсон, не могут в апишку. А использование постманов меня вообще убивает.

это вы ещё распознавание речи не тестили )))

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

ну теория тестирования для тестировщика важна безусловно