Pull to refresh
55
-15
Lilia Urmazova @lilia_urmazova

Expert in Quality Development

Send message

Отбор был, заполняли анкету.

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

Более 50% так и сидят без работы.

Не хочется демотивировать, но по собственным данным Яндекс.Практикума (анализ отчета) после курса "Инженер по тестированию" без работы сидят 84%.

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

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

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

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

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

Спасибо за обратную связь!

В данном случае мы это сделали специально.

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

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

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

Спасибо за обратную связь! В следующем релизе будет исправлено. Если что бага минорная - в этом пункте ничего и не должно было быть, случайно пустой добавился.

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

Увы, это особенности SCORM-формата. В нем невозможно прописать "в текущем релизе этот учебный тест изменился чуть-чуть, прогресс нужно оставить, а вот этот учебный тест поменялся - прогресс по нему нужно сбросить".

Весь мой прогресс исчез. Вы там обновили версию 1.0.0 ?

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

Посмотрите, пожалуйста. Мой ник в вашей базе raidex

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

редкий тестировщик приходит на проект и сразу начинает писать запросы в БД или общаться с Линуксом

...И именно поэтому те, кто учатся по этому учебнику (заочно или очно), попадают в редкую категорию и гораздо реже через пару месяцев после обучения начинают стонать "никуда не зовут". Свободное владение подобным демонстрирует на собеседовании уровень общих способностей и потенциала, даже если Linux/DB именно сейчас на проекте не нужны.

Да и для конкурентоспособного тестировщика тестировать то, что "понятно, как работает" - это как бы норма, а не что-то выдающееся.

Или это чтобы с первой страницы запугать новеньких? :)

В том числе да. Учебник изначально создавался под очное обучение и Linux в одной из первых глав в том числе и служил фильтром для тех, у кого "тестирование это легко, сиди жми мышкой по UI".

Спасибо за добрые слова!

Это небольшая проблема с версткой, пофиксаем в ближайшее время.

Разрешение по вертикали какое? Меньше 1080?

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

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

Во первых суррогатные ключи могут быть и составными.
Во вторых есть еще естественные ключи.

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

полнейшего непонимания руководящего состава

Любой нормальный руководящий состав понимает, что чем точнее дефект будет локализован, тем меньше потратится времени разработчиков (проблему в БД может и админинстратор разрулить) и тем больше компания сэкономит.

Про тестовый стенд уже написали в другом комментарии.

Да, жизнь зачастую сложнее, чем пишут в учебниках для начинающих.
Но:

  1. Тест идет к главе про реляционные базы данных.

  2. Это все-таки скорее исключение, чем правило. Мы при обучении используем подход от простого к сложному и от сложного к частному. Если начинать студентов на первом же этапе грузить возможными частными случаями, то у них в голове будет тотальная каша.

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

"Может быть физически" или "может быть, но за это нужно оторвать руки"?

У нас есть таблица teachers (в тесте она не дублируется, но она есть в предшествующей главе с теорией).
У нас есть таблица exams.
У нас в таблице exams есть поле teacher_id.
В любой нормальной базе данных между exams и teacher будет связь по teacher_id.

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

При нажатии на "Полный экран" в верхней панели эта кнопка не будет видна.

Конечно: https://mentorpiece.education/textbook/

Англоязычный вариант является первоисточником (и создан нами же), но по опубликованной версии (0.0.9) отстает от только что опубликованного русскоязычного релиза (1.0.0).
Отличий, впрочем, не так много: в 0.0.9 нет только одного модуля (Git) и не внесены минорные изменения.

А название полей это просто название полей.

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

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

У Хабра интересный дефект в функционале - Вы написали мне в ЛС, но когда пытаюсь ответить, получаю:

"Пользователь exibite777 запретил личные сообщения".

Просьба тогда сюда написать https://t.me/MentorPiece_consult

Information

Rating
Does not participate
Location
Yerevan, Армения
Registered
Activity

Specialization

20 лет даю компаниям QA-таланты
Lead
From 8,000 €
Training
Quality assurance
Software testing
Change management
Talent Management