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

Всем привет! Видим в канале много новой аудитории Предлагаем познакомиться поближе. Мы любим говорить о профессиях, трудоустройстве и карьерном пути разработчиков, тестировщиков и аналитиков данных. Собрали посты, которые могут быть полезны и интересны. 🟤 Зарплаты 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