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

Есть корпоративный формат и открытый формат. Что Вас интересует? Можем перейти в личку или пришлите Ваш запрос на 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 - требования к продукту если нет ничего больше. И по этим "требованиям" я буду работать, если ничего больше нет. Именно это я и пытаюсь донести до Ольги, что есть программа, есть описание того, как она работает. Вот по описанию и пишите тестовые случаи. Что не понятно спрашиваете у разработчиков.

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

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

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

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

Т.е. фриланс. Есть специальные сайты фрилансеров, на которых ищут работу - Форум фрилансеров

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

Можно взять отпуск.

полагаю, что в моем случае проще начать со step-by-step? тогда возникает другой вопрос: список действий и результатов получиться просто огромный!? ибудет выглядеть так: 1. в поле "номер бланка" вводим слово "кошка" -> результат символы не печатаются -> fail/pass? и так далее...так или не так. не понимаю....

Введите в свой словарный запас еще понятия "позитивный" и "негативный" тест. В двух словах, "позитивный" тест - это тест при котором система себя ведет так, как описано в требованиях/мануале/guide и т.п., что у вас есть. Негативный, это тест, который проверяет работу системы при неверном ее использовании (например в числовое поле попытаться вставить букву).
1. Если у Вас намечается оооочень много тестовых вариантов использования, а времени не много, сперва пишите и проверяйте только позитивные. Это покажет Вам, правильно ли работает программа, как то описано в требованиях/мануале/guide и т.п., что у вас есть.
2. Если есть время на небольшую часть негативных тестов, тогда добавляйте по одному негативному тесту к каждому варианту использования.
3. Если много времени, то делайте полное позитивное и негативное тестирование.

Надо оговорить, что в п.2. стоит сперва выбрать критические части ПО и проверять там негативные тесты в первую очередь. Если на остальные нехватит времени, не так критично.

Не забывайте перед реализацией того или иного пункта обсудить его с руководителем и дать свою оценку по времени. Что-то типа: ожидается около N тестов, время на их написание Т1, время на ревью и корректировку Т2, время на прохождение Т3 (тут прохождение + фиксировнаие результатов + тестовые репорты), время на работу с ошибками в течении полного жизненного цикла ошибки Т4. Итого закончим тогда-то.

Конечно, Вам будет трудно определиться с датами в первые разы. Но за Вас этого никто не сделает. Попробуйте накидывать по 15% времени к каждой фазе. Ну и включайте здравый смысл.
Это если в двух словах. :-)

Кк-то я не понимаю такого "удаленного тестирования".
Не нравится своя работа - меняйте работодателя; а так разрываться - ни там ни там не будет полной отдачи.
имхо.

Частично соглашусь с Вами. Да, работать удаленно имея основное место работы долго нельзя. Точнее можно, но, действительно, очень скоро полной отдачи не будет. Но делать это периодически вполне возможно, например 2-3 недели потестил по вечерам, месяц отдохнул. Еще пару недель пописал тестовые спецификации, пару недель отдохнул. Опять же, если нет семьи, то и в выходные можно по 2-3 часа поработать. На ряду с финансовым вопросом, еще решается и вопрос с практикой.

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

Ну вот Вы и наставляете человека на путь истинный.
Цель/задача тестировщика проверить программный продукт на соответствие требованиям. А уж что вы при этом доказываете, что она работает или не работает, вопрос лично каждого.

Вообще это не я, это почти дословная цитата из Канера.

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

Если вы используете только requirements-based тестирование, то можно либо а) позавидовать ("ура, у них есть спецификации!") либо б) посочувствовать ("если требованиями покрыто только 10% функционала и обновлялись они год назад -- что же протестировали все эти люди?")

М-да... :-)
а) Если у вас нет требований, что же вы тогда проверяете? Точнее откуда вы знаете, что правильно, а что нет?
б) год назад надо было спрашивать разработчиков, а что они, собственно делают? Неубедительно.

А в данном случае требованиями есть "документация - рук-во пользователя и по установке и удалению программы". Чем не требования к тестированию? Все остальное - это домысел как должно работать или предложения, как сделать по другому, но никак не ошибка. Ровно потому что вы не знаете как оно должно быть на самом деле.

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

Ну вот Вы и наставляете человека на путь истинный.
Цель/задача тестировщика проверить программный продукт на соответствие требованиям. А уж что вы при этом доказываете, что она работает или не работает, вопрос лично каждого.

Переписка удалена по просьбе автора

И узнай ещё насчёт Validio, вроде как у них были какие-то курсы.

А давно тренинги в Validio? Когда мы читали тренинги для их специалистов, было немало толковых ребят, так что если они разработали свои курсы, должно быть неплохо.

Up!

Вот наши тренинги по работе с RRobot'ом.

Ресурса по тестированию больше нет.

Вот, материалы остались, а такое мнение уже есть.

Полностью согласен с Сергеем.

Вы согласны что ресурса больше нет, что он умер?
Странно, так значит теперь переводятся скажем вот эти слова с главной страницы:
"Software-Testing.Ru перешагнул ещё одну логическую ступеньку и теперь будет развиваться не только в направлении тестирования и качества ПО, но и как проект о разработке ПО, программной инженерии, информационных технологиях, связи IT и потребностей бизнеса."

Конечно приятно что ресурс по тестированию ассоциируется только с software-testing.ru. Особенно это должно быть приятно Славе. Он над этим трудился не один год. Да и многие ребята тут тоже нашли свою нишу и, спасибо им, помогали нам отвечая на вопросы.

Но все же. Хотелось бы отметить, что под ресурсом по тестированию имеется в виду именно ресурс по тестированию, а не одна из его реализаций. Отсюда повторюсь. Я согласен с Сергеем. Ресурса по тестированию на сегодня нет. И эта ниша освободилась. Конечно, домен softwer-testing.ru зарезервирован, но сотни других softpodtestom.ru, testimsoft.ru и т.д.ru :-) до сих пор свободны.

Отвечая на Ваш вопрос, да умер. Я бы это назвал иначе: перерос; перешел в другую плоскость. Но факт остается фактом, что из узкоспециализированной плоскости тестирования он ушел.

Ресурса по тестированию больше нет.

Вот, материалы остались, а такое мнение уже есть.

Полностью согласен с Сергеем. У всех желающих, теперь, появился отличный шанс сделать живой ресурс для тестировщиков. Слава показал, что это возможно.
Я уже видел два подобных начинания. К сожалению, через месяц-два после старта они оканчивались.
Вывод - "Любовь, это вам не просто так. Ею заниматься надо." (с) не помню кого.

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

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

Уж раз выложили, тогда давайте так как есть.

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

Оба-на. Что бы мне вас не уважать, надо хотя бы, как-то общаться и знать вас не только по форуму. "Иначе зачем же?" (с)
Не понял про не уважение. Тут по подробнее, пожалуйста.

На счет переписать статью, я в предыдущем комменте уже написал, что я думаю про вашу статью. Вполне имеет право на жизнь равно как и моя. Вы хотите вывести формулу профессионализма? За что боремся в данном случае?

Вам вся моя статья не понравилась или конкретный диалог?

Оказалось немного, поэтому отвечаю сразу.

1. Моя статья про людей, которые начинают идти или недавно идут по профессиональной лестнице. Ваша про менеджера. Наши статьи в принципе о людях разного уровня. Это даже из названия видно.
2. Полностью согласен с вашим видением менеджера. Руководитель всегда должен быть на шаг впереди, на голову выше и т.п.
"Он предлагает другие виды деятельности до того момента, когда его сотрудника окончательно заест текучка. Он проводит тренинг до того, как станет очевидной потребность в обучении. Он выбивает хорошие рабочие места потому что так надо, а не потому что об этом просили."
Бесспорно отличный менеджер.

Только я пытаюсь быть более реалистичнее. На мой взгляд у вас описание идеального коня в вакууме. Таких менеджеров, а скорее обстановок, в которых менеджер так сможет себя вести (люди хорошие есть и немало), крайне мало. А на просторах СНГ и вовсе редкие случаи. Чаще всего менеджер либо зажат сроками либо результатами, а иногда и то и другое. В таких ситуациях тоже надо уметь работать профессионально. Было бы неплохо в статье осветить эту сторону работы менеджера. На мой взгляд таких ситуаций гораздо больше чем описанных у вас. Тут, на мой взгляд, на первый план выходит умение менеджера увлечь людей и работать не обращая внимания на мелкие неурядицы. Они всегда сплошь и рядом, как бы вы не огораживались. Это часть нашей жизни.


Мои комменты:
"отфутболил подчиненного" - указал на белые пятна в профессиональном развитии специалиста; указал на узкий кругозор специалиста; указал на отсутствие профессионального подхода у специалиста.

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

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

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

Ну если другого способа нет, то http://blog.shumoos.com/archives/108
Не хотел я ее публиковать до рецензирования и корректуры.

Можно было мне на мыло кинуть. Читаю.
Вы просите, насколько я понял рецензии. За скорую рецензию не ручаюсь, но долго тянуть, так же не буду. :-)

В связи с чем публикую здесь личное письмо к Ростиславу Боруку:
Ростислав, я написал контрстатью на вашу статью "Как стать Профессионалом?".

Есть две проблемы:
1. Я использую ваш диалог. Могу заменить на свой, но мне проще поставить ссылку.
2. Статья вам не понравится.

Поработаем вместе?

Привет Сергей!

Давайте сперва почитаем статью, может и понравится. Где ее можно найти?

Привет!

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

Из личных наблюдений могу перечислить следующее:
...

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

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

...
3. Невозможность ни при каких обстоятельствах приобрести жилье. Причем данная проблема в Белоруссии существует до сих пор.

Почему выбрал Москву:
1. Шире перспективы во всех планах. Море компаний в которых можно развиваться.
2. Русскоязычная аудитория. Адаптация легче на порядки.
3. Интересный город. В плане того, что есть на что посмотреть и есть где провести досуг.
4. Гораздо шире аудитория по интересам.

Все остальное пожалуй вторично.

А как на счет жилья в Москве. Неужели в Москве более реально купить квартиру, чем в Минске?

Хочется всего и сразу? Так бывает, но не очень часто. Как правило, value от подобных переездов сильнее проявляется со временем. Это как перейти из более слабой спортивной команды в более сильную. Сначала условия более или менее те же, но если сможете заиграть в новой команде, то, скажем, за 3 года продвинитесь и по деньгам и в профессиональном развитии дальше, чем за те же 3 года в прежней команде.

+1

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

Да я уже опубликовал в блоге )

Спасибо. Очень понравилось описание персонажей.

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

Добрый день.
Могу посоветовать такой алгоритм:
1. Понять что это;
2. Узнать как это сделать;
3. Проанализировать, только честно, способны ли вы на такое?
4. Принять решение и выполнять его.

Вам стоит написать пару процедур, при чем различной сложности, что бы не было ложного ощущения легкости или сложности этой работы. Конечно стоит начать с простых.
Ну а по результатам сами увидите ответ.