вам и так нелегко.

-----

Именно по-этому у меня требования к тестеру... хммм... "несколько завышенные" - мне нужно чтобы он не только делал рутину - для этого можно взять мартышку, но и мог сказать больше, чем чем Я написал в процессе разработки...

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

починку багов типа «тупая секретарша нажала 500 раз на одну и ту же кнопку»

Вы не правильно понимаете ситуацию. проверяется то совсем не это.

Просто это простейший способ проверить "клиента на вшивость".

Кстати, сегодня столкнулся с двумя интересными явлениями на почве тестирования.

Два разработчика проверили одну задачу - все работает точно согласно описанию. Дают тестирам на подтверждение.

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

Теперь начинаем уточнять задачу, как именно должно быть во всех возможных случаях.

2. Тестировщики постоянно поддерживали таблицу с данными о быстродействии одной части проги при различных алгоритмах использования в зависимости от версии ПО.

Как они это делали было без разницы пока не получил возврат задачи оптимизации с пометкой "разницы в быстродействии не выявлено".

Выяснились интересные вещи.

Быстродействие проверялось с помощью таймера на смартфоне, при этом результаты в таблице были начиная от 300 мс (3 раза мол измеряли и после делили)

Данные были такого размера, что визуальной деградации быстродействия было незаметно.

Измерение с помощью встроенного софт таймера показало время до 100 мс.

Вы сдавали тест на Istqb на немецком или на английском? Получили дополнительные 15 мин, т.к. сдавали на не родном языке? Наш преподаватель говорит, что не положено(для тех, кто прожил больше 1,5 года в Германии). На официальном сайте, однако, говорят что положено тем, кто сдаёт на не родном языке.

Просто, если на 40 вопросов положено 60 мин, то 15 мин не будут лишними (если учесть сложность вопросов и немецкого языка).

я сдавал и рекомендую сдавать только на немецком. Хотя бы потому, что ради вас одного никто не будет дополнительно заморачиваться с английским. Подготовка будет вестись только на немецком и многие термины вы будете знать только на немецком. Кроме того сами вопросы и ответы на подготовке будут только на немецком.

Дополнительные 15 минут брать обязательно, они очень важны.

Достаточно принести и показать российский загран паспорт.

Зы. Я провалил мок на русском, но сдал реальный на немецком. Что как бе намекает на качество перевода на русский.

Понятно.На нашем курсе проблем со сдачей на английском как раз нет, а вот с 15 доп.мин есть)))). Что за бред и из какого пальца он высосал правило про 1,5 года....Это говорит многое о его профессионализме....

Про силлабус на русском - вы правы, читаю оба и отличия заметны (особенно тонкости в формулировках ,что очень важно).

Интересно, как вы находите, Моки в сравнении с реальным экзаменом?

Сам экзамен был сложнее или тот же уровень? Есть платформа с более чем 500 вопросами- симуляторами. Есть ли смысл уделять ей много времени, если времени в обрез...

Вернулся из отпуска и подниму тему :D

Да и мне лично какой интерес от того что получен отчет, всё работает как и раньше.

В этом суть тестирования. Тестирование дает гарантию того, что продукт (фича) работает также, как и раньше. Ручное тестирование штука трудоемкая и дорогая, поэтому придумали тест-планы, кучу различных видов тестирования и методик.

Зато вот когда что то не так это уже интересней, можно и рассказать и запоминается.

Возможно, но скорее всего это просто неэффективно.

Предположим у тебя массовый продукт и примерно 1млн человек использует твой софт. При этом у 90% пользователей проблем нет. Зато у 100 человек хреновая сетевая карта и иногда вываливается сетевой кабель. По опыту могу сказать, что если ошибка регистрируется редко, то ей присвоят минимальный приоритет и руки до нее скорее всего никогда не дойдут. Так стоит ли тратить на это дорогой ресурс? Ведь тестировщик должен убедиться, что 90% пользователей будут довольны.

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

А проблему с выдернутым сетевым кабелем тестировщик зачастую и не может воспроизвести :) Да и юнит-тест тут подходит лучше.

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

Зачем нужен тестировщик, который делает случайные тесты? :)

А проблему с выдернутым сетевым кабелем тестировщик зачастую и не может воспроизвести :)

-----

Если бы это была единственная проблема которую тестер никак не осознает...

Вот еще одна.

Прибежал техник со стороны для обслуживания чего-то там.

Пока делал - прописал себе под что-то ему одному нужное статический ИП.

Сделал - убежал.

А ИП - остался прописанным.

По случаю - совпал с ИПом сервера базы.

Маршрутизатор - умный - обрабатывает ОБА одинаковых ИПа.

Т.е. один пакет кидает на сервер, второй - на хрен знает куда...

Может тестер ЭТО придумать? Какие познания в сетях у него должны быть?

Если бы это была единственная проблема которую тестер никак не осознает...

Так тестеру это и не надо осознавать ;)

Может тестер ЭТО придумать? Какие познания в сетях у него должны быть?

И при чем тут тестирование?

Так тестеру это и не надо осознавать ;)

-----

Правда что ли?

Ну и каким же образом тестера вообще могут дойти до необходимости проверять работоспособность в этих условиях?

Ну а если уж отавать нетещеное - так нах тогда тестера держать?

На уровне "не-е, не работает" - мне не интересно. Т.е. Я это увижу БЕЗ тестера - уведомление об сбое придет.

Мне интересно на уровне - "не работает при потере более 10% пакетов", "не обрабатывается ошибка наличия второго ИП в сети" и т.п.

Ну и каким же образом тестера вообще могут дойти до необходимости проверять работоспособность в этих условиях?

Так это от тестера никто и не ожидает :D

так нах тогда тестера держать?

Задача тестера - убедиться в том, что продукт работает также, как и в прошлый раз. Собственно говоря это задача любого тестирования. Тестер нужен там, где нельзя (ну или слишком трудоемко) выполнить тест автоматически. Тестер - это дорогой ресурс и если рассматривать тестера как "человека для поиска багов", то ресурс этот не только очень дорогой, но еще и с крайне низким КПД.

Тесты делаются для того, чтобы убедиться в том, что система все еще "зеленая". И не важно ручные это тесты, автоматические, юнит-тесты, системные, нагрузочные или еще какие.

Ни один здравомыслящий менеджер не поставит тестировщика "искать баги" :) А если кто-то ставит такую задачу, то этот менеджер просто некомпетентен и должен быть уволен как минимум за растрату денег :)

Я это увижу БЕЗ тестера - уведомление об сбое придет.

После этого уведомления ты должен:

1) создать тест-кейс, в котором будет приходить уведомление о сбое

2) пофиксить баг

3) убедиться, что уведомление о сбое больше не приходит

4) выполнять этот тест всегда

Все должно быть быть проделано именно в таком порядке. При этом тестировщик будет принимать участие на этапах 1, 3 и 4.

Мне интересно на уровне - "не работает при потере более 10% пакетов", "не обрабатывается ошибка наличия второго ИП в сети" и т.п.

Формулируешь то, что тебе интересно в ТЗ, тестировщик делает тест-кейс и прогоняет его всегда.

По моему вы как-то недооцениваете работу тестировщика. Я сейчас на курсах по тестированию.Со мной здесь почти все из программистов.

Тестировщик, например может сделать следущее:

Äkvivalenzklassentest

Grenzwertanalyse

Entscheidungstabellentest

Zustandbasiertertest

Anwendungsbasierte

Anweisungstest

Zweigtest

Pfadtest

Dynamisch-Statischtest

Funktional-nichtfunktionaltest

Это ли не в помощь программисту....и это ещё далеко не половина того, что он может...

Со мной здесь почти все из программистов.

Опять же, тестирование бывает не только ручным (ручное тестирование - это совсем дорого и совсем мало эффективно), но автоматизированным. Более того, именно в сторону автоматизированного тестирования и идет развитие.

Тестировщик, например может сделать следущее:

Можно расшифровки всех этих терминов? :) А то мы будем говорить каждый о своем.

Многие из перечисленных тестов здесь:

https://de.m.wikipedia.org/wiki/Kontrollflussorientierte_T...

на графике показано, что стоимость проектов без тестера и с тестером одинакова, т.к. затраты на исправление багов(без тестировщика)= зарплата тестировщика.

Ни один здравомыслящий менеджер не поставит тестировщика "искать баги"

-----

Ну а кодера - легко поставит писать тесты...

Ну или искать проблему типа описанной выше...

Кстати, а кого он поставит на поиск указанного "бага"? Просто интересно - какой специалист должен этим заниматься...

И... это... Я не здравомыслящий менеджер - т.е. менеджер, который работает с тем набором людей какой ему дают, а всего лишь прогер, которому тестер нужен как расширение фукнционала или на съем части нагрузки. Потому Я буду искать тестера с квалификацией позволяющей выполнить 1) самостоятельно и ко мне прийти уже с достаточно четкой формулировкой проблемы.

1) создать тест-кейс, в котором будет приходить уведомление о сбое

-----

Вот оно самое и есть - создать ситуацию воспроизводящую уведомление об сбое.

Вот и расскажи мне как он это сделает в своей сетке в описанном случае.

И, пойми, меня НЕ интересует факт сбоя или его отсутствия (у тестера) - Я уже имею уведомление и оно достаточно детализированное.

Меня интересует чтобы Я не тратил свое время на поиск того что вызвало данное уведомление. Бо, задавить его Я могу и без тестера.

И - ДА - на вопрос тестера - Что изменилось? - будет дан 100% точный ответ - НИ-ЧЕ-ГО.

В смысле - в софте - ничего. Ничего не инсталилось, ничего не менялось в соурсах, в текущей сети (мною) и на сервере... ни-че-го...

Если ты пишешь юнит-тесты, то то, что описано по ссылке, возможно, тебе и пригодится. Хотя Visual Studio отлично умеет считать coverege и подкрашивать зелениньким "протестированное" и красненьким "не тестированное" :) Есть также статические анализаторы кода, которые показывают в том числи в цикломатическую сложность. Нужно ли все это тестеру? Если ты собираешься писать юнит-тесты, то да. Если программисты будут писать тестируемый код, то это даже улучшит надежность и качество кода.

Занимаются ли тестеры написанием юнит-тестов? Скорее нет :)

на графике показано, что стоимость проектов без тестера и с тестером одинакова, т.к. затраты на исправление багов(без тестировщика)= зарплата тестировщика.

лично у меня этот график вызывает сомнения :) я бы даже сказал, что это полная глупость, т.к. тестировщик не исправляет баги, он вылавливает "отклонения" на ранней фазе. Т.е. наличие тестировщика никак не влияет на стоимость исправления бага.

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

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

Методы тестирования, что я описала относятся не только к White-box testing a также и к Black-box тестингу.А это намного шире Unit или Modul тестирования.Вы не находите?

Мне рано с вами спорить- у меня пока одна теория)))...практики нет...

Но мне кажется, наличие тестировщика по любому повышает процент качества самого продукта...Ведь каждый регрессионный тест (после исправления ошибок) это по сути ухудшение качества софта.Или я не правильно понимаю?

И еще, интересно, есть ли такой автоматизированный тест, который проверит, что переменной дано правильное значение?

В этом суть тестирования.

В этом суть регресионного тестирования, безусловно важного которое и стремятся обычно автоматизировать.

Речь же шла несколько о другом. Зачем мне в единственном экземпляре тестировщик, который кроме регресионного тестирования ничего больше не умеет?

Предположим у тебя....

А не надо ничего предполагать, это довольно хорошо известно, как и предполагаемая среда использования.

Я вот помню нас начальник отдела поддержки хорошо проучил. Писали мы ему письма, расскажите, что плохо, как сделать лучше? А он один раз говорит приходите ко мне с новой версией, я вам все покажу.

Он нам в руки лэптоп, вон говорит стоит устройство делайте, что нужно. Мы ему, а там же стол закрывает половину, может отодвинуть - а он, не так наши клиенты и работают. Каждый попробовал и сразу стало понятно где проблемы.

Да и юнит-тест тут подходит лучше.

Да, интересно, хотел бы глянуть как он воспроизведет туже самую ошибку от винды и это не эксепшион внутри проги.

Зачем нужен тестировщик, который делает случайные тесты?

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

И еще, интересно, есть ли такой автоматизированный тест, который проверит, что переменной дано правильное значение?

Зависит от того что конкретно вы подразумеваете. И на каком уровне работаете? Если на уровне кода, то проблем, не вижу если есть доступ к значению переменной, и если четко определено "правильное значение"

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

Это очень спорное утверждение :) Стоимость исправления ошибки зависит скорее от слоя, в котором была найдена ошибка. Т.е. если ошибка в компоненте низкого уровня, то изменение этой компоненты может повлечь изменения в компонентах более высокого уровня.

Есть конечно еще случай, когда один костыль подпирается другим костылем и так штук 10-20-100 (в зависимости от сложности) костылей. В этом случае исправление самого "нижнего" костыля также может повлечь большие изменения, но в этом случае время обнаружения проблемы также играет слабую роль :) Ну если только за это время еще штук 200 костылей не добавили :) Но тут уж сами себе злобные Буратино и никакое тестирование эту коллекцию костылей уже не спасет :D

Методы тестирования, что я описала относятся не только к White-box testing a также и к Black-box тестингу.А это намного шире Unit или Modul тестирования.Вы не находите?

Я нахожу, что софт должен соответствовать спецификации :) Ну и я не вижу никакого смысла в разделении на white-box-testing и black-box-testing. Собственно говоря, unit-тестирование - это black-box-тестирование ;) А всякие метрики (всевозможные типы покрытия) высчитывает Visual Studio. Кстати "Modul" переводится на англиский как "unit" :)

Но мне кажется, наличие тестировщика по любому повышает процент качества самого продукта...

Я с этим и не спорю :)

Ведь каждый регрессионный тест (после исправления ошибок) это по сути ухудшение качества софта.Или я не правильно понимаю?

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

И еще, интересно, есть ли такой автоматизированный тест, который проверит, что переменной дано правильное значение?

Я не совсем понимаю, что ты хочешь спросить :)

Если речь о какой-то внутренней (приватной) переменной, то ее значение никого не интересует и проверять ее в принципе не надо.

Если речь идет о каком-то состоянии объекта, которое видимо для других объектов, то да, такой тест сделать можно.