На собеседованиях тестировщиков-автоматизаторов часто спрашивают про исключения. Чаще всего на этот вопрос рассказывают про 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. Неожиданно обнаружите белые пятна в собственных познаниях и пойдете их устранять.