Rost

НЕобходимость есть, только в Беларуси. Что предложите?

Есть корпоративный формат и открытый формат. Что Вас интересует? Можем перейти в личку или пришлите Ваш запрос на info@qaexpert.ru

Как то резковато Вы про эти курсы отзываетесь

Про сами курсы я не отзывался. :-) Я про обложку, на которой продаются курсы, высказал свое мнение. Вы считаете иначе?

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

По двум причинам:
1. Я тоже надеюсь, что все всем ответили. Но если у кого-то есть желание продлить данную ветку, которая ушла от начального более технического вопроса "Хотелось бы узнать какие функции в нем вы считаете нужными а какие так себе ))", к философии о том, что кому по карману. Очевидно, что такие темы стоит обсуждать в клубе.
2. "Модератора прошу последующие посты не по теме топика считать флудом и принимать соответствующие меры!!!!"

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

ЮстусТретий и slat, предлагаю вам перенести возникшую ветку обсуждения в более подходящее место, например, сюда.

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

Послушайте Алексея. Выкладывайте резюме, проходите первое собеседование по телефону. Если все согласны, приезжайте на посмотреть компанию. Это совсем другой уровень, по сравнению с фрилансом. Да и во фрилансе немало проблем: нечестные работодатели, проблемы с переводом средств, с получением, небольшие, чисто организационные, моменты: нет стажа, который можно показать и т.п.
Более того, уверен, что большинство компаний, находящиеся на этом форуме люди знают и помогут Вам с оценкой надежности и стабильности оной.
Ну а если Ваш потенциальный работодатель еще и поможет с переездом, то останется только решиться. :-)
А через 1-2 месяца вы привыкните и все встанет на свои места. Все не так страшно, как кажется. Считайте это командировкой. :-)

It would be a mistake to redefine your mission more positively, as someone who verifies that the program works. Even if "verify that the program works" is handled to you as your mission, advise your client that such verification is impossible. It's hideously expensive. Unless you run every possible test, you can't prove the product works. The best you could say is "For the tests I performed, I didn't notice that the product didn't work". The opposite, however, is marvelously economical: With as little as one test, you can shown that the product doesn't work.

Cem Kaner, in the "Lessons Learned in Software Testing"

Спасибо за цитату. Теперь нехватает только определения самого Канера, что есть целью тестирования. :-) Думаю Ольге очень познавательно читать и думать над такими вот абзацами.
А почему Вы сделали вывод из этого абзаца, что "Ваша цель как тестировщика - доказать, что программа не работает, или работает плохо, или просто она противная и бяка." Нет, я понимаю Вашу цель - доступно донести до начинающих специалистов светлую мысль. Но вот почему именно такая суть, не понимаю.
Я полностью согласен с Канером, что проверять работоспособность системы это безыдейное занятие, тем более в разрезе "run every possible test" и без упоминания о проверке некорректной работы.
Замечу только, что это никак не расходится с тем, что я написал "Цель/задача тестировщика проверить программный продукт на соответствие требованиям". Как вы это делаете, запускаете только позитивные тесты, запускаете только негативные либо и те и те, все возможные или достаточные для заключении о готовности ПО к запуску в продакшн, повторюсь "вопрос лично каждого".

Мы сейчас рискуем свалиться в рассуждения о философии тестирования. Попробую ограничиться лишь следующим:

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

Не, думаю что мы дойдем до рассуждений о философии. :-)
А чем отличается п. 2 от п. 3? ИМХО по сути ничем, только по форме изложения. И я таки с Вами соглашусь. Пока что я не совсем понимаю, почему Вы так привязались к слову требования. Для меня и user guide - требования к продукту если нет ничего больше. И по этим "требованиям" я буду работать, если ничего больше нет. Именно это я и пытаюсь донести до Ольги, что есть программа, есть описание того, как она работает. Вот по описанию и пишите тестовые случаи. Что не понятно спрашиваете у разработчиков.

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

Абсолютно с Вами согласен (я не про НАСА :-)). Надо думать, особенно если на входе только руководство пользователю. Оттуда можно взять поведение, а все остальное необходимо предполагать и интересоваться у ответственных лиц, правильно ли ты предполагаешь. Можно еще посоветовать попросить ПМ'а провести ряд презентаций самого продукта для тестировщиков. Можно даже спонтанных. Цель - донести до тестировщиков поведение системы и ответить на вопросы.

Алексей, я не говорю о конкретной модели тестирования. Я говорю о миссии/цели тестирования. Что, в конечном счете, необходимо проверить все ли правильно реализовано, а не доказывать что что-то не работает. И очень похоже, что мы подразумеваем одно и то же, а говорим разными словами. :-)