Garm

Опрос, честно говоря, совсем не репрезентативный.

• Градаций мало. Между "плохо владею" и "хорошо владею" — пропасть. Да и "владею в совершенстве" адекватный человек никогда не поставит. По сути три варианта ответа.
• Нет вопроса про сферу деятельности. Мне кажется, специалисты которые тестирующие облачные сервисы будут иметь другие ЗП и скиллсет, в сравнении с теми, кто тестирует САПР.
• Как выше писали, по сути про Web вопрос. 

На выходе получится что-то в духе "плохо владею почти всем из списка, получаю много и в евро с заказчиком из Германии" (потому что тестирую сложные и важные embeded системы в промышленном оборудовании) или "хорошо владею большей частью списка, получаю копейки в рублях с заказчиком из Томска" (потому что я же прошёл курсы по веб-тестированию, не могу же я плохо владеть всем этим из списка).

 

 

 

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

ну вот один тестировщик проработает 5 лет в банке и ещё например в стартапе где будет облачная аппликация, а другой 5 лет игрушки будет тестить

 

к эйчару либо тим лиду придут оба кандидата. На кого будут смотреть как на серьёзного человека?

 

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

 

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

Писать что "development has a low barrier to entry too", это как-то лицемерно. Возможно на западе ситуация иная, но в России стать тестировщиком куда проще чем разработчиком. 

Периодически вижу статьи такого типа, мне они напоминают какую-то форму аутотренинга. Мол, "тестирование — сложно, тестирование — для профессионалов дела, тестирование — это вам не тут"... 

 

 

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

А на деле порог вхождения в тестирование действительно один из самых низких в IT (если честно, не знаю где ещё ниже). Возможно за Западе действительно что-то меняется, но за мой опыт работы в Москве и Питере я видел достаточно людей "тестирующих GUI". При этом да, на "высоком уровне" тестирование требует всего того, что перечислил автор. Лично мне кажется, тут как с гитарой: научиться играть пару аккордов можно за день-два, но чтобы стать мастером нужны годы тренировок. 

В общем, такое чувство что у автора тот самый "комплекс тестировщика".

Тьфу, и правда ведь. Попутал раздел.

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

А вообще, казалось бы, при чём здесь сертификаты если речь о том, как сохранить знания которые не используешь в повседневной работе, а времени на постоянное повторение нет.

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

Продолжать решать задачи, только так. Попробовать найти применение БД на рабочем месте, как вариант. 

Если честно, не совсем понимаю как можно забыть SQL. Можно забыть keyword'ы, но их повторить не долго, сам принцип не меняется же. Ну, сложные запросы и вправду сходу можно не написать.

Моё мнение: если ты пользуешься какими-то технологиями в повседневной работе, укажи их. Любой навык — это плюс. Вполне возможно, что HR будет отсеивать резюме по ключевым навыкам и, допустим, наличие "git/svn/mercurial" (не знаю что вы используете) в резюме позволит тебе пройти какой-то верхний уровень отсева. Также любая совпавшая технология с технологией работадателя, это тоже плюс, так как понижает порог вхождения в компанию.

Касательно дженкинса, советую посмотреть настройки джоб в дженкинсе или туториал какой-нибудь. Это не долго, так как там ничего особо сложного нет, зато понимания добавит. Про VCS, если ты в целом понимаешь как это работает (что такое бранчи, master/trunk, working copy, checkout и т.п.), то этого тоже должно хватать.

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

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

Спасибо за пояснения, но вопрос ещё есть частично

 

Хорошо, а как тогда фраза "писать свой фреймворк на основе fonemonkey api"

если это просто точки входа, как на их основе можно писать другой фреймворк

 

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

Секретаршу (задачей которой является доставка напитков) мы пишем сами, а для реализации этапа "вскипятить воду" используем библиотеку "чайник". Доступ к "чайнику" мы осуществляем через API.

"На основе" можно заменить на "используя". 

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

блин, хочется левый вопрос

3. Писать свой фреймворк на основе FoneMonkey API

 

 

 

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

API — точки входа, которые предоставили разработчики стороннего софта, для работы с их кодом.

Допустим, у нас есть фреймфорк "секретарша", задача которого готовить чай или кофе по настроению начальника. Этот фреймворк использует библиотеку "электро-чайник". Секретарша не знает принцип работы чайника, но у неё есть доступ к методам воздействия на него: включить/выключить, налить жидкость, вылить жидость и т.п. Эти методы воздействия и будут API.

Думаю, после опроса (и особенно после заявлений некоторых коллег про неадекватную вилку) многие призадумаются и пойдут искать себе работу. ИМХО, опрос вполне адекватный. Посмотрим по результатам.

Очень интересно увидеть результат. А то по сообщением складывается мнение, что в МСК ЗП у тестировщиков за 150 тысяч в среднем. Хотя по личному опыту (и опыту знакомых), это не так. Тут хочешь не хочешь, начнёшь сомневаться в себе и задавать вопросы.

 

И интересно, откуда эта "задачка" и каков правильный ответ с точки зрения задающего.

Я ответил примерно как Вы, на что мне сказали следующее:

Это вопрос как раз из области тестирования и мат статистики.

Вопрос имеет вполне конкретный ответ

 

Усомнившись в своей логике решил узнать мнение коллег.

 

А вы задавали уточняющие вопросы? Ну, например, какие 20 багов были найдены и пофикшены? Может быть 7 багов были в архитектуре приложения, из-за чего всё переписывать надо было, а 20 в текстовке где-нибудь. Ну, в таком духе.

А в целом, под таким углом я бы сказал что в программе "А" больше. 

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

Прежде всего, надо добавить структуризацию, тогда проверки станет проще придумывать. Разбей игру на максимально независимые компоненты, а затем дроби их дальше на функциональности. Например:
1. Физика.

   1.1 Перемещение объектов

      1.1.1 Перемещение игроков пешком

      1.1.2 Перемещение игроков технике

      1.1.n ...

   1.2 Взаимодействие объектов

      1.2.1 Столкновения

      1.2.n ...

2. Стрельба 

    2.n ...

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

Вещи типа графики, анимаций, звука приходилось тестировать по-тупому. Т.е. при проверки звука каждый отдельный юнит (я стратегию тестировал) проверялся на вещи в духе: наличие и соответствие всех звуков, уровни громкости, отсутствие зацикливания и т.п. Это несколько уныло, но лично на моём опыте это помогло выявить графические/звуковые баги.

И ещё о мультиплеерности. Тут прямо целый ряд типов проверок всплывает: соединение, хранение информации об игроках, соответствие данных на клиенте и сервере (на клиенте отбавляется 10 хп, на сервере 5,, например), подмена пакетов и прочее. На самом деле поле не паханное.

В двух словах как-то так.

Привет. 

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

Изначально хотел написать про предущий опыт, но вышло с "Войну и Мир", поэтому я постараюсь кратко по пунктам описать общий подход.

В двух словах, как я делал раньше:

1. Получение (полу)готовой документации. Составление в блокноте (физическом) списка того, что стоит проверить, на что обратить внимание, также оценка того, как будет конечный пользователь использовать готовую фичу. 

2. Получение фичи на руки. Первая "обзорная проверка", оценивал насколько всё совпадало с моими идеями до этапа разработки. А разница порой была заметна.

3. Проходил юзер-сценарии.

4. Давал волю фантазии, ходил по "компонентам", и записывал все новые/обновлённые идеи в тот же блокнот, в форме слабо детализированных чеклистов (если детализация сразу не требовалась).

5. Проходил проверки, добавлял новые идеи.

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

На новой работе мне пришлось столкнуться с несколькими вещами:

1. Формализм. Например, в ревью на мои баг-репорты были замечания в духе "здесь больше бы подошло слово 'построить', а не 'создать'" или "войти под учётной записью администратора" вместо "залогиниться под админом". Шаги очень-очень детализированы, хотя аутсорса нет и все сидят рядом. К слову, разработчики в своих репортах пишут гораздо более "свободно".

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

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

Я ожидал чего-то подобного, но не думал что это будет настолько непривычно. Сейчас, собственно, появилась напасть, с которой мне пока не справится. Одним из заданий на испытательный срок является составление тест документации на функциональность. Т.е., у меня есть на руках ТЗ, реализованная версия тоже есть, я по ней должен составить тест-кейсы и пройти их. Я составил требования, написал всякие "введения", "настройку окружения" и прочие "таблицы данных". А вот этапе написания тест-кейсов, как глупо это бы не звучало, я застопорился. Для меня основная проблема заключается в том, что они очень подробны и детальны, что вроде бы хорошо, но я не понимаю как уместить в них все идеи, которые я использую при проверках. Я начинаю писать кейс, а в голове у меня проносится "а что если вот так..?", и я сбиваюсь, потому что это тоже стоит записать, но ведь это будет уже отдельный кейс, и так раз за разом. Сейчас думаю попробовать сделать "по старинке", а на основе готовых чеклистов составить уже кейсы, но по-моему это неправильно. 

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

Прошу прощения за стену текста, но короче как-то не вышло.