Вопрос к тестировщикам
Да, понятно изложено...
Просто я думала, что "качество кода" прямо пропорционально "качеству продукта".
Потом ребята из фирмы, куда я на практику пойду, сказали, что если я их смогу убедить в том, что им нужен тестер, то они меня оставят...Но вижу, что убеждать мне их особо нечем:)). Тем более что они сами свой софт юнит тестами покрывают. Люди пытались "склонить" меня на собеседовании к Mediengestalter и Фронтэнд, но я твёрдо стояла на тестировщике))).
Потом, я отдаю себе отчёт: нужно хорошо знать тестинг( быть минимум миддл), чтобы вводить это в фирму...Поэтому мне было интересно послушать мнение программистов.
Потом, я отдаю себе отчёт: нужно хорошо знать тестинг( быть минимум миддл), чтобы вводить это в фирму...
Это так.
Но вы не расстраивайтесь раньше времени, вы ещё даже не начали работать. Начните, а там осмотритесь по ситуации. В конце концов, если они вас позвали, значит решили, что им это зачем-то нужно.
Тем более что они сами свой софт юнит тестами покрывают.
Юнит-тесты - это вообще не гарантия того, что у них все работает).
Но вы не расстраивайтесь раньше времени, вы ещё даже не начали работать
нет,нет....нисколько. Я считаю, что мне крупно повезло! Сертификат плюс первый опыт (даже 2 месяца), повышают мой шанс найти работу как минимум на 30%. Жаль, что не будет именно тестера, от которого можно было бы быстрее научиться, но ничего страшного. Моё первое впечатление от людей там, очень положительное....
Что работает согласно спекам - может подтвердить и прогер.
Чушь городите. Во-первых, в силу психологических причин разработчик недостаточно критичен к собственной работе. Во-вторых, мир не идеален и формулировка спецификации в том числе. Были у меня случаи, когда программеры интерпретировали реки совсем не так, как я. В итоге получалось, что моя интерпретация верная 
В-третьих, программеры не в состоянии взглянуть целостно на продукт, всегда в подкорке мозга потоки данных бегают, я это из личного опыта знаю. Ваши рассуждения о работе тестировщика - дилетанство, сбиваете только ТС с толку.
От тестировщика, по крайней мере Я, ожидают нахождение имеющихся и потенциальных проблем.
А кто вы такой, что вы что-то ожидаете что-то от тестировщика? 
Что такое проблема в вашей точки зрения? На чем основываться, определяя проблема это или нет? На здравом смысле конкретного человека? Тогда это вообще жесть
См.AlexNek и его упоминания об тестировщице догадавшейся выдернуть кабель...
По вашему тестирование должно быть только негативным? Есть и другие виды тестирования, которые отнюдь не менее важные.
ем более что они сами свой софт юнит тестами покрывают.
Спросите у них, какой у них процент code coverage и branch coverage. Еще можете спросить про цикломатическую сложность Раз у них есть юнит тесты, надо пробовать искать ошибки на уровне интеграции.
Mediengestalter
Это что такое? Оформление какое-то?
Юнит-тесты - это вообще не гарантия того, что у них все работает).
https://tenor.com/view/unittest-unit-test-gif-10813141
Вооо, классный пример 
По вашему тестирование должно быть только негативным?
остальное просто не запомнилось. Да и мне лично какой интерес от того что получен отчет, всё работает как и раньше. Хорошо, замечательно, полезно.
Зато вот когда что то не так это уже интересней, можно и рассказать и запоминается.
С другой стороны, зачем нужен тестер которой будет проверять работу исключительно в правильных "режимах"?
Данная профессия в русском языке называется тестировщик. Я не придираюсь за неимением аргументов, просто режет слух)
Нет универсального ответа, зачем нужны тестировщики. Но давно уже пришли к мнению, что тестировщики проверяет систему на предмет соответствия треьованиям. Цели и приоритеты тестирования в каждом проекте свои. Где-то важна стрессоустойчивость системы (в автопроме бывает такое), где-то это не совсем важно. Негативное тестирование - это одна из методик наряду с позитивным тестированием, тестированием пограничных значений, классами эквивалентности. Если позитивное тестирование не выявило багов, то можно заняться негативным тестированием. А так.. толку от того, что сферический калькулятор не вылетает, если ему вводят буквеннные символы, но не может правильно вычислить 2+3.
Ответа однозначного нет, креативность - это неплохо, но работа тестировщика - это часто рутина, особенно если разработчики башковитые.
ЗЫ вспомнила тут.. во времена разработки мой шеф тыкал в кнопку что питцот раз, чтобы приложение зависло или вылетело. Идиотизъм ж.
просто режет слух
могу вас понять, только русским мы на работе как то не пользуемся. 
бота тестировщика - это часто рутина
Вот за что их и уважаю, я бы на их месте давно бы уже повесился 
мой шеф тыкал в кнопку сто питцот раз, чтобы приложение зависло или вылетело
А чем не нравится? Нормальный способ, на десктопе может и не сильно нужно, но бывают и там подобные глюки
Во-первых, в силу психологических причин разработчик недостаточно критичен к собственной работе.
------
Это - да. И тем не менее именно прогер изначально утверждеает, что сдаваемый код работает согласно спекам.
В итоге получалось, что моя интерпретация верная
-----
Т.е. ты таки СЛОМАЛА то. что наваяли прогеры...
программеры не в состоянии взглянуть целостно на продукт
------
Это - тоже почти ДА.
Дело в том, что при современных объемах ПО вообще никто не в состоянии ЭТО сделать.
Вот свеженький пример:
- прожу. В какой-то момент получю тайм-оут на базе. Спрашиваю - что с базой? - ответ - Все нормально, работает, задержек нет.
- не верю, создаю мини-проект и проверяю подключение - работает.
- возвращаюсь к старому солюшнику - тайм-оут.
Вот теперь взгляни целостно на продукт и ответь на вопрос - где и что не дает законнектится на базу?
По вашему тестирование должно быть только негативным?
-----
В первую очередь - ДА.
Сделать код рабочим согласно спекам - это доступно прогеру.
А вот найти условия при которых он становится нерабочим - это не совсем прогерская задача.
Как-то обсчитывали обработку звука. Там - фурье и куча формул с синусами и косинусами... тестировщика - не было - пришлось самим выяснять где синус становится 1.е+304... Так, кстати, и не нашли - пришлось костылить проверкой, а это - дополнительное время в рассчетаx...
А так.. толку от того, что сферический калькулятор не вылетает, если ему вводят буквеннные символы, но не может правильно вычислить 2+3.
-----
Да-да...
Кстати, а кто должен искать где и как синус становится 1.е+304?
Если прогер - так у него НАПИСАНО ПРАВИЛЬНО - именно так как в документации, все аргументы в допустимых границах, получаемые результаты - заданной точности. Кроме синуса. Он, кстати, не повторим...
И, кстати, тесты в 99.9% случаев будут выполнены корректно.
Кто и как будет искать где и как синус становится 1.е+304?
И, кстати, какое было задание у прогера? Чтобы калькулятор не вылетал когда ему вводят буквенные символы? Ну так он это и делает. Не вылетает. А правильно посчитать 2+3 - другая задача...
но работа тестировщика -
это часто рутина, особенно если разработчики башковитые
-----
Просто башковитым разработчикам нужны башковитые тестеры...
А зачем?
-----
Это меня, прогера, тестер спрашивает зачем тестировать?
Или непонятно что именно будет происходить после двух, при котором первый еще не диспатчирован, кликов по кнопке?
Ну так там не сложно - если нет специальных требований - будут два запроса или две записи - где-то...
Последствия? Да кто же их предскажет...
Проблема: в тестировщики часто идут те, кто не тянет в прожении - квалификация ниже и не позволяет понять где, что и как можно СЛОМАТЬ...
В реальном мире время (=деньги) это ограниченный ресурс, и тратить его на поиск и починку багов типа «тупая секретарша нажала 500 раз на одну и ту же кнопку» - экономически нецелесообразно. С точки зрения бизнеса для 99% приложений (за исключением тех, где надежность суперкритична и нужна защита от дурака всех видов) разумнее инвестировать эти средства в починку более приоритетных багов и разработку новых киллер-фич.
В реальном мире
-----
В реальном прогерском мире код обрабатывающий данную ситуацию пишется ОДИН раз.
В реальном тестерском мире требуется лишь удостоверится, что написанный код используется...
Т.е. обе части надо написать один раз.
разумнее инвестировать эти средства в починку более приоритетных багов
-----
Я сейчас как раз вожусь с кодом в котором чинили более приоритетные баги.
Чтобы понять:
- основой рассчетов является квадратный... местами - линейный вместо квадратного... метр.
- в метрах считать не удобно - перешли к количеству листов (минимальный объем доставки к станку) - там проще - вместо 0.267, 2.763, 1.987 будет 1, 3, 2.
- из листов зачем-то перешли в проценты - видимо менеджеру требовалась обобщенная картинка...
- из процентов - надо было суммировать - снова пересчитали в листы
- а из листов, через метры, - снова в проценты...
Где "сшивали" Я вижу... а вот починить, даже зная что надо считать - все еще не могу - всего в наличии листов - 9, а вот у станка лежит... 1170... толи в выборке не то, толи в процессе пересчета проценты остались...
Чего "стоило" вот такое "починение" - известно - чел слетел с катушек и слег в дурку... Я, похоже, уже тоже на пути туда...
Будем дальше гнать "починку приоритетных багов"? 