Комментарии 162
На первый взгляд непосредственно по тестированию не больше половины курса...
И в этом его главное преимущество:
Стать тестировщиком не так сложно - сейчас есть множество QA-учебников и QA-курсов. Сложно стать конкурентоспособным тестировщиком. Исходя из этого, в учебник добавили не только всю необходимую базу, но и такие важнейшие темы, как углубленный тест-дизайн, Linux и глубокое понимание трехзвенной архитектуры. Ведь именно это отличает по-настоящему крутого QA-профессионала от простого «нажимателя кнопок».
:-) Преимущество будет... Но только тогда, когда QA специалист не просто пройдет один (два или пять) курсов и узнает что такое БД и Linux (по курсам/учебникам типа вашим), а будет разбираться чем работа запросов в Oracle отличается от "аналогичных" в PostgeSQL (или MS SQL), и почему работа одного и того же (к примеру Java) приложения (на одном и том же сервере) в Windows вызывает другую нагрузку на ресурсы сервера чем в Linux, и по какой причине использование 2 серверов с 16 ядрами CPU может быть менее (или более) эффективно чем использование одного сервера с такими же 32 ядрами CPU....
Вот только попытки "впихнуть не впихуемое" в один курс (или учебник) "пробежав по верхам", а после этого заявлять "мы сделали крутую штуку и после ее вы станете крутым профессионалом!", не очень хорошо характеризует уровень знаний его составителей, скорее характеризует их амбиции... :-)
"Крутой профессионал" - это задание правильной планки и ориентиров, потому что у большинства новичков подход "тестирование - это просто". Полностью прошедший учебник + несколько месяцев интернатуры на реальном проекте будет на уровне "крепкий junior - pre-middle". То что Вы пишите - это "middle+" и пытаться такого специалиста с нуля подготавливать несколько бессмысленно.
А по вашему "middle+" уже такими рождаются? :-)
Скорее "Полностью прошедший учебник + несколько месяцев интернатуры на реальном проекте будет" = "умею работать по шаблону и инструкции, а чему там нас учили уже не помню..."
Примерно как учебники и курсы из серии - "Как заработать миллион за 3 месяца." :-)
Если интересует именно наш опыт проведения интернатур в российских и американских компаних (и их результатов), то могу рассказать.
Если же Вы хотите что-то предложить в плане еще более качественного обучения, то я пока не могу уловить что именно. :)
"Опыт интернатур" - мало кого интересует (исключая тех кто за это получает себе доход)... Работодателей интересуют готовые специалисты требуемой квалификации... :-) Продавать "золотоискателям" "лопаты" рассказывая "сказки о возможностях скорого заработка"- всегда было выгодно.... :-)
а почему бы и да, расскажите, может даже отдельной статьей
такие тонкости не обязательно знать всем тестировщикам подряд. Даже разработчики не все это все знают.
Современные "разработчики" много чего не знают и не умеют... Именно это их заставляет использовать монстрообразные фреймворки которые "еле ползают" на современных многоядерных CPU... Это же проще чем изучать основы и принципы функционирования компьютеров и OS.... :-)
Именно такие "разработчики" пихают в базу "сырые" XML объекты...
:-) Во многом это зависит от требований и условий... Насколько мне известно данные с датчиков баллистических ракет пишутся напрямую на носитель (без OS и fs). А вот для БД "общего назначения" к примеру та же Oracle от таких "финтов" как запись данных на "сырые устройства" (которой пользовалась множество версий) отказывается... По реальным тестам это давало +5% производительности и +25% "гемороя" администраторам серверов БД....
А при чем тут qa? Это даже не все программисты на мой взгляд знают - б/д это вообще свой отдельный мир.
В главе про базы данных в тесте про экзамены ошибка.
Крайне маловероятно, этот модуль был опубликован на английском еще в январе и с тех пор более 4000 студентов его прошли.
Перепроверьте себя, пожалуйста. Если все равно будут сомнения - напишите свою версию в https://t.me/MentorPiece_consult
Английский вариант похож на русский, но не идентичен.
Что такое "Информация о конкретном объекте базы данных" и Информация об атрибуте объекта (например, номер телефонов)" ? И как их сопоставить с понятиями "Строка" и "Поле"?
Я уж не говорю о многозначности понятия "строка" - это поле строкового типа, содержимое поля строкового типа или строковый литерал?
В тестировании сейчас софт скилы правят. Я прошел тех собес в Райффайзен банк на синьора, со 100% результатом, но офер не получил, т.к не хватило проактивности на встрече с командой.
Добрый день! Мне кажется это не так легко, как об этом пишут в интернете. На многих ресурсах говорят, вход в профессию без опыта и без знаний, с нуля-это легко. Я вот сейчас на курсы хожу, и с каждой новой темой, понимаю, что ничего подобного. Для того чтобы действительно быть профессионалом, необходимо приложить много усилий. Особенно если с английским есть проблемы. Здорово, когда люди выпускают такого рода учебные пособия. Спасибо им огромное.
Минусуйте сколько влезет, но боже мой, как вы надоели со своим тестированием. Создали целую мини-индустрию вокруг стандартного процесса разработки ПО, чтобы наживаться на людях, не имеющих образования, с баннерами вроде "освой карьеру в ИТ! Получай 200к в месяц!", раздаете титулы вроде "QA-профессионалов", как будто это вообще что-то значит. Сходи в институт, получи диплом, вот это будет что-то значит. Я может и далек от реального положения дел, но последний раз я проверял, это программист должен тестировать свой код. Это называется "твоя работа". Более тесные интеграции ему может помочь тестировать дев-оп. Какие учебники, какие 40 модулей, включая о Линуксе ?♀️ Ну если есть предложение наверное есть спрос. Полное вырождение индустрии. Когда раньше один профессионал мог в фотошопе нарисовать компонент, сверстать его, написать код и протестировать, теперь это -- дизайнер, верстальщик, дев, тестировщик.
Сходи в институт, получи диплом, вот это будет что-то значит.
Сейчас будет интересная ветка дискуссии про вузы, которые умеют качественно готовить тестировщиков. Десять лет назад их число равнялось нулю и с тех пор ситуация не сильно изменилась.
Более тесные интеграции ему может помочь тестировать дев-оп.
Я может и далек от реального положения дел.
Это именно так.
Когда раньше один профессионал мог в фотошопе нарисовать компонент, сверстать его, написать код и протестировать, теперь это -- дизайнер, верстальщик, дев, тестировщик.
Ооо, вы еще живете в те времена, когда страничка - html код и пару css'ок, а профессионал - человек, прочитавший "Java за 12 часов" во время перелета к заказчику? Эх, славные были деньки...
Самое смешное, что функционал у html кола и пары css будет одинаковым))) но во втором случае будет нода, реакт, девопсер, бандл, мемоизация и куча других странных слов.
У нас был курьез, один из бекеров-старперов, сделал на jquery фронт чтоб тестить бэк за день, а потом выяснилось, что всё разработчики юзают его фронт, а не модный с реактом и дизайнером.
Но больше всего я смеялся, когдафронтер сказал, что под мобилку нужно чото там ме, яц ковырять, а jquery корректно открылся в мобилке, когда реактный фронт разнесло вдребезги.
История забавная да. Но куда впихнуть рекламу, аналитику и т.п.? Как-то давно видел, что в браузере в контру 1.6 играют. Впечатляет...
Самое смешное, что функционал у html кола и пары css будет одинаковым)))
Не очень понятно, что значит "одинаковым"? За последние 10-20 лет добавилась куча семантики в html, функциональность css расширилась и переменными и функциями и анимациями и т.д.
Если это инет магазин, то у сайта функциональность это на каждого входящего генерировать выручку.
Если сайт на html генерит её больше, значит он лучше, даже без семантики и функций в с as.
И что это даёт пользователю? Лет двадцать периодически покупаю билеты на сайтах авиакомпаний. Раньше нужную функциональность прекрасно обеспечивал статический html с формочками и cgi на сервере. Сейчас у всех "веб приложения" со скриптами на клиенте и микросервисами, я от этого вижу только тормоза при отрисовке и запросах к разным серверам, функциональность абсолютно та же.
90% сайтов по функционалу сильно далеко не ушли от того, что было 20 лет назад, а поменялся только дизайн да анимации. Консалтинговая компания, в которой я работаю, попросила своих же консультантов разработать им внутренний портал. Из функционала - календарь, база с данными о сотрудниках, возможность заполнять timesheet и отправлять маркетинговые письма время от времени. Пока там работает 180 человек и рост в 60-70 новых консультантов в год. Вот под это выделили команду из фронтэнда, бекэнда, UI, UX дизайнера и архитекта. Они год делали React+микросервисы в докере+обернули всё в CI/CD на Дженкинсе. И спустя год нихрена не готово. Решили добавить еще разраба - человеку 45 лет, из них 25 лет в отрасли. Он за 4 недели сделал весь тот-же функционал, с тем-же дизайном на чистом JS+CSS+HTML плюс Spring на бэке с Hibernate и Постгресом, добавил Liquibase и всё. Проект билдится и деплоится на GitHub actions за 1.5 минуты в один монолит на VDS, который держит 2900 одновременных пользователей без просадки по времени ответа сервера. При этом покрытие тестами - 88%. И всё это один человек сделал за 4 недели. И код открыл и сразу понял как работает и что где.
Но как я понимаю, выпускникам современных курсов по программированию, не объясняли, что каждая технология имеет своё место применения, и готовый рецепт для высоко-нагруженного онлайн магазина не подходит для внутреннего портала микро-компании. И по-моему опыту, такая фигня происходит повсеместно.
Тут была проблема в постановке задачи. Микросервисы появились, потому что кто-то захотел поддерживать миллионы пользователей и миллиарды запросов. Возможно так было сделано для того, что бы отточить навыки работы с этими технологиями.
Я вот сейчас считаю киллер-технологией для мелких проектов supabase, здесь ты делаешь фронт который ходит напрямую в базу. А бэкэнда как такового нет. Единственное что придется писать больше кода на sql, что бы делать то что раньше делалось на бэке (авторизация и валидация) и если появиться альтернатива sql (например будет больше возможностей у plv8) прототипы будут делаться только так. А когда увидят на дашбордах, что база не справляется будут к ней дописывать микросервисы.
А до микросервисов это было невозможно, по-вашему? А как же SWIFT работал? Они в день такой вал транзакций переваривают, что никаким онлайн магазинам и не снилось.
Микросервисы появились, потому что так проще разделить разработку на команды и ответственность за конкретный кусок функционала. Плюс масштабировать дешевле не всю машину, а маленький кусок, в котором большая нагрузка.
Проблема в том, что микросервисы приносят очень много сложности в проект, которую сильно недооценивают.
Supabase - что только фронтендеры не сделают, лишь бы архитектуру приложений не учить.
миллиарды запросов это внезапно база данных, а не микросервисы. Нагруженность редко в бэке провисает, обычно всё в БД упирается. А там абсолютно пофиг сколько в неё один монолит стучится в 200 потоков, или 200 микро сервисов.
Для таких требования - купили бы какую нить "Джиру" за один день и ещё б сэкономили и время и деньги.
Стоит признать, если б деду поставили сверху бизнс-оунера, дизайнера и проджект -менеджера, он бы тоже через год вплотную к окну авторизации бы приблизмлся)))
Согласуй ДТО между фронтом и бэком, "мне кажется правильно писать commentException, а не exceptionComment", передвинь левее кнопку, а давай в рамках предположения вот так попробуем)))
Когда раньше один профессионал мог в фотошопе нарисовать компонент,
сверстать его, написать код и протестировать, теперь это -- дизайнер,
верстальщик, дев, тестировщик.
Типичная речь деда-гейткипера оторвавшегося от реальности. Или реально сможете сделать какой-нибудь VK/FB/Youtube в одиночку? Или, может, Хабр? Или спутали с сайтами 20-летней давности, где была одна статика, а из "интерактива" – падающий снег и мигающий текст через <blink>?
А ты на реакте сможешь фейсбук/vk/youtube сделать в одиночку чтоль?
Вы частность раздули до межгалактических масштабов, сделали объемный логичный вывод на абстрактном уровне абстрактности, затем всë это применили обратно к предмету обсуждения.
Это нарочно?
это программист должен тестировать свой код. Это называется "твоя работа". Более тесные интеграции ему может помочь тестировать дев-оп.
Разраб написал тест - все работает.
Слили в предпрод - не работает.
Проверили с дево-опсом, нашли причину, поправили, заработало.
Слили в прод, а оно не работает.
Вообще, тестировать силами разраба, по мне так - очень дорогое удовольствие, при условии что стоимость часа работы разраба часто в пять раз выше стоимости часа тестировщика. Писать unit тесты - да, хотя есть и противники этой философии. Но тестирование отдайте человеку, который в этом больше шарит и стоит дешевле.
Когда раньше один профессионал мог в фотошопе нарисовать компонент, сверстать его, написать код и протестировать, теперь это -- дизайнер, верстальщик, дев, тестировщик.
А ещё раньше все в FIDO сидели и Интернета не было..., и вообще в ворде можно было html страничку сделать и выложить и даже "профессионал" не нужен. Время идет, меняется сложность задач, требования к качеству и самое главное - объемы и сроки. Один "профессионал" рисовал, верстал и тестировал один компонент - неделю; сейчас дизайнер, верстальщик, дев и тестировщик - делают это максимум за 2 дня.
Я может и далек от реального положения дел, но последний раз я проверял, это программист должен тестировать свой код.
Программист должен протестировать:
1) какую нагрузку и объем данных сможет выдержать его код и на каком сломается
2) сможет ли какой-нибудь хитромудрый Вася залесть в данные с помощью его кода или нет
3) правильно ли работает его код с базой, брокерами, другими системами и модулями системы, в которой живет его код
Правильно я понимаю?
А unit-тесты, которые проверяют сам "код", разрабы и так пишут сами в общем случае.
Универсальный солдат - это ок, когда ты один, а когда вас таких войско, каждый должен выполнять свои задачи, несмотря на то, что каждый из вас может на том или ином уровне выполнять задачи соседа.
Токарь на заводе не занимается грузоперевозками, термической обработкой, шлифовкой, фрезеровкой и гальваникой. Может он и умеет, но зачем? Он так будет по одной хитроповернутой втулке в неделю точить вместо одной в час, так и с ней процент брака будет, что проще уволить. Если не нравится сравнение разраба с токарем, возьмите инженера-конструктора, принцип тот же.
Порадовало: "Мы намеренно даем ссылки на англоязычные ресурсы, поскольку русскоязычные не всегда соответствуют стандартам качества и актуальности. Для автоматического перевода рекомендуем использовать сервис DeepL(opens in a new tab), использующий нейросети."
Т.е. перевод через сервис DeepL соответствует стандартам качества?
Может быть стоило найти русскоязычные ресурсы соответствующие стандартам качества и актуальности, раз уж взялись за русскоязычный учебник?
В целом неплохо, молодцы.
В 700+ страниц (без учета изображений!) учебника входит только оригинальный качественный контент на русском. И его более чем достаточно для работы QA.
Ссылки на англоязычные материалы даны в конце глав в качестве дополнительного материала для особо инициативных. Переводить эту информацию и включать внутрь учебника не было смысла - иначе он стал бы под 2000 страниц.
На русскоязычные ресурсы ссылки не давались по причинам а) отсутствия 50% тем б) кривому переводу QA-терминов на русский.
В целом неплохо, молодцы.
Спасибо, стараемся!
Это всё понятно. Сама фраза покоробила, получается вроде как DeepL переводит QA-термины на русский лучше чем в русскоязычных ресурсах
Тут определенное подталкивание студента в ту сторону, что совсем без английского ему все равно будет тяжело.
Вариант
англоязычный оригинал + перевод DeepL = возможность сверить криво переведенный нейросетью термин
все-таки лучше варианта
русскоязычный текст с кривым переводом терминов, а в оригинал и не заглянуть что там имелось-то ввиду
Это всё опять же дополнительный материал для инициативных студентов, а они в большинстве понимают что надо.
Тогда может быть лучше было бы написать как-то так: "Мы считаем, что в англоязычных ресурсах более актуальная и качественная информация по QA, поэтому даём ссылки на англоязычные ресурсы и рекомендуем читать статьи в оригинале. В случае плохого знания языка вы можете воспользоваться сервисом автоматического перевода, например DeepL"
Интересно что вас это зацепило. В моем прочтении это "Читайте оригиналы, там хорошо. Не умете в оригиналы - сублимируйте автопереводом. Самый не поганый автоперевод - вот тут."
А про
Т.е. перевод через сервис DeepL соответствует стандартам качества?
даже не возникло мыслей :)
Да, а почему ресурсы должны переводить лучше, чем DeepL? Исковерканные, сленговые переводы сплошь и рядом.
Местами не всё переведено, нужно вычитывать:
"
Important notes
Чтобы эффективно использовать пайпы, пожалуйста, помните следующее:"
для пайпов вроде обще употребимое русское слово есть каналы или конвейер?
Important notes
Да, это косяк. Вычитывалось каскадно в две пары глаз, но...
Спасибо, внесем в список дефектов.
для пайпов вроде обще употребимое русское слово есть каналы или конвейер?
Поднимем этот вопрос на общее обсуждение, но изначально между главным ментором и Linux-ментором был консенсус по "пайпам".
А кратко, на cheatsheet есть? А то 700 страниц читать всё равно никто не будет.
Вы бы хотели лечь на операцию к хирургу, который учился по cheatsheet?
До конца 700 страниц многие успешно доходят, судим по статистике англоязычного учебника.
Большинство столько действительно читать не будет, но потом это большинство говорит "вакансий нет", "устроится нереально" и т.д.
Я ещё хочу чтоб мне клининг дома делала девочка с ВО по клинингу? интернатуры и докторской. Ну не за 3000 конечно... Тыщ за 300, она ж не зря училась.
Не надо путать тестирование сайтов и человеческие жизни.
Не надо путать тестирование сайтов и человеческие жизни.
Конечно же современная медицина никаким ПО не пользуется.
Про известный случай с багой Therac-25 на Хабре писали - но там умерло "всего лишь" два человека.
А вот в базе данных американской FDA по инцидентам с медицинским оборудованием значится 290141 запись, из которых 52% привели к смерти пациента. Какой процент из них относится непосредственно к ПО пусть каждый предположит сам.
судим по статистике англоязычного учебника
А где он? И где можно скачать английский или русский учебник, чтоб закинуть на ноут и уехать на дачу к родственникам отбывать барщину, а в перерывах самообразовываться?
А где он?
https://mentorpiece.education/textbook/
И где можно скачать английский или русский учебник, чтоб закинуть на ноут и уехать на дачу к родственникам отбывать барщину, а в перерывах самообразовываться?
Информация о прохождении тестов сохраняется в БД и поэтому, увы, локальная работа в оффлайне не поддерживается.
До конца 700 страниц многие успешно доходят,
Видимо, у них есть мотивация терпеть интерфейс, где всё двигается, сверкает и вздымается, "как будто вновь оживленО" :)
Первый баг: "Закрыв браузер, вы потеряете информацию о прохождении курса, и вам придется начинать с начала."
(1) в русском языке "неявное тематическое подлежащее" (или как там его называл Микитко?) пока не считается правильным, хотя его употребляют многие (это про "шляпу, смотрящую в окно").
(И да, некоторые лингвисты уже ставят под сомнение разумность строгих правил.)
(2) Так как обе части зависят от "Закрыв браузер", запятая перед "и" не нужна.
Как это читать на электронной книге? Или хотя бы оранжевый учебник "Как учиться"? Может есть где-то гитбук, в который, чуть что, можно и замечания/фиксики пулять?
Увы, только старый добрый браузер.
Тут специальный стандарт, который обычный софт не поддерживает - SCORM. Он содержит разнообразные инструменты проверки знаний. А еще, так как учебник используется и на нескольких профессиональных курсах, позволяет оценки за прохождение тестов из учебника автоматически проставлять в "дневник студента" в LMS.
А вот это большое ничем не занятое пространство внизу - так задумано?
Сайт конечно хорошо, но книга в pdf лучше
Только про QA в этом учебнике ни слова. Даже до QC не добрались. Что мешает просто написать: 100-Year Testing-Textbook
Подожду, пока кто-нибудь скопирует весь текст и соберёт PDF.
Умельцы наверняка найдутся, но а) интерактивные тесты перестанут работать, а это потеря половины идеи учебника б) релизы выходят достаточно часто, а часто пересобирать вряд ли кто будет.
Мы в принципе изначально думали над этой идеей, но выяснилось, что используемый SCORM-редактор под pdf изначально не расчитан и экспортирует его в страшноватом виде.
Забавно, но pdf может содержать внутри себя рабочий JavaScript. Правда не уверен, что с его помощью можно сделать особую интерактивность.
Ну вот навскидку https://pspdfkit.com/blog/2018/how-to-program-a-calculator-pdf/
Выходит скачать сам бесплатный учебник нельзя? Только содержание? У меня например сайты *.ru не открываются без VPN
Если Вы за границей, то может интересней окажется англоязычный первоисточник? https://mentorpiece.education/textbook/
А так в принципе для нас не проблема поднять русскоязычную версию и на не .ru домене.
Я попробовал полистать учебник и хочу высказать своё мнение.
Найдите, пожалуйста, нормального дизайнера/UX-специлиста. Сейчас учебник дико неудобный. Почему он открывается в маленьком фрейме? Почему перед каждым уроком огромные картинки с надписью "ты достоин лучшего образования"? Почему нужно нажимать на кнопки, чтобы догружать урок? Почему элементы страницы появляются при прокрутке? Оно ещё и тормозит. Почему слайды из гугл-документов приходится рассматривать, как китаец из мема шпаргалку?
Из шрифтов тоже какая-то мешанина.
Я бы по такому учебнику учиться не стал, простите.
Посмотрите, скажем, на https://learn.javascript.ru/ — учбник, на котором выросли поколения фронтендеров. Обычные статические страницы, ничего не летает и не всплывает и при этом он гораздо удобнее. Не разу не видел там жалоб "где же модные анимации?"
Спасибо за обратную связь, но мы сможем повлиять только на это (как и писали в другом комменте):
Почему он открывается в маленьком фрейме?
Шрифты и дозагрузка - это особенности редактора. В англоязычном варианте, кстати, шрифты действительно выглядят лучше.
Посмотрите, скажем, на https://learn.javascript.ru/
Не увидели ничего похожего на встроенные тесты и запоминание прогресса. Интеграция с LMS, очевидно, тоже не поддерживается.
Инструментов для "просто красиво сверстать" сейчас тысячи, включая любимые многими Notion и Obsidian. Что же касается выбора функциональных инструментов для онлайн-обучения и поддержки SCORM-пакетов, то выбор крайне невелик. Мы выбрали самый функциональный и user-friendly (другие намного хуже), но он не без недостатков, да.
не пустит тестировщика (тем более джуна) в БД
На ДЕВ-стенде или на специальном тестовом стенде? Да почему же? Вполне себе пускают. SQL-запросы тоже надо тестить.
полнейшего непонимания руководящего состава
Любой нормальный руководящий состав понимает, что чем точнее дефект будет локализован, тем меньше потратится времени разработчиков (проблему в БД может и админинстратор разрулить) и тем больше компания сэкономит.
Про тестовый стенд уже написали в другом комментарии.
В первом же практическом разделе #02.3 Реляционные базы данных: Практика и ДЗ есть ссылки для запуска внешнего приложения, например, 192.168.40.100:8000/flight/search, естественно она не открывается. В прочем в английском оригинале точно также. Вероятно задумывалось, что курс установлен в некоторой аудитории, где это внешнее приложение развернуто локально. Есть вариант как-то исправить? Может есть контейнеры с приложениями?
Учебник предназначен и для самообучающихся студентов и для студентов курсов, использующих этот учебник как основу. Поэтому каждый практический раздел содержит по два блока практики: "Самообучающимся студентам" и "Студентам курсов, использующих этот учебник". Вы сейчас смотрите во второй блок.
Для студентов курсов, использующих этот учебник, развернута "серверная песочница" со всем что нужно для практики:
SSH-клиент для модулей Linux, “Сети” и “Траблшутинг”
СУБД-клиент для модулей “СУБД” и “Траблшутинг”
Веб-браузер и СУБД-клиент для модулей WEB/REST API и "Тест-дизайн и работа с требованиями"
Тестовые приложения Java Auth, Java FTB, Alaska Bears.
Увы, мощностей песочницы хватит только для студентов курсов.
Если найдется инициативное лицо для разворачивания этого хозяйства на более широкую аудиторию, мы готовы предоставить образы.
В идеале, конечно иметь возможность установить это как контейнер Docker с набором необходимых открытых портов локально. Контейнер можно опубликовать в публичный DockerHub. Я работаю системным аналитиком и могу помочь, надо конечно сначала попробовать это сделать самостоятельно. Единственное, что Docker приложения невозможно гарантированно всегда забиндить на конкретный адрес и порт. Для этого можно попробовать в ЛК на курсе дать возможность указать адрес и порты, тогда из приложения будет правильно открываться. В общем, можно попробовать
Пожалуйста, напишите мне в ЛС, свяжу с нашим инфраструктурным человеком.
Зашибись... Уже учебники и курсы стали в докер оборачивать... :-)
Речь, не о курсе, а о том, что самому курсу требуется ряд сервисов для практических заданий и подготовленные данные. Типа кому надо, развернул себе сам, не хочешь - не разворачивай, удовлетворись текстовым описанием. Конечно, если сам курс тоже модульное приложение само-в-себе, его тоже можно упаковать в контейнер и поднять все одним compose-файлом
Проходил пару курсов на Курсере, где домашку предполагается запускать на прилинкованном докер контейнере. И могу сказать, что это супер удобно, намного удобнее, чем самому разворачивать окружение, искать такие же версии библиотек, как у ментора, решать проблемы с зависимостями и т.д. Прогресс в чистом виде.
У Хабра интересный дефект в функционале - Вы написали мне в ЛС, но когда пытаюсь ответить, получаю:
"Пользователь exibite777 запретил личные сообщения".
Просьба тогда сюда написать https://t.me/MentorPiece_consult
Зато в Kuber'е можно забиндить на конкретный адрес и порт
Поразительное преобладание негативных комментариев у поста, где бесплатно делятся результатами большого и, по-моему, полезного труда
Наверное, по-своему логично, что к материалу по тестированию сразу лезут с указаниями на все возможные недочёты — «а чо внизу пустое пространство», «а как это в читалку запихнуть»
Но я для разнообразия хочу просто написать «спасибо»
С одной стороны, конечно, да. Труд, несомненно, титанический. И я присоединяюсь к "спасибо".
С другой стороны, "материал по тестированию", похоже, плохо протестирован.
В оправдение могу сказать только то, что это не учебник в классическом смысле - который написали, один раз хорошо вычитали и дальше он стоит на полке несколько лет.
Фактически менторы вносят изменения в каждую главу после каждого занятия с очными студентами. Плюс от самообучающихся очень активная обратная связь идет. А постоянно "на белую" вычитывать 130 занятий, в которые параллельно вносятся изменения десятком менторов, достаточно сложно. То есть это такой учебник в стиле Agile - очень живой и дышащий.
Соответственно плюс получается в том, что он постоянно актуализируется и дорабататывается. Минус - что могут выскакивать дефекты.
Кстати, очень не хватает функционала как на Хабре - выделить фрагмент, нажать Ctrl+Enter и написать сообщение об ошибке. В тестах по SQL пригодилось бы.
Это инструмент Orphus. Ранее можно было скачать с сайта автора. Сейчас остался лишь как orphus.js в разных местах.
Спасибо!
Критика частично обусловлена тем, что мы сами изначально задали планку. Та же недоработка с версткой с "восьмью айтишниками с суммарным опытом в IT 130 лет" действительно не очень хорошо сочетается.
Так что конструктивная критика - это замечательно, а тренировка Soft skill по "пропусканию" неконструктивной тем более важна для айтишника.
Так это же тестировщики пишут.
Не читал. Пока нет возможности. Но похоже больше рассказ об инструментах, которые не совсем относятся к тестирования. Тестер ими должен владеть, но не нужно их описывать. Только сторону требуемую тестеру.
Тоже удивлена негативу. Люди делятся плодами труда, на двух языках, обновляют.
Авторы, вам большое спасибо! Покидала ссылку на статью знакомым тестерам.
Не смотрел пока сам учебник, но в восторге от содержания. Спасибо за проделанную работу!
Жаль, нельзя прыгать по отдельным темам, чтобы перейти к интересующей теме нужно пройти уже знакомую тему. Правда, для новичков это может быть и плюс
(del)
Посмотрел тест по БД.
Вопрос: 01/04 Сколько внешних ключей содержится в таблице Exams?
Правильный ответ, нет информации, потому в вопросе нет информации о фк. А название полей это просто название полей.
Дальше смотреть не стал, подозреваю, что все остальное так же безграмотно
А название полей это просто название полей.
Базы данных, которые спроектированы так, что поле "teacher_id" в таблице "exams" может обозначать что-то иное, чем первичный ключ таблицы "teachers", слава богу, встречаются исключительно редко и только на "приговоренных" проектах.
При этом тестировщик должен уметь схемы базы данных "читать с листа".
Это может быть колонка без FK
"Может быть физически" или "может быть, но за это нужно оторвать руки"?
У нас есть таблица teachers (в тесте она не дублируется, но она есть в предшествующей главе с теорией).
У нас есть таблица exams.
У нас в таблице exams есть поле teacher_id.
В любой нормальной базе данных между exams и teacher будет связь по teacher_id.
Жизнь и нормальность — два параллельных понятия, но иногда они всё ж пересекаются.
Допустим exams и teachers таблицы из другой системы и они у нас участвуют в интеграции. Чтоб не парить мозг разработчика с отсутствием значения в teachers при попытке добавить новые exams, можно не делать FK, а, например, слать письмо минут через 20, когда должны бы уже были всосаться все teachers, но что-то нашего так и не появилось. Если сделать FK, то такие записи с новым "несуществующим" учителем надо будет куда-то класть и обрабатывать позже.
А если взять ваш подход, то exams внезапно становится таблицей с расписанием экзаменов: какая группа у какого препода какой предмет когда сдаёт. А оценки студентов за экзамены — это уже другая таблица, которая будет содержать exam_id, student_id, exam_points
А в следующем задании в таблице teachers есть subject_id, хотя в лекции написано, что teachers и subjects состоят в отношении один ко многим (а на самом деле многие ко многим)
В любой нормальной базе данных между exams и teacher будет связь по teacher_id.
Как минимум три с половиной варианта для возражения:
FK могут не поддерживаться технически. Например, Hive/Spark.
FK могут поддерживаться, но на уровне всей базы принято соглашение о неиспользовании FK, т.к. данные наполняются из множества источников и даже из одного источника могут литься независимыми потоками. Ну и для ускорения при вставке данных. А контроль связей осуществляется другими средствами.
За свою жизнь я видел всего одну почти нормальную базу данных, но это произошло лишь потому, что эта база всю свою жизнь создавалась и поддерживалась одной командой. Когда база разрабатывается множеством команд, как параллельно, так и последовательно во времени, она всегда становится таким лоскутным одеялом из компромиссов, техдолга, ошибок и т.д.
3.5. Соглашения об именовании полей бывает разные. Например, teacher$id будет FK, а teacher_id - нет (это реальный пример из жизни).
Да, жизнь зачастую сложнее, чем пишут в учебниках для начинающих.
Но:
Тест идет к главе про реляционные базы данных.
Это все-таки скорее исключение, чем правило. Мы при обучении используем подход от простого к сложному и от сложного к частному. Если начинать студентов на первом же этапе грузить возможными частными случаями, то у них в голове будет тотальная каша.
Значит, мне повезло больше. На небольших проектах техлид вполне успевает не допускать техдолг в БД, так как он гораздо дороже, чем в коде. Крупные проекты, где каждая команда сама независимо лезет в общую базу и без согласования создает сущности, мне, слава богу, встречались только два раза.
Если начинать студентов на первом же этапе грузить возможными частными случаями, то у них в голове будет тотальная каша.
При чем тут частные случаи. ФК однозначно определяется на основе метаданных. Нет матданных это не ФК.
А то потом начинаются перлы в стиле у вас teacher_uuid, а надо teacher_id.
Переучивать людей дорого.
"Может быть физически" или "может быть, но за это нужно оторвать руки"?
На основании чего отрывать руки будете? На основе эмоций?
В любой нормальной базе данных между exams и teacher будет связь по teacher_id.
В базе будет та связь, которая необходима для решения задач поставленных перед продуктом, а не потому что у кого то есть фантазии.
Во первых суррогатные ключи могут быть и составными.
Во вторых есть еще естественные ключи.
В базе будет та связь, которая необходима для решения задач поставленных перед продуктом, а не потому что у кого то есть фантазии.
Это неправильный подход. Есть проверенные десятилетиями отраслевые подходы, стандарты и архитектуры. И если для конкретного продукта предлагается нестандартное решение, то это должно быть подтверждено очень вескими аргументами. Потому что на другой чаше весов гениального решения "в нашем случае так сделать было лучше/быстрее/эффективней" - продукт, который потом сложно или невозможно поддерживать.
Во первых суррогатные ключи могут быть и составными.
Во вторых есть еще естественные ключи.
Вы забыли, что речь идет про учебник для начинающих в IT.
Усложнять им картину, рассказывая про пока ненужные им понятия, это примерно как в начальных классах школы говорить, что на самом деле на ноль можно делить.
Это неправильный подход. Есть проверенные десятилетиями отраслевые подходы, стандарты и архитектуры.
Окей, то есть продукт зарабатывает деньги, но это не правильные деньги...
Ccылки на эти отраслевые подходы, стандарты можно? На IEEE, на ISO и ГОСТ?
И если для конкретного продукта предлагается нестандартное решение, то это должно быть подтверждено очень вескими аргументами. Потому что на другой чаше весов гениального решения "в нашем случае так сделать было лучше/быстрее/эффективней" - продукт, который потом сложно или невозможно поддерживать.
Раз пошла речь о стандартах ГОСТ 25010-2015 атрибут качества сопровождаемость, либо вы в него вложились и тогда измения в продукте дешевы либо нет. Это ни как не связанно с тем какие решения вы использовали.
Вы забыли, что речь идет про учебник для начинающих в IT.Усложнять им картину, рассказывая про пока ненужные им понятия, это примерно как в начальных классах школы говорить, что на самом деле на ноль можно делить.
Нет, вообще мимо аналогия. Прочитав ваш учебник человек получает необходимые знания для выполнения работы младшим тестировщиком. А то что я сказал про ключи это база, это словарь и понятия.
Либо у него нет базы, тогда он не может быть тестировщиком, потому что не понимает, что от него хотят. В этом случае, зачем ему читать 700 страниц, когда есть намного более полные и менее объемные учебники....
только на "приговоренных" проектах.
Компания атласиан резко напряглась, поскольку ее продукты стали резко приговоренные
если не прошел тест, то к следующей теме не перейти
Очень раздражает.
Можете опубликовать ссылку на английскую версию, пожалуйста :)
Конечно: https://mentorpiece.education/textbook/
Англоязычный вариант является первоисточником (и создан нами же), но по опубликованной версии (0.0.9) отстает от только что опубликованного русскоязычного релиза (1.0.0).
Отличий, впрочем, не так много: в 0.0.9 нет только одного модуля (Git) и не внесены минорные изменения.
Моё почтение!
Спасибо за релиз, я с июня решил погрузиться в сферу тестирования, с тех пор в процессе обучения попробовал, наверное, все ресурсы, какие может попробовать студент-самоучка. И пока что этот учебник занимается уверенное первое место. Старую версию я прошёл где то на 40%, после обновления мой прогресс на 20.
Про многие ошибки и баги уже написали, но мне, например, это всё не первостепенно, главное совсем другое. Не удивлюсь, если и остальным, кто прежде всего пришёл за знаниями, так же.
Тем, кто пишет, что материалов непосредственно по тестированию слишком мало, тот, скорее всего, просто не знаком с тем, как обстоят дела на рынке труда начинающих QA-инженеров))
Кнопка "Предыдущая версия" отжирает значимую нижнюю горизонтальную часть экрана, и по-сути, мало кому нужна. Зачем она там? Зачем сделано именно так?
Потому что прогресс пользователя перенести в новую версию учебника, увы, невозможно. И у некоторых может быть инфаркт недоумение, когда в один прекрасный день, зайдя по привычному адресу, увидят исчезнувшие результаты месяцев учебы.
При нажатии на "Полный экран" в верхней панели эта кнопка не будет видна.
В результате это было пофиксано.
Это очень хороший материал! Но пожалуйста, сделайте возможность читать любую главу или раздел без тестов. Иначе это онлайн курс, а не учебник. Я не тестировщик, но мне любопытно было почитать последние главы ради теории. Спустя 15 тестов я сдался, т.к. проще взять оглавление и найти другую литературу. Вся прелесть книги в том, что можно открыть интересующую главу и получить информацию, я всегда могу вернуться к предыдущим главам самостоятельно.
Я представляю себе ИИ-учебник: Тесты показывают, что вы плохо усваиваете материал. Лексическая сложность текста снижена до возрастной категории 10-12 лет. Пожалуйста, перечитайте главу "Анализ интеграла Мора" в упрощенном изложении. :)
Спасибо! Колоссальный труд
А что можно почитать не начинающему разработчику для понимания процессов QC/QA?
Меня интересует не то как писать юнит тесты, а как организовать разработку и тестирование чтобы в результате было меньше багов в продакшене.
Очень неудачный выбор платформу для курса. Посмотрите в сторону Udemy, например.
Внимание вопрос. А можно как-то отключить эфект проявления, чтоб сразу текст был? Спасибо.
Судя по темам специалист на выходе будет тестировать сайты и API с SQL базой данных. Понятно, что это ширпотреб, но давайте честно это все первая ступень и скорее всего последняя и никакой это не тестировщик, а прикладник для сайта.
Вторая мысль кто автор учебника? Какой-то аффилированный государственный университет с сертификацией позволяющий учитывать сертификат при приеме на работу или просто левые ребята, которые считают, что их мнение самое лучшее и они лидеры продаж, первые на рынке и т.д. Без обид такие выпуски делают каждый отдел в каждой компании...
Почему выбран текстовый формат. У меня лпаки^W зрение плохое могу я посмотреть видео с примерами?
О, Хабр-комментаторы не подкачали, захейтили сразу все - и книгу, и тестировщиков, и друг друга заодно.
На самом деле да, много вопросов к верстке и к слову "книга" (это реально полноценный курс, а книгу можно было бы читать с любой главы), но главный вопрос - почему такой порядок тем, ведь положа руку на самое ценное - редкий тестировщик приходит на проект и сразу начинает писать запросы в БД или общаться с Линуксом. Но практически сразу ему приходится сталкиваться с тест-анализом, тест-дизайном и так далее. Поэтому и вопрос - почему начинается сразу с технических понятий, которые могут никогда и не пригодиться (хотя сейчас и правда от джуниоров требуется знание всего на свете), а до главного в тестировании - до той самой теории, нужно еще добраться через технические задачки. Или это чтобы с первой страницы запугать новеньких? :)
Вообще учебник дело хорошее, конечно. Из русскоязычного наверное только Ольга Назина делала попытку систематизировать все в книге. А из англоязычного я вспоминаю только учебник Савина (не книгу, а именно учебник по тестированию)
редкий тестировщик приходит на проект и сразу начинает писать запросы в БД или общаться с Линуксом
...И именно поэтому те, кто учатся по этому учебнику (заочно или очно), попадают в редкую категорию и гораздо реже через пару месяцев после обучения начинают стонать "никуда не зовут". Свободное владение подобным демонстрирует на собеседовании уровень общих способностей и потенциала, даже если Linux/DB именно сейчас на проекте не нужны.
Да и для конкурентоспособного тестировщика тестировать то, что "понятно, как работает" - это как бы норма, а не что-то выдающееся.
Или это чтобы с первой страницы запугать новеньких? :)
В том числе да. Учебник изначально создавался под очное обучение и Linux в одной из первых глав в том числе и служил фильтром для тех, у кого "тестирование это легко, сиди жми мышкой по UI".
Спасибо за добрые слова!
по содержанию очень нравится, наверное пробегусь даже, но оформление абсолютно ни к месту. Зачем эти всплывающие строки, кнопки далее и прочая мура? почему нельзя просто текст по человечески вывести?
Я полностью прошёл ваш старый релиз, где было 22 главы. У вас настолько совершенно выстроен процесс разработки новых релизов, что прогресс полностью теряется с выходом нового релиза ( о чём у вас написано в главе 1 ). Итак. Я снова прошёл ( ещё раз ) все 22 главы ( на это я потратил своё время ). Т.е. тупо нажимал на ответы, которые я уже знаю. В новом релизе было одно изменение, т.е. один раз мне пришлось задуматься. Итак, сегодня я дошёл до главы 27 ( закончил знакомство, моё первое, кстати, с технологией Scrum ). Первый раз увидел Jira.
Бац
Весь мой прогресс исчез. Вы там обновили версию 1.0.0 ?
Посмотрите, пожалуйста. Мой ник в вашей базе raidex
:(
У вас настолько совершенно выстроен процесс разработки новых релизов, что прогресс полностью теряется с выходом нового релиза ( о чём у вас написано в главе 1 ).
Увы, это особенности SCORM-формата. В нем невозможно прописать "в текущем релизе этот учебный тест изменился чуть-чуть, прогресс нужно оставить, а вот этот учебный тест поменялся - прогресс по нему нужно сбросить".
Весь мой прогресс исчез. Вы там обновили версию 1.0.0 ?
Конечно же текущие версии не перезаливаем. Каждый новый релиз - отдельная версия и прогресс по любой версии остается и к нему можно получить доступ на странице версий.
Посмотрите, пожалуйста. Мой ник в вашей базе raidex
Да, за полгода было несколько жалоб на потерю прогресса. Глобального фикса пока нет (софт для отображения SCORM пишем не мы), но локализация показывает, что это происходит, когда пользователь проходит учебник сразу с нескольких устройств. Пожалуйста, напишите еще и свой email в поддержку (телеграм или любой из контактов на странице), попробуем пофиксить.
Проблемы с исчезнованием прогресса в результате были пофиксаны.
Прогресс восстановлен всем кто отписался.
Глава 37
Полный релиз бесплатного интерактивного 700-страничного учебника по тестированию