Николай

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

Притом в рекомендациях к ISTQB Foundation Level есть очень правильная оговорка: "Не рекомендуется сдавать людям, у которых менее 6 месяцев опыта". Если опыта нет, вы только начали работать или только планируете перейти в тестирование - не идите сдавать экзамен. Вы просто не поймете для чего это было придумано и как это применять в живой жизни.

К слову, ISTQB Foundation во многом основаны на книгах горячо любимого мной Коупланда.

Мне кажется изобретаете велосипед. Полноценных игровых джойстиков для телефонов уже полно в продаже

Чем ваша идея лучше?

Добрый день,

1. Практически уверен, что это незаконно. Эксплуатация детского труда и все такое. После этого пункта уже можно ставить точку, но я добавлю.
2. Вам уже корректно отметили в одном из комментариев, ребенок не составит вам тестовый отчет и вообще сложно будет понять, что именно не нравится. Не нравится, и все тут. Тестирование - это работа, а не просто потыкать по экрану.
3. В играх, детских приложениях и прочем, о чем вы вероятно думаете, я предполагаю, что тестирование на аудитории если и устраивают, то бета-тестами. Для этого распространяют приложение на определенный круг лиц. Например, англоязычные продукты любят сначала любят тестировать в Канаде - аудитория схожа, а страна и количество пользователей меньше. Полученные результаты анализируют. Выборка данных в разы больше, данные по UX по одному ребенку ничего не дадут.

Для бизнес и прочего софта, ваша потенциальная услуга точно будет бесполезной.

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

Дальше больше, посмотреть глазами умирающего, посмотреть глазами утопающего, посмотреть глазами без глаз и так далее.

Посмотрите практику Lean Startup, в интернете много статей на эту тему, хотя подход не является прям универсальным.

Вкратце, до запуска продукта и вообще до кода, сделайте страницу "по-быстрому" на каком-нибудь генераторе Landing Page. Даже, если вы крутой Front-end девелопер, вам это будет дешевле. Распишите планируемую идею, напишите "Скоро будет", добавьте блок "Подписаться" или "Сообщите мне, когда продукт появится". Распространите сайт среди целевой аудитории и оцените "как зайдет", сколько потенциальных первых заказчиков вы получите. Самые активные пользователи отправят вам еще и фидбеки, и пожелания. Можно понять, будет ли вообще все это дело рентабельно и стоит ли свеч.
Классический маркетинг вроде анализа конкурентов, ниши, бизнес-планирования тоже никто не отменял.

Если овчина выделки стоит, то делайте MVP (один или командой зависит от масштабов). Распространяйте его среди целевой аудитории и уже собранной базы подписчиков. Это вам и первые клиенты и фидбеки для дальнейшего роста (или остановки проекта).

А еще бытует мнение (и я склонен с ним согласиться), что если за MVP, то есть первую версию продукта, по прошествию времени не стыдно, то что-то пошло не так.

Если вы хотите больше советов, то:
- Найдите мотивированного напарника. Если вы технарь, то пусть это будет маркетолог/продавец и наоборот.
- Большую команду не стоит привлекать, если вы ее не потянете по деньгам. При этом, найти людей которые работают не только за зарплату, а еще и потому, что ваш продукт им нравится - большая удача, но к этому надо стремиться на первом этапе.
- Оформляйтесь официально, когда стало понятно, что MVP идет удачно. Много есть разговоров на эту тему на самом деле, но если с партнерами не сойдетесь, потом будет еще больнее расходиться. Хотя, если риск неудачи продукта слишком большой, ввязываться в бюрократию/бумажки/юридические вопросы слишком рано тоже не круто и отнимет кучу времени.
- Не привлекайте инвестиции слишком рано, если можете протянуть сами хоть какое-то время. Потом вы будете стоить дороже, а процентом делиться меньшим.
- Не бойтесь меняться на ходу, MVP для того и есть, чтобы нащупать свою бизнес-модель. Есть много примеров, когда выстреливала не основная идея, а побочное ответвление продукта.
- И кстати сразу думайте, как будете отстраиваться от конкурентов.

Вообщем боюсь, вы все равно не послушаете часть советов. Если это ваш первый проект, все равно набьете шишек, чтобы к следующему проекту понять что "MVP за 5 дней" не такая уж и плохая идея :) Проходили, знаем.

UPD. И еще, ваши инструменты на первом этапе:
- Конструктор Landing Page
- Excel
- Mailchimp
- Перейдете к разработке, сразу ставьте что-то для управления тикетами. На первом этапе может быть что-то легковесное типа Trello.

P.S. если не секрет, в какой области идея?

Это один из стандартных шаблонов. Вы можете найти и купить любой такой поискав по запросу "Admin Template" например на themeforest или другом сайте с шаблонами.

Ввязываться ли в работу с шаблонами - это другой вопрос

Рекомендую для начала Коупланда (Copeland). Отличный автор, мало того на нем в том числе построена система сертификации по тестированию ISTQB.

Можно конечно того же Савина почитать.

Проблема системная, и заключается она в том, что на вашем проекте нету нормального Product Owner / Project Manager с опытом в управлении продуктом и командой. Если те люди, которые должны выполнять задачи вышеназванных ролей, являются со-основателями компании или приближенными, то скорее всего изменить что-то будет сложно. Ну разве что они адекватные и до них можно достучаться - тут вам виднее.

Если желание изменить у них что-то появится, то:
1. Сначала надо построить процессы на бумаге. Разработка довольно типовой бизнес-процесс, много где он отлично расписан. Пусть берут основу и дорабатывают под компанию.
2. Потом уже внедрить приложение для управления проектами, которое позволит этот бизнес-процесс сделать исполняемым. То есть пустить его в работу. До этого надо кстати еще подумать, как мигрировать существующие данные.

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

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

Redmine - неплохая условно-бесплатная система управления проектами со своими недостатками. Активно пользовались ей на первом этапе, до выхода нашего приложения в лайв. В Redmine сильная база, но как kn0ckn0ck правильно сказал - она, к сожалению, уже давно практически не развивается. Многие фичи приходится допиливать под компанию, покупать платные плагины. Хотя для стандартных кейсов, при небольшом количестве сотрудников, вполне сойдет.

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

jMeter

Про jenkins / teamcity и другие сборщики уже ответили выше.

Если вопрос чисто организационный: почему тестеры чаще других пересобирают тестовые серваки? То это потому, что когда тикет приходит в тест, его невозможно тестировать, если негде тестировать. Не поднимать же себе локальную версию каждый раз?

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

Речь же идет о сайте, верно? Хотя не так принципиально. Начните с контента: с того, какую информацию вы хотите разместить на своем сайте/проекте. От этого уже пойдет составление технического задания, оно же "ТЗ":
1) Структура страниц: что, где, на какой странице должно располагаться
2) Как будут выглядеть отдельные страницы блоки
3) Какой дополнительный функционал будет подключаться. Например, виджеты обратных звонков.
ну и т.д

Дальше в хорошей студии большую часть всего этого доработают за вас. Сначала вы заполните бриф, ответите на вопросы что и как хотите сделать. После этого менеджер по продукту со стороны студии задаст нужные вопросы по ТЗ и отдаст в работу.

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

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

Что повлияет на цену больше всего, это:
1) Будут ли использоваться готовые клипарты (отрисованные шаблоны векторных сцен) или сцены будут отрисовываться с нуля
2) Сколько будет анимации / эффектов
3) Язык озвучки и качество диктора.
4) Кто будет писать и разрабатывать сценарий

По этим критериям и в зависимости от конторы цены скачут от 150 до 3000 (трех тысяч) долларов за 1,5-2 минутный ролик. Самый бюджетный вариант - это полностью сделанный на клипартах, с непрофессиональным диктором, с эффектами уровня PowerPoint.

Redmine - opensource для управления задачами и проектами. Подойдет вам, раз уж вам так важно использование локально.

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

Плюсы:
- Open-source. Хотя это плюс, который одновременно и минус, но зато позволяет производить доработки.
- Относительно гибкий в настройках
- Достаточно понятный, хотя и устаревший интерфейс
- Расширение функционала плагинами

Минусы:
- Нужно разворачивать и сопровождать свой сервак. Для кого-то это проблема, так как нет специалистов. Мало того, это значительно нивелирует условную "бесплатность".
- На больших объемах данных, пользователей или количестве подключенных плагинов начинает существенно падать производительность.
- Как опенсорс, медленно разрабатывается, какие-то баги проще самим исправить, чем дождаться обновления.
- Scrum/Kanban борды, если это актуально, придется решать плагинами, а они далеко не все огонь.

Другие решения даже не рассматриваете?

-- выучится на тестировщика гораздо проще;

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

Порог вхождения в тестирование ниже, чем в программирование - это правда. Но ближе к Senior-уровню ситуация меняется: хорошим тестером быть дано не каждому. И я даже не говорю по Automation. И не буду говорить что есть три уровня тестеров: Tester, QC, QA (последних вообще мало).

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

Тестирование - во многом:
1) Про умение писать техническую документацию: тест-планы, тест-кейсы, баг-репорты. Писать нужно очень много - это 70 процентов работы.
2) Про коммуникацию. Необходимо общаться и эффективно получать информацию от BA, Dev, Customers, Stakeholders
3) Про способность докапываться до сути и понимать потребности бизнеса. Dev может делать только свой кусочек работы, а QA должен понимать как это работает в целом.
4) Технические навыки и хотя бы общее понимание того, как пишется код - тоже обязательны.

И, в целом, в QA много рутинной работы, с которой не все справляются.

-- знание ООП, алгоритмов, синтаксиса ЯП является бонусом, но не всегда это обязательно;

Чем больше вы знаете, тем больше вы стоите. Конечно ООП нужно знать.

-- тестировщики постоянно востребованы, почти так же как и программисты;

Безусловно

-- почему тогда все не идут в тестировщики, вместо программистов? Из-за любви к программированию? Или лишь потому что программистам платят немного больше?

Читайте выше - работа QA не для всех в виду ее специфики.

-- можно ли устроится тестировщиком после 34 лет (в вакансиях конечно требования к возрасту не пишут, по понятным причинам)? Слышал, что это в основном для молодёжи..

Можно, но сложнее, кто бы вам не говорил иначе. В странах СНГ средний возраст айтишника пока около 28-30 лет, хотя в штатах уже давно значительно выше.

-- правда ли то что тестировщики с опытом работы так же востребованы за рубежом как и программисты?

Да

-- если кандидат пройдёт онлайн курсы тестировщиков, это повысит его шансы при приёме на работу в IT компанию?

Сомнительно. Лучше почитайте Коупланда (Copeland)

-- и верно ли то что раньше (лет 10 тому назад) тестировщиком легче было устроится без опыта, "с улицы"?

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

Я последнее время часто провожу собеседования тестеров. Начал вам подробно отвечать, получилось столько текста, что решил написать на эту тему полноценную статью. Правда там больше информации по найму manual junior. Но на некоторых вопросах посыпется половина и более опытных QA. Разместил ее на спарке в блоге нашего проекта: https://spark.ru/startup/neaktor/blog/31094/nanyat...

Краткое содержание вопросов по самому собеседованию:

• Что такое вообще тестирование?
  
• Что такое blackbox / whitebox / graybox?
  
• Жизненный цикл бага / ПО?
  
• Чем отличается чек-лист от тест-кейса? Когда стоит их использовать?
  
• Виды / типы / уровни тестирования
  
• Техники тест-дизайна. Минимальный набор: Boundary Values, Equivalence Partition, Decision Tables, State Transition. Более продвинутые: Pairwise например. Решите практическое задание по составлению тест-кейсов с применением техник тест-дизайна, которые знаете. Explorative - не в счет
  
• Логические задачи
  
• Вопросы на адекватность. Что делать, если вам возвращают тикет в Reject? Не знаете как тестировать какой-то функционал. Что делать?
  

Отдельно тестовым заданием проверяется оформление дефектов.

Большинство вопросов "открытые", то есть можно остановить соискателя в любой момент и попросить уточнить какие-то делали. Например, "Тестирование производительности? Давайте остановимся подробнее. Какие подтипы знаете? Чем отличается Load от Stress тестинга? Как вы будете проводить тестирование производительности?"

Или вот например еще задача на подумать. Когда тестирование интерфейса является функциональным тестированием, а когда нет? Приведите пример.

Если говорить про собеседования senior, то более технические вопросы обязательны. Артем выше привел неплохие примеры. Но тут можно вообще про много что спрашивать. От как вы будете тестировать API до запросов в noSQL базы. Также у тестеров с опытом спрашивать про матрицы покрытия тестов, тест-планирование, цикл разработки тестовой документации и так далее.

Надеюсь вам поможет.

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

Создавать кейсы вручную этой техникой долго и относительно сложно. Есть специализированные тулзы для этого.