В сторону Ugreen не смотри, только если решишь накатывать trueNas или что-то другое. Операцинка от Ugreen очень сырая. Плюс надо будет делать моддиг(менять термопасту, менять кулер) говорю по опыту, у самого dxp4800plus
Если мой endpoint должен принимать int только и я пишу обработчик, который приводит пришедшее значение к int и если это не int то мы выдаём ошибку, а если int - идём дальше - с моей стороны в обоих случаях у нас валидные данные.
Вы же ожидаете, что придет или то или то? Ожидаете :) А если ожидаете, значит данные валидные. Но если вы не обрабатывает ошибки или допустим у вас пришёл отрицательный int, а всегда должны быть положительные и вы это нигде в коде не предусматриваете - то тут уже негативный кейс.
В общем мое видение этой "проблемы": все то, что не предусмотрено в коде - негативные кейсы
Всегда задумывался о том, почему негативное тестирование, это негативное тестирование.
Мы же предполагаем, что юзер может войти в систему с валидными credentials.
НО так же мы предлагаем, что юзер не может войти в систему в плохими credentials.
Так вот почему в первом случае у нас позитивное тестирование, а во втором примере негативное?
Мы же заранее знаем, что юзер не должен войти.
Или же, мы знаем, что если пошлем не валидный userId, то бэкенд вернёт 404 или 400 или 204 или 422 (в зависимости от реализации), то почему этот тест негативный?
Негативное тестирование в моем понимании, это когда ты посылаешь валидные/не валидные данные и сервис ведёт себя совсем не так, как задумывалось
Привет, спасибо за статью, сам работаю в этой сфере с 2006 года. По поводу причин как-то надуто сказано. Типа тестеры во всем виноваты. Мне кажется, вы просто не отрастили яйца 😄 Я буквально 2 месяца назад завернул проект, сказав боссам, что менеджеры сработали плохо, ибо спека отстой. То, что я протестировал работает согласно спеке, НО вот есть куча других проблем, которые в спеке не описаны. Проект ушел на доработку.
Сегодня был митинг, где я тоже нагло сказал, что команда для которой мы делаем апи не предоставила данные, тестирования в релиз не будет. Бай🙂
Все всегда относительно. Я выгорел из-за того, что 80% сотрудников компании не профессионалы. Ну, когда они задают вопрос какой-то, я чувствовал, что становлюсь тупее. В общем ушел в бэкенд, чтоб общаться с более умными ребятами и стало лучше
Я никого не хочу оскорбить сейчас, но раньше авторов таких постов называли "КО"(капитан очевидность)
За последние годы я вообще не видел одного проекта под ваши критерии, скорее всего происходило, как указал автор выше: спека на 1 страницу и 50-60 багов плюс 3 разраба, которые не понимают, чего от них хотят😁
По поводу предсказаний, мне кажется, это гадание на кофейной гуще. Так как не учитывается просто человеческий фактор. Во вторых, если процесс разработка/тестирование стабилен, то среднеквадратичное значение всегда будет уменьшаться или хотя бы не увеличиваться, так как все поставлено на поток.
Ну и ещё вопрос: этот инструмент был создан для QA или для менеджера проекта?
Вы выше писали, что признают Facebook messenger, а теперь пишете, что смс от синих.
Потом вы писали, что подняли "говна" на вентилятор - ну пока только вы подняли.
Мое мнение: чуваки создали железку, чуваки создали софт для железки. У них есть свое видение безопасности, юзер экспериенса - зачем они должны делить API для этого софта? Мне допустим в синие сообщения на много чаще валится спам, чем в обычных смс и если блокировка поможет убрать этот спам - я за.
П.с. вы же не отдаете бесплатно продукты, которые сделали своими руками? Ребята из Apple таким образом зарабатывают деньги и поднимают имидж компании
P.s. смена sms на iMessage не насильственная, так как когда авторизуешься в apple id на iphone, у тебя спрашивают, будешь ли пользоваться iMessage. Плюс в любой момент можно это отключить в настройках.
Я не защищаю эпл, просто с вашей позиции почему-то вам apple что-то должен. Хотя по факту проходите мимо без Айфона ?
А как же проверить -1 или число большее int. Ну и null тоже же надо вкорячить и проверить :)
Попарное тестирование.
Согласен. UI такой ui
Таблицы принятия решений (ТПР).
Никогда почти не делал их за 15 лет работы
По опыту скажу, все проекты разные и единого подхода не будет. Я уже смирился с тем, что пирамида тестирования тоже не всегда применима и верна. Но это все от проекта к проекту
нас просили в офис приходить, хотя бы раз в неделю. Пацаны из Чикаго стали ездить, в итоге весь день на смарку, никто из них не работает. У них там то пицца, то small talks и все
Статья хорошая, но прочитав ее, стало интересно, для чего вы ходите в кафку и что туда складывание? Для чего ходите в базу и так далее?
Ну и по сути, если вы делаете много всяких "запросов", "фиксов" и так далее, то становится немного страшно: а все ли ок у озона? Ибо в компании в которой я работаю, если ребята из тех поддержки приходят с подобными запросами, то значит у нас где-то баг и нужно его фиксить, ну или это запрос новой функциональности.
Ещё из интересного отмечу Ugreen NASync серию.В сторону Ugreen не смотри, только если решишь накатывать trueNas или что-то другое. Операцинка от Ugreen очень сырая. Плюс надо будет делать моддиг(менять термопасту, менять кулер) говорю по опыту, у самого dxp4800plus
Если мой endpoint должен принимать int только и я пишу обработчик, который приводит пришедшее значение к int и если это не int то мы выдаём ошибку, а если int - идём дальше - с моей стороны в обоих случаях у нас валидные данные.
Вы же ожидаете, что придет или то или то? Ожидаете :) А если ожидаете, значит данные валидные. Но если вы не обрабатывает ошибки или допустим у вас пришёл отрицательный int, а всегда должны быть положительные и вы это нигде в коде не предусматриваете - то тут уже негативный кейс.
В общем мое видение этой "проблемы": все то, что не предусмотрено в коде - негативные кейсы
Всегда задумывался о том, почему негативное тестирование, это негативное тестирование.
Мы же предполагаем, что юзер может войти в систему с валидными credentials.
НО так же мы предлагаем, что юзер не может войти в систему в плохими credentials.
Так вот почему в первом случае у нас позитивное тестирование, а во втором примере негативное?
Мы же заранее знаем, что юзер не должен войти.
Или же, мы знаем, что если пошлем не валидный userId, то бэкенд вернёт 404 или 400 или 204 или 422 (в зависимости от реализации), то почему этот тест негативный?
Негативное тестирование в моем понимании, это когда ты посылаешь валидные/не валидные данные и сервис ведёт себя совсем не так, как задумывалось
Привет, спасибо за статью, сам работаю в этой сфере с 2006 года. По поводу причин как-то надуто сказано. Типа тестеры во всем виноваты. Мне кажется, вы просто не отрастили яйца 😄 Я буквально 2 месяца назад завернул проект, сказав боссам, что менеджеры сработали плохо, ибо спека отстой. То, что я протестировал работает согласно спеке, НО вот есть куча других проблем, которые в спеке не описаны. Проект ушел на доработку.
Сегодня был митинг, где я тоже нагло сказал, что команда для которой мы делаем апи не предоставила данные, тестирования в релиз не будет. Бай🙂
Все всегда относительно. Я выгорел из-за того, что 80% сотрудников компании не профессионалы. Ну, когда они задают вопрос какой-то, я чувствовал, что становлюсь тупее. В общем ушел в бэкенд, чтоб общаться с более умными ребятами и стало лучше
Я никого не хочу оскорбить сейчас, но раньше авторов таких постов называли "КО"(капитан очевидность)
За последние годы я вообще не видел одного проекта под ваши критерии, скорее всего происходило, как указал автор выше: спека на 1 страницу и 50-60 багов плюс 3 разраба, которые не понимают, чего от них хотят😁
не все современные кондеи умные, 2 недели назад ставил Daikin split + 2 головы и управление по wi-fi только в мечтах моих
Я вчера от одного руководителя услышал:
>Вот так нужно делать, я в сфере уже 5 лет и так правильно
Извините, но тут отчёт, без конкретных цифр, без выявленных проблем, без путей решения этих проблем.
Спасибо за ответ.
По поводу предсказаний, мне кажется, это гадание на кофейной гуще. Так как не учитывается просто человеческий фактор. Во вторых, если процесс разработка/тестирование стабилен, то среднеквадратичное значение всегда будет уменьшаться или хотя бы не увеличиваться, так как все поставлено на поток.
Ну и ещё вопрос: этот инструмент был создан для QA или для менеджера проекта?
Так, а зачем же вообще оценивать результаты тестирования по численным KPI?
Честно, статью прочитал 2 раза, третий раз быстро пробежал глазами и в целом вообще не понял сути внедрения.
Вот! А эплу под вас нужно подстроиться? ?
Монополии на отправку сообщений нет вообще. Хочешь - sms, telegram, Viber, Whatsapp and etc. ? Выбирай все, что угодно)
Не можешь на android выбрать iMessage? Чья это проблема?
Я не могу на iphone установить два одинаковых приложения, я же не ною всем и не говорю, чтоб iphone был похож на android.
Ну такое себе, как и все эти антимонопольные законы
Эмммммм. В таких случаях я всегда говорю: сделай что-то своё, открой аpi и будь супер крутым мужиком ?
Мои друзья читают и отвечают ?Причем на СМС, хотя у всех есть и телеграммы и прочие мессенджеры. Я проблем таких не испытаю
Погодите, пользователи apple спокойно получаю смс от пользователей android или sms гейтов. Проблем тут 0.
Если эти смс не читаются - это же не проблема apple. Все смс приходят и видны в приложении.
Вы выше писали, что признают Facebook messenger, а теперь пишете, что смс от синих.
Потом вы писали, что подняли "говна" на вентилятор - ну пока только вы подняли.
Мое мнение: чуваки создали железку, чуваки создали софт для железки. У них есть свое видение безопасности, юзер экспериенса - зачем они должны делить API для этого софта? Мне допустим в синие сообщения на много чаще валится спам, чем в обычных смс и если блокировка поможет убрать этот спам - я за.
П.с. вы же не отдаете бесплатно продукты, которые сделали своими руками? Ребята из Apple таким образом зарабатывают деньги и поднимают имидж компании
P.s. смена sms на iMessage не насильственная, так как когда авторизуешься в apple id на iphone, у тебя спрашивают, будешь ли пользоваться iMessage. Плюс в любой момент можно это отключить в настройках.
Я не защищаю эпл, просто с вашей позиции почему-то вам apple что-то должен. Хотя по факту проходите мимо без Айфона ?
Анализ граничных значений.
А как же проверить -1 или число большее int. Ну и null тоже же надо вкорячить и проверить :)
Попарное тестирование.
Согласен. UI такой ui
Таблицы принятия решений (ТПР).
Никогда почти не делал их за 15 лет работы
По опыту скажу, все проекты разные и единого подхода не будет. Я уже смирился с тем, что пирамида тестирования тоже не всегда применима и верна. Но это все от проекта к проекту
нас просили в офис приходить, хотя бы раз в неделю. Пацаны из Чикаго стали ездить, в итоге весь день на смарку, никто из них не работает. У них там то пицца, то small talks и все
Может эндпоинт с параметрами?
Статья хорошая, но прочитав ее, стало интересно, для чего вы ходите в кафку и что туда складывание? Для чего ходите в базу и так далее?
Ну и по сути, если вы делаете много всяких "запросов", "фиксов" и так далее, то становится немного страшно: а все ли ок у озона? Ибо в компании в которой я работаю, если ребята из тех поддержки приходят с подобными запросами, то значит у нас где-то баг и нужно его фиксить, ну или это запрос новой функциональности.
А у нас наоборот, увольняют девелоперов из Люксофта и на их смену берут индусов? Буду страдать