Здесь простым языком про TON, DFC и крипту.
Принимаем автоматически.
Ссылка для друзей: https://t.me/+-EOfWx2pRKhmNGE6
Связь: @deftalk_bot
Last updated 5 days, 19 hours ago
Канал для поиска исполнителей для разных задач и организации мини конкурсов
Last updated 2 weeks, 1 day ago
На собеседованиях тестировщиков-автоматизаторов часто спрашивают про исключения. Чаще всего на этот вопрос рассказывают про try-catch-finally, но мало кто может внятно объяснить, чем проверемые исключения (checked) отличаются от непроверяемых (unchecked).
Часто я слышу такой ответ: проверяемые - это те, которые мы может отловить и проверить, а непроверяемые - нет. ЭТО НЕПРАВИЛЬНО 😡
Проверяемые - это такие исключения, которые проверяются и выявляются на этапе компиляции кода в IDE. IDE не скомпилирует программу, пока такое исключение не будет обернуто в try-catch. Пример - FileNotFoundException. Попробуйте реализовать чтение из файла без обработки исключения - не получится.
А непроверяемые исключения - это те, которые возникают в ходе работы программы и вызваны ошибкой программиста. Например, при попытке получить элемент массива по индексу может возникнуть IndexOutOfBoundsException. IDE не в состоянии на стадии кода предусмотреть, что в массиве не окажется нужного элемента, поэтому здесь наступает ответственность разработчика.
Подробнее тут https://javarush.com/groups/posts/1944-iskljuchenija-checked-unchecked-i-svoi-sobstvennihe
Вчера выступала в проекте GeekBrains «Путь в ИТ»
За час постаралась рассказать, в чем заключается работа тестировщика и показала простой практический кейс.
Осталось много вопросов, на которые не успела ответить. Буду публиковать их здесь, потому что они тоже важные и интересные.
🐹 Существуют ли открытые платформы или сайты для бета-тестирования реальных проектов или приложений для получения практики?
Для получения первой практики поищите задачи в проекте «Хомячки». Правила, как вступить и начать тестировать читайте на форуме. Еще про проект можно почитать на Хабре.
Другой вариант получить практику - скооперироваться со студентами с факультета разработки. Они пишут код, вы пишете тесты, в итоге есть что приложить в порфолио.
Наконец, можно попробовать свои силы на платформах crowd testing. Ищите сами в гугле, у меня нет опыта работы с ними.
🕸 Не отберут ли нейросети работу у тестировщиков?
Нет, потому что нейросети - это тоже программный продукт, который надо тестировать. А также их кто-то должен обучать. Чтобы нейросеть смогла протестировать продукт, должны быть предельно четко сформулированы требования. Даже если нейросеть научится проектировать и выполнять тесты, кто-то должен будет формализовать ТЗ таким образом, чтобы нейросеть поняла, что он нее хотят.
Нейросети по генерации картинок уже хороши, но много ли художников остались без работы?
💬 СhartGPT в роли QA пробовали?
Пробовала, результат не впечатлил. Скорее всего, потому что недостаточно четко сформулировала запрос. Что возвращает нас к предыдущему пункту.
📱Мобильный разработчик может заниматься дополнительно тестированием?
Почему бы и нет, но смысл? Лучше хорошо делать что-то одно: тестировать или разрабатывать, - чем посредственно и то, и другое.
Разработчики тоже занимаются тестированием: они пишут юнит-тесты, интеграционные тесты, проверяют свой код перед тем, как отдать в тестирование. Но считается, что разработчик не может адекватно протестировать собственный код, т.к. подсознательно будет избегать ошибок. Поэтому тестированием занимаются другие специалисты, для которых код - это черный ящик, и у нас свои инструменты.
💸 Возможно ли в принципе работать тестировщиком по совместительству?
Мне кажется, очень сложно найти вакансию тестировщки на частичную занятость. Компании обычно предлагают полный рабочий день, а на фрилансе мизерное количество заказов на тестирование.
Но можно попробовать себя в роли «Хомячка», см. первый вопрос
Московское время 20:44, мы с разработчиком заняты отладкой веб-приложения, которое никак не хочет стабилироваться 😫
Сегодня я узнала много интересного про ошибки веба
- Обновление списков после операций CRUD уходит в бесконечную загрузку
- При выборе значения из списка оно не подставляется в поле ввода
- Поля не заполняются при копировании объекта
- Логика на фронте зло. Сегодня наш разучился выполнять элементарные арифметические операции
- При вводе запятой в числовое поле (корое типа float) в поле появляется NaN, и игнорируются последующие попытки вбить цифры
- При нажатии Backspace на пустом поле вввода приложение уходит в штопор
- При попытке редактировать сущность создается дубликат
- Валидация вылезает там, где ее отродясь не было и не закладывалось
Вот сколько идей на будущее для исследовательского тестирования веб-приложения!
У меня, например, получилось вот так. Это значит, что я миддл. До сеньора мне надо подождать еще несколько месяцев (опыт работы) и прокачать уровень задач
И в догонку - запилила табличку самоопределения. Пока что только для QA.
Как использовать таблицу
1. Создать копию файла - исходник доступен только на чтение (Файл - Создать копию)
2. Заполнить колонку по шкале от 1 до 3 (как - описано в Пояснении)
3. Результат будет на диаграмме
Как интерпретировать результат
1 - джуниор
2 - миддл
3 - сеньор
До какого уровня дотягивает 4 столбца - тот и присваиваем себе, указываем в резюме. Вакансии смотрим на 1 уровень выше 🙂
Продложение про грейды
Вот параметры, по которым (приблизительно и весьма условно) можно определить свою “миддловость” или “сеньорность”. Речь пойдет преимущественно о тестировщиках и немного о разработчиках. Мои представления о грейдах в других областях ИТ удручающе малы.
⏳ Опыт работы
Количество отработанных лет само по себе значит мало. Как известно, опыт приходит с возрастом, но иногда возраст приходит один. Тем не менее, вызывает доверие теория про 10000 часов: целенаправленные занятия в течение этого времени приводят к совершенному владению навыком. Поэтому сеньором можно считать того, что отработал свыше 10000 часов, миддл будет на уровне 5000 - 10000, а все, кто посвятил IT менее 5000 находятся на стадии джуниоров.
🏋️♀️ Сложность задач
Компании по-разному определяют, насколько сложные задачи должен решать специалист на каждом уровне. А еще часто используется более 3 ступеней градации: 5 или 6. Если же усреднить требования, то получится примерно следующее:
Джуниор:
- Разработчик: пишет рабочий код по конкретной задаче, запускает код локально, фиксит баги
- Тестировщик: запускает готовые тесты (авто или ручные), пишет баг репорты.
Миддл:
- Разработчик: понимает, как разработка влияет на производство. Умеет писать документацию. Принимает небольшие проектные решения.
- Тестировщик: пишет новые тестовые сценарии, отчеты о тестировании. Оптимизирует процессы тестирования.
Сеньор:
- Разработчик: управляет командой разработчиков, ставит задачи на команду. Формирует стратегию разработки.
- Тестировщик: может настроить процессы тестирования с нуля. Составляет тест-планы, матрицы покрытия, оценивает процент тестового покрытия. Распределяет задачи на тестирование внутри команды.
🛠 Владение инструментами
Здесь мы полностью переходим в область тестирования, т.к. из инструментов разработки мне известна только IDE. В вакансиях QA фигурирует примерно следующий список:
- postman
- soap ui
- базы данных
- снифферы
- знание любого языка программирования
- chrome dev tools
- техники тест-дизайна
- Elastic / Kibana
- любая система баг-трекинга
- Docker
- Kubernetes (или другой оркестратор)
- Kafka / Rabbit MQ (иди другой брокер сообщений)
- shell / bash
- CI / CD (gitlab, jenkins)
Чем больше знаете и умеете ипользовать, тем ближе вы к сеньору.
👩🚀 Автономность
Сегодня ценятся “самонаводящиеся” специалисты, т.е. те, которые могут сами найти недостаток, поставить задачу и решить ее с пользой для компании.
Джуниор работает только с задачами, который ставит ПМ, лид, ПО.
Миддл самостоятельно определяет задачи по своей компетенции в рамках продуктовой задачи
Сеньор выходит за рамки продуктовых задач, над которым работает команда. Например, находить недочеты в процессах разработки и предлагать оптимизацию. Или инициировать переход на новый технический стек с целью улучшения показателей качества или скорости разработки.
🔀 Смежные компетенции
Недостаточно только выполнять непосредственные обязанности. В IT модно быть T-Shaped специалистом, т.е. помимо основных хард-скиллов уметь что-то еще. Это могут быть:
- гибкие методологии (скрам-мастер, аджайл-коуч)
- роль технический писатель
- любой вид нефункционального тестирования
- и прочие навыки, которые приносят пользу всей команде, но не относятся к основной роли
Более 1 смежной компетенции - отличная заявка на звание сеньора-помидора.
Список литературы
https://habr.com/ru/companies/getmatch/articles/544466/
https://habr.com/ru/articles/646113/
https://biz.mann-ivanov-ferber.ru/2019/06/20/65571/
Удаленная отладка:
Вот этим мы и заняты в QA
Про кризис самоопределения
Иногда мы в ИТ заняты решением философского вопроса: ~~тварь я дрожащая~~ джуниор я неопытный или право имею на звание сеньора. Итог самопознания бывает самый неожиданный, вплоть до глубокой депрессии на фоне синдрома самозванца.
😡 Первая проблема грейдов - отсутствие объективной шкалы, по которой можно себя оценить. Общепринятой мерки нет, единой сертификации нет, и сеньор из стартапа, придя в FAANG, оказывается миддлом или даже начинающим специалистом. Значит, грейд - это не характеристика специалиста, а скорее степень соответствия требованиям компании.
👿 Вторая проблема - необходимость повесить на себя ярлык во время поиска работы. Редкая вакансия обходится без пометки Middle / Senior / джуниоров не рассматриваем. Соответственно, в резюме надо указать свой уровень, но здесь мы возвращаемся к проблеме 1: нет шкалы для самооценки, есть синдром самозванца.
Есть три варианта, как самоопределиться.
🧘♀️ Первый - не вешать на себя никакой ярлык, и в резюме указывать просто “QA-инженер” или “Java-разработчик”. Подробно перечислить список умений, достижений и откликаться на вакансии, где есть совпадение по компетенциям. Оптимальный вариант для тех, кто познал дзен и не стремится к сферическиому званию в вакууме. Если же лычки нужны позарез, читай далее.
👀 Второй вариант - мониторинг вакансий, выявление задач, отличающих один грейд от другого. Например, отличительной чертой сеньора с большой долей вероятности будет умение управлять командой. Значит, тот кто может управлять командой, может претендовать на сеньора. Но это не точно, потому что в некоторых сеньорных вакансиях никем управлять не надо.
📊 Третий вариант - самооценка по ряду параметров, на которые смотрят компании при составлении матриц компетенций (матрицы, как правило, однотипны. Что-то оригинальное может быть разве что в условном Яндексе). О них в следующий раз.
Еще раз про упражнение с кухонной плитой и юнит-тестами
Хочешь понять что-либо - объясни другому. Правило работает безотказно, когда речь идет о понимании чего угодно: от «почему трава зеленая» до «почему черная дыра так называется».
У нас на собеседованиях задают вопрос: «Объясните принципы ООП, чтобы понял трехлетний ребенок». Проделывать данный экзерсис полезно не только с принципами ООП, но и с другими концепциями ИТ.
- Объяснить SOLID дедушке-агроному
- Сделать ремонт в квартире по аджайлу
- Написать чек-лист интеграционных тестов пылесоса
И так далее, простор для фантазии бесконечен!
В итоге:
1. Лучше начнете понимать, чем же вы заняты в ~~тени~~ ИТ
2. Подготовитесь к каверзным вопросам на будущих собеседованиях
3. Неожиданно обнаружите белые пятна в собственных познаниях и пойдете их устранять.
Здесь простым языком про TON, DFC и крипту.
Принимаем автоматически.
Ссылка для друзей: https://t.me/+-EOfWx2pRKhmNGE6
Связь: @deftalk_bot
Last updated 5 days, 19 hours ago
Канал для поиска исполнителей для разных задач и организации мини конкурсов
Last updated 2 weeks, 1 day ago