azShoo

Как уже сказали выше, есть много инструментов для распознавания речи, вам надо использовать их, а не писать свое.
Далее. Предположим, вы распознали голос и получили на выходе, грубо говоря, String переменную с фразой, произнесенной в микрофон.
Тут уже начинаются ваши сложности.
В вашу пользу играет то, что у вас есть N тэгов (заранее встроенных в приложение), по которым распределяются расходы. Например: Еда, Мобильная связь, Обучение, Кредиты, етк. Их число ограничено, не бесконечно и известно заранее.
Дальше ваша цель - составить "словари" для распределения этих String переменных по категориям.
Из сложностей - разный порядок слов, синонимы и просторечия, излишнее и\или недостаточное описание + дефекты распознавания речи.

Решите для себя следующую задачу:
У вас есть 15 текстовых описаний расходов в произвольной форме (начиная от "сегодня я потратил пятьдесят тысяч рублей на баночку вкуснейшей черной икры" и заканчивая "пятихаточка на мобилу").
Вам нужно соотнести их по категориям расходов.
Как? Словари, ключевые слова, максимальное количество совпадений. Как-то так.
Когда закончите с этим - прикрутите распознавалку речи и проблем уже не будет.

Все, что попадает в лоно интернета однажды, остается в нем навсегда.

odesk и только.
Забудьте про русский язык и русских заказчиков вообще.

Я думаю, что есть очень много вопросов, над которым вам надо подумать перед тем, как браться за эту идею.
Как минимум потому, что ваше описание проекта трудночитаемо и слабо понятно.
1) Окей, есть "социальная сеть".
Что там должны делать инди-разработчики?
Завести канал и постить видео? О чем? О геймплее, о разработке?
Или надо постить рекламные посты и обзоры?
Или надо кидать ссылки на гуглплей \ кикстартер?
Или как стим будете прикручивать "каталог" игр?

Что там должны делать пользователи?
Искать и скачивать игры? Читать обзоры\смотреть видосы?
Или генерировать контент с обзорами игр и оценками? Если да, то зачем им это?

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

2) Как вы всё это будете монетизировать?

3) Как вы будете привлекать туда аудиторию, как со стороны разработчиков, так и со стороны игроков?
Чем вы лучше какого-нибудь 4pda или тонны форумов про геймдев? Или раздела рутрекера с инди играми.
Стрим предлагает канал продаж, ютуб - удобный хостинг видео + реклама, кикстартер - краудфандинговую платформу.

Про это даже говорить не хочу:

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

Ибо с безопасностью непонятно что, с мотивацией - тоже (покупаемые ачивки? лол, зачем?!), с условиями получения и вывода - тоже непонятно. В общем вопросов ещё на полтора поста.

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

Зависит от того, чем и как собираетесь управлять.

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

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

Искусственный интеллект? Серьезно?
Ну йомана.

В целом, Сергей, конечно, может быть прав. Вопрос достаточно размыт для того, что бы не иметь правильно ответа вообще.
Как мне кажется, вопрос скорее про п.2 из вашего вопроса (виды тестирования).
В таком случае, наиболее приоритетным перед релизом является smoke-тестирование -> регрессия, т.к. в них покрыты основные требования к уже реализованному.
Т.е. в случае благополучного прохождения smoke и регресси -> вы как минимум убедитесь, что выпускаемый функционал не сломал реализованное ранее (т.е. не сделал хуже).
А дальше, уже, тестирование самого функционала.

Для браузеров с >15% аудитории сервиса - только живые браузеры, при необходимости - виртуалки.
Для остального - сойдет браузерстак.

Алгоритм примерно следующий.
1) Избавиться от счетов в данном банке и порекомендовать знакомым сделать то же самое.
2) Репорт в банк.
В большинстве случаев несет профит только тогда, когда удается выйти на безопасников.
Клуши из саппорта принципиально игнорят такие вещи.
3) Посты в соц. сети, хабр и тематические сообщества.

Если собрались разрабатывать под iOS\MacOS - покупаете мак.
Другие варианты (сборка ханкинтошей и поднятие виртуалок) - танцы с бубном и поиск способа прострелить себе колено, с тем же итогом, вам надоест и вы купите мак.

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

Дальше всё упирается в соотношение "ценность информации" vs "затраты на получение пароля".
Никому не надо получать доступ к вашему компу, что бы открыть зип файл с котиками.
Сделать то же самое, что бы получить доступ к платежной информации ваших клиентов - вполне.

Фактически, большинство способов увода паролей сводятся к:
1) Заставить пользователя его самостоятельно ввести где-надо. Фишинг, снифферы и прочее.
2) Получить доступ к вашему компу\трафику с вашей стороны. Ну, вы поняли. Получили доступ -> открыли текстовый файл (или раздел "пароли" в браузере).
3) Получить доступ к вашим паролям со стороны сервиса. Или атака на сам сервис, или на промежуточные звенья. Когда пароль или иная информация ловится на получении.
Все три варианта в большинстве случаев применяются не "целенаправленно", а к широкому кругу лиц. Нашли уязвимость, заэксплойтили, собрали навар.
Есть конечно ещё брутфорсы, социальная инженерия, пытки паяльником и ещё много радостей. Они уже применяются целенаправленно и почти не имеют смысла для среднестатистического юзера.

И вообще, как Вы этим обходитесь? Пользуетесь автосохранением паролей?

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

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

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

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

В остальном:
1) общее представление о процессе разработки, об технологиях (если веб - клиент серверная архитектура и все дела, если платформа - то почитать об устройстве платформы)
2) теория тестирования: что есть баг/дефект, классификации, как составлять баг репорт. Что такое тест кейсы-тест-степ-тест сьют и прочие умные слова, короче: как писать тесты.
3) тест дизайн: базовые практики на уровне примерного понимания.
4) работа с базой на уровне селектов и прочих простых вещей.