В очереди на тестирование Telegram Posts

Всем привет! Видим в канале много новой аудитории

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

🟤 Зарплаты IT-специалистов в первой половине 2024
Каждые полгода Хабр Карьера проводит исследование, чтобы узнать, сколько зарабатывают в IT. Делимся основными выводами.

🟤 На что смотрит лид при проверке тестовых заданий
В сентябре 2022 года выпускник курса «Python-разработчик» Олег Завитаев стал лидом и теперь сам собеседует разработчиков к себе в команду.

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

🟤 Из звукорежиссуры в Data Science: путь к карьере мечты
История выпускника курса «‎Специалист по Data Science»‎. По образованию Иван звукорежиссёр, за его спиной — больше тысячи концертов. В карточках Иван рассказывает, как ушёл в анализ данных и нашёл работу мечты.

🟤 C++ для начинающих: подборка бесплатных ресурсов
Лекции, блоги и другие полезные ресурсы, с которых можно начать знакомство с языком. Подборку собирал Савва Лебедев — программист с семилетним стажем, менеджер команды наставников на курсе «Разработчик C++».

Всем привет!

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

Но мы не прощаемся! Наш канал по тестированию станет частью большого канала по программированию @practicumtech. Там будет ещё больше полезного контента для погружения в мир программирования и в тестирование — как его часть.

До новых встреч и успехов на профессиональном пути!


Команда курсов «Инженер по тестированию» 🖤

Как разрабатывают приложения

Для создания приложений используют методологии — общие стратегии, которые определяют способ разработки.

Методологии бывают более строгими и гибкими. В строгих подходах этапы идут последовательно. Например: придумать функциональность приложения — реализовать задуманное — протестировать — запустить.

В гибких подходах приложение создают итеративно — через повторение определённых циклов действий. Например: придумать функциональность приложения — разработать самую главную функцию — протестировать — запустить — проанализировать запуск и потом пересмотреть изначальный план, чтобы в случае изменений или фидбека команды/пользователей его подкорректировать.

Строгие методологии используют при разработке критически важных систем: в медицине, ракетостроении или ядрах банковских систем. Важный признак строгой методологии — это когда ещё на старте есть список конкретных требований к приложению и все знают, что именно должно получиться. Самая популярная методология этого вида — Waterfall.

Методологии вроде Waterfall всё реже подходят современным разработчикам: их сложно подстроить под постоянные изменения и обновления. Поэтому на замену строгим и требующим определённости методологиям приходят гибкие — самая популярная из них называется Agile.

Гибкие (само слово agile переводится как «гибкий») итеративные методологии используют в проектах, где не такие большие риски ошибок, но при этом важна скорость и эффективность разработки. Например, при разработке социальных сетей, мессенджеров и мобильных приложений всех видов.

В следующем посте разберём, как разработчики пользуются Agile и почему тестировщикам тоже нужно о ней знать.

Каким был 2023 год?

🎓 мы выпустили больше 3000 тестировщиков

🌲 первый фидбек в году нам оставили 1 января в 02:16, а первый проект сдали 1 января в 12:10

⏰ примерно 2000 дней провели на фритреке студенты всех курсов — это как пять лет за один год

🌟 количество сданных проектов за год близко к 33000 — если каждый из них считать за километр, студенты на 80% окружили ими экватор

Пусть 2024 продолжит цепочку рекордов, но главное — ваших знаний, успехов и стремлений

Верим в каждого, кто начинает учиться, идём рядом с теми, кто учится, гордимся выпускниками и восхищаемся каждым, кто решился на смену профессии. Уверены, у вас всё получится ❤️

С Новым 2024 годом!

Почему важно указывать окружение в багах

Для начала давайте разберёмся, что такое окружение.

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

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

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

📱Для мобильного приложения важна его сборка, операционная система и модель устройства. Пример: сборка 100.1.1, iOS 16.1.2, iPhone 11

💻 Для веб-приложения — операционная система, разрешение экрана и версия браузера. Пример: Google Chrome 116.0.5845.163, MacOS, 2560 × 1600

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

500 Internal Server Error: что значит и как решить

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

Я всегда стараюсь раскопать проблему, если есть время и знания. Разберу популярную ошибку 500 Internal Server Error по мотивам задания на поиск багов.

Многие из вас нашли хотя бы один из этих багов:

1. При вводе отрицательного числа и нажатии на кнопку Calculate система не реагирует. Остаётся предыдущий результат.
2. Факториал большого числа от 992, например, 3333, не считается. Система не реагирует. Остаётся предыдущий результат.
3. При попытке вычислить факториал «1.» (точка в конце числа) cистема не реагирует. Остаётся предыдущий результат.

Если система не реагирует, значит, проблема в ответе бэкенда. Это и называется 500 Internal Server Error.

Как это узнать?

Открыть DevTools* и во вкладке Network посмотреть, что происходит при нажатии на Calculate. Если увидите ошибку 500, значит, сервер отработал с ошибкой и не вернул корректный ответ.

Что делать тестировщику?

Завести баг на бэкенд, а потом попросить разработчика бэкенда добавить проверки так, чтобы сервер не «падал» при попытке обработать такие значения или исправить ошибки в подсчёте факториала и выдавать корректный результат.

*DevTools — встроенные инструменты в браузере для разработчика, с помощью которых можно в том числе тестировать веб-приложения

DevTools открывается сочетанием клавиш Ctrl + Alt + I в Windows или Cmd + Option + I в macOS

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

Сегодня расскажу о том, как правильно писать баг-репорты. В начале карьеры я думала, что указывать много деталей в простом баг-репорте — это лишнее. Ведь зачем подробно описывать что-то очевидное, если это всем понятно? Но с опытом убедилась, что всё очевидное сегодня уже никто не помнит завтра, поэтому важно фиксировать всё.

Сравните оформление одного и того же бага:

1) По нажатию на кнопку ничего не происходит

2) Калькулятор не работает с числами с точкой, например, 5.0

Как воспроизвести:
1. Открыть страницу https://qainterview.pythonanywhere.com/
2. Ввести в поле ввода 5.0
3. Нажать Calculate!

ОР: выводится результат вычисления факториала для целого числа 5
”The factorial of 5 is: 120”
ФР: по нажатию на кнопку ничего не происходит. Страница остаётся в прежнем состоянии.

Почему второй пример лучше:
В нём описали порядок действий для достижения результата и ожидаемый (ОР) и фактический (ФР) результаты. Так понятно, какое поведение системы ожидали и какое получили по факту. 

Полное описание поможет команде понять, где именно ошибка, как её воспроизвести и исправить.

Ещё при описании бага полезно указывать название и версию браузера и предлагать решение проблемы, если есть версии. Но об этом расскажу подробнее в другой раз.

Презентуем свой аутентично-ностальгический стикерпак! Он создан специально для всех любителей IT и ретро-эстетики. Внутри вы найдете стикеры, которые помогут выражать свои мысли и эмоции в чатах и комментариях к нашим постам: https://t.me/addstickers/prctcm.

«Быть дотошным, но не душным»: какие софтскилы нужны джуну-тестировщику

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

Делимся краткой подборкой ↓

• Желание задавать вопросы. Вопросы — главный инструмент в руках начинающего тестировщика. Задавать их можно даже на собеседовании, например, попросив подсказку, если не получается решить задачу. Всё потому, что джуну можно чего-то не знать, это не страшно. А вот отсутствие интереса — красный флажок для работодателя.

• Умение рассуждать. Навык на грани хардскилов и софтскилов — готовность добираться до сути, когда ответ неизвестен. Впрочем, наши собеседники из IT-сферы считают, что на собеседовании можно и ошибиться — неправильный ответ всё равно лучше, чем «я не знаю».

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

• Умение работать в команде. Работодателю важно не только, как вы справитесь с задачами, но и уживётесь ли в коллективе. Будьте готовы рассказать про свои увлечения и показать, что вы за человек, — а как устроитесь на работу, поддерживайте внутренний tone of voice. Например, не общайтесь формально, если в компании принято обращаться на ты.

• Ответственность. Не опаздывайте на встречи и не игнорируйте сообщения, а также не подводите коллег — соблюдайте дедлайны или предупреждайте заранее, если рискуете не успеть. А ещё внимательно изучите особенности работы в компании: внутреннюю документацию и то, как ведутся процессы.

• Гибкость. Важно, чтобы специалист пытался решить проблему, даже если ситуация кажется безвыходной. Если на интервью вас спросят «что вы будете делать, если надо поправить баг, а разработчик говорит, что бага нет», не стоит отвечать, что это не ваша проблема — лучше постарайтесь предложить варианты её решения.

Делимся записью беседы с Яной Фёдоровой — преподавателем английского языка и выпускницей курса «Инженер по тестированию» и студенткой курса «Автоматизатор тестирования на Java».

Как говорит сама Яна: «Я думала, что следующим языком, который буду изучать, станет итальянский. Но нет, им стал Java». Яна 9 лет преподавала английский язык, получила целых три диплома по этому направлению — два российских и один иностранный. А потом она решила сменить сферу, изучить направление тестирования и, в частности, научиться писать автотесты на Java.

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

А ещё для слушателей, которые заполнят форму обратной связи после этого эфира, мы дадим скидку 10% на любой курс Практикума до 19 октября.

Запасайтесь чаем и печеньем, приятного прослушивания✨

Нули в записи — это баг, на самом деле она длится час.