Бесплатный практический вебинар ― Тестировщик с нуля: как начать карьеру в IT без кода и знания математики.
⏰ Когда: 6 марта в 19:00 (мск).
За 2 часа вы узнаете как устроено ручное и автоматизированное тестирование, попробуете профессию на практике и протестируете свой первый сайт.
✔️ Познакомитесь с технологиями и навыками, которые требуются для старта в тестировании. Узнаете про зарплаты и перспективы в сфере.
✔️ Протестируете 2 страницы, разберете базовые техники тест-дизайна и тест-кейсы, автоматизируете тестирование при помощи Selenium IDE, составите первый баг-репорт.
🎁 Всем, кто зарегистрировался ― Гайд «Как заговорить на сленге IT-специалистов», а в конце трансляции ― Карту компетенций джуниор тестировщика!
⏰ Когда: 6 марта в 19:00 (мск).
За 2 часа вы узнаете как устроено ручное и автоматизированное тестирование, попробуете профессию на практике и протестируете свой первый сайт.
✔️ Познакомитесь с технологиями и навыками, которые требуются для старта в тестировании. Узнаете про зарплаты и перспективы в сфере.
✔️ Протестируете 2 страницы, разберете базовые техники тест-дизайна и тест-кейсы, автоматизируете тестирование при помощи Selenium IDE, составите первый баг-репорт.
🎁 Всем, кто зарегистрировался ― Гайд «Как заговорить на сленге IT-специалистов», а в конце трансляции ― Карту компетенций джуниор тестировщика!
Почему баги возвращаются? 🤔
Сегодня разберём одну из самых неприятных ситуаций в тестировании – возвращение багов после фикса. Почему так происходит, и как это предотвратить?
🔹 Разработчик пофиксил, но не проверил код на смежные участки.
Программное обеспечение – это не набор отдельных кусочков, а сложная система. Один фикс может затронуть другие модули. Если не учитывать влияние изменений, баг может всплыть в новом месте.
🔹 Тестировщик проверил только исправленный сценарий.
Частая ошибка – проверить только шаги бага, но не провести регрессию. Нужно учитывать контекст и возможные побочные эффекты.
🔹 Недостаток автотестов.
Если в проекте нет хорошего набора автоматизированных тестов, старые баги могут возвращаться при каждом новом релизе. Хорошие автотесты помогают избежать этого.
🔹 Команда не ведёт учёт багов.
Если нет системы контроля дефектов или качественного описания фикса, баг может вернуться, потому что его просто не учли в тест-плане.
Что делать?
✅ Проводить регрессию после каждого фикса.
Не проверяй только сам баг – тестируй и связанные модули.
✅ Автоматизировать ключевые сценарии.
Например, если баг был связан с формой логина, добавь автотест, который будет её проверять при каждом релизе.
✅ Документировать баги и их фиксы.
Чем детальнее ты фиксируешь проблему, тем легче её предотвратить в будущем.
✅ Общаться с разработчиками.
Задавай вопросы: какие части системы могли быть затронуты? Это поможет определить области для дополнительного тестирования.
#qa #testing
Подпишись👉 @testlab_qa
Сегодня разберём одну из самых неприятных ситуаций в тестировании – возвращение багов после фикса. Почему так происходит, и как это предотвратить?
🔹 Разработчик пофиксил, но не проверил код на смежные участки.
Программное обеспечение – это не набор отдельных кусочков, а сложная система. Один фикс может затронуть другие модули. Если не учитывать влияние изменений, баг может всплыть в новом месте.
🔹 Тестировщик проверил только исправленный сценарий.
Частая ошибка – проверить только шаги бага, но не провести регрессию. Нужно учитывать контекст и возможные побочные эффекты.
🔹 Недостаток автотестов.
Если в проекте нет хорошего набора автоматизированных тестов, старые баги могут возвращаться при каждом новом релизе. Хорошие автотесты помогают избежать этого.
🔹 Команда не ведёт учёт багов.
Если нет системы контроля дефектов или качественного описания фикса, баг может вернуться, потому что его просто не учли в тест-плане.
Что делать?
✅ Проводить регрессию после каждого фикса.
Не проверяй только сам баг – тестируй и связанные модули.
✅ Автоматизировать ключевые сценарии.
Например, если баг был связан с формой логина, добавь автотест, который будет её проверять при каждом релизе.
✅ Документировать баги и их фиксы.
Чем детальнее ты фиксируешь проблему, тем легче её предотвратить в будущем.
✅ Общаться с разработчиками.
Задавай вопросы: какие части системы могли быть затронуты? Это поможет определить области для дополнительного тестирования.
#qa #testing
Подпишись👉 @testlab_qa
👍5
Разработка эффективных тест-кейсов для автоматизации: Руководство для опытных QA-инженеров
Автоматизированное тестирование требует грамотного проектирования тест-кейсов, обеспечивающего надежность, стабильность и минимальное техническое обслуживание. Разберем ключевые аспекты, которые помогут в создании эффективных тест-кейсов.
1. Основные принципы проектирования тест-кейсов для автоматизации
При написании тест-кейсов для автоматизации важно соблюдать несколько принципов:
1. Идентифицируемость – тест-кейс должен иметь четкое название, описывающее его цель.
2. Детерминированность – каждый тест-кейс должен давать один и тот же результат при повторном выполнении.
3. Модульность – тест-кейсы должны быть независимыми друг от друга, чтобы избежать цепной реакции сбоев.
4. Повторяемость – тест должен быть устойчивым к изменениям данных и среды.
5. Минимизация технического долга – избегайте чрезмерной детализации, которая затрудняет поддержку.
2. Структура эффективного автоматизированного тест-кейса
Хороший тест-кейс состоит из следующих компонентов:
• Название – краткое и информативное (например, Verify user login with valid credentials).
• Предварительные условия (Preconditions) – данные, состояния системы перед тестом.
• Шаги выполнения – четкая последовательность действий.
• Ожидаемый результат – конкретный и измеримый.
• Постусловия (Postconditions) – очистка данных, если требуется.
Пример:
3. Лучшие практики автоматизации тест-кейсов
Чтобы тесты были устойчивыми и эффективными, следуйте этим рекомендациям:
3.1. Используйте Page Object Model (POM)
Этот паттерн помогает избежать дублирования кода, улучшает читаемость и облегчает поддержку.
Пример:
Использование:
3.2. Минимизируйте использование sleep()
Фиксированные задержки (time.sleep(5)) делают тесты медленными и нестабильными. Вместо этого используйте ожидания элементов:
3.3. Создавайте независимые тесты
Тесты не должны зависеть друг от друга, иначе один сбой может вызвать цепочку ложных негативных результатов.
Плохая практика:
• Тест на авторизацию выполняется только после успешной регистрации.
Хорошая практика:
• Разделите регистрацию и авторизацию, используя API-запрос для предварительного создания пользователя.
3.4. Уменьшайте зависимость от тестовых данных
Храните тестовые данные в конфигурационных файлах или используйте параметризацию.
Пример параметризации в Pytest:
#qa #testing
Подпишись👉 @testlab_qa
Автоматизированное тестирование требует грамотного проектирования тест-кейсов, обеспечивающего надежность, стабильность и минимальное техническое обслуживание. Разберем ключевые аспекты, которые помогут в создании эффективных тест-кейсов.
1. Основные принципы проектирования тест-кейсов для автоматизации
При написании тест-кейсов для автоматизации важно соблюдать несколько принципов:
1. Идентифицируемость – тест-кейс должен иметь четкое название, описывающее его цель.
2. Детерминированность – каждый тест-кейс должен давать один и тот же результат при повторном выполнении.
3. Модульность – тест-кейсы должны быть независимыми друг от друга, чтобы избежать цепной реакции сбоев.
4. Повторяемость – тест должен быть устойчивым к изменениям данных и среды.
5. Минимизация технического долга – избегайте чрезмерной детализации, которая затрудняет поддержку.
2. Структура эффективного автоматизированного тест-кейса
Хороший тест-кейс состоит из следующих компонентов:
• Название – краткое и информативное (например, Verify user login with valid credentials).
• Предварительные условия (Preconditions) – данные, состояния системы перед тестом.
• Шаги выполнения – четкая последовательность действий.
• Ожидаемый результат – конкретный и измеримый.
• Постусловия (Postconditions) – очистка данных, если требуется.
Пример:
Название: Verify user login with valid credentials
Предусловия:
1. Пользователь зарегистрирован в системе.
Шаги:
1. Открыть страницу входа.
2. Ввести корректный логин и пароль.
3. Нажать "Войти".
Ожидаемый результат:
- Пользователь успешно авторизован.
- Открыта главная страница.
Постусловия:
- Выход из системы (если требуется).3. Лучшие практики автоматизации тест-кейсов
Чтобы тесты были устойчивыми и эффективными, следуйте этим рекомендациям:
3.1. Используйте Page Object Model (POM)
Этот паттерн помогает избежать дублирования кода, улучшает читаемость и облегчает поддержку.
Пример:
class LoginPage:
def __init__(self, driver):
self.driver = driver
self.username_field = driver.find_element(By.ID, "username")
self.password_field = driver.find_element(By.ID, "password")
self.login_button = driver.find_element(By.ID, "login")
def login(self, username, password):
self.username_field.send_keys(username)
self.password_field.send_keys(password)
self.login_button.click()Использование:
login_page = LoginPage(driver)
login_page.login("[email protected]", "securepassword")3.2. Минимизируйте использование sleep()
Фиксированные задержки (time.sleep(5)) делают тесты медленными и нестабильными. Вместо этого используйте ожидания элементов:
WebDriverWait(driver, 10).until(EC.presence_of_element_located((By.ID, "dashboard")))3.3. Создавайте независимые тесты
Тесты не должны зависеть друг от друга, иначе один сбой может вызвать цепочку ложных негативных результатов.
Плохая практика:
• Тест на авторизацию выполняется только после успешной регистрации.
Хорошая практика:
• Разделите регистрацию и авторизацию, используя API-запрос для предварительного создания пользователя.
3.4. Уменьшайте зависимость от тестовых данных
Храните тестовые данные в конфигурационных файлах или используйте параметризацию.
Пример параметризации в Pytest:
@pytest.mark.parametrize("username, password", [
("[email protected]", "pass123"),
("[email protected]", "pass456"),
])
def test_login(username, password):
login_page.login(username, password)
assert dashboard_page.is_loaded()#qa #testing
Подпишись👉 @testlab_qa
👍4
Разработка эффективных тест-кейсов для автоматизации: Руководство для опытных QA-инженеров. Продолжение.
4. Возможные проблемы и их решения
4.1. Хрупкие тесты
Проблема: Тесты падают при малейшем изменении UI (например, изменился ID кнопки).
Решение: Используйте надежные селекторы:
• XPath, основанный на структуре: //button[text()=
• CSS-селектор по атрибутам: button[data-testid=
4.2. Зависимости от тестовых данных
Проблема: Жестко закодированные тестовые данные могут устареть.
Решение: Используйте генерацию данных:
4.3. Долгое выполнение тестов
Решение:
• Параллельное выполнение тестов (pytest-xdist).
• Выборочное выполнение важных тестов (маркировка
• Оптимизация локаторов и ожиданий.
5. Заключение
При проектировании автоматизированных тест-кейсов придерживайтесь:
✅ Ясной структуры (название, шаги, ожидания).
✅ Page Object Model для упрощения кода.
✅ Надежных локаторов и динамических ожиданий.
✅ Минимизации зависимостей между тестами.
✅ Использования параметризации и генерации данных.
Это поможет создать надежную, легко поддерживаемую тестовую систему.
#qa #testing
Подпишись👉 @testlab_qa
dashboard_page.is_loaded()4. Возможные проблемы и их решения
4.1. Хрупкие тесты
Проблема: Тесты падают при малейшем изменении UI (например, изменился ID кнопки).
Решение: Используйте надежные селекторы:
• XPath, основанный на структуре: //button[text()=
Login]• CSS-селектор по атрибутам: button[data-testid=
login]4.2. Зависимости от тестовых данных
Проблема: Жестко закодированные тестовые данные могут устареть.
Решение: Используйте генерацию данных:
import faker
fake = faker.Faker()
print(fake.email()) # Генерирует случайный email4.3. Долгое выполнение тестов
Решение:
• Параллельное выполнение тестов (pytest-xdist).
• Выборочное выполнение важных тестов (маркировка
@pytest.mark.smoke).• Оптимизация локаторов и ожиданий.
5. Заключение
При проектировании автоматизированных тест-кейсов придерживайтесь:
✅ Ясной структуры (название, шаги, ожидания).
✅ Page Object Model для упрощения кода.
✅ Надежных локаторов и динамических ожиданий.
✅ Минимизации зависимостей между тестами.
✅ Использования параметризации и генерации данных.
Это поможет создать надежную, легко поддерживаемую тестовую систему.
#qa #testing
Подпишись👉 @testlab_qa
👍3
🚀❓ Играете в игры, но хотите зарабатывать на их тестировании? Тогда это ваш шанс! На открытом вебинаре «Инструменты для тестирования игр» вы узнаете, как стать экспертом Game QA и превратить хобби в карьеру.
Что обсудим:
- Какие инструменты нужны для тестирования игр и зачем.
- Как работать с документацией, замерять производительность и автоматизировать рутину.
- Как собрать идеальный инструментарий для эффективной работы.
- Как использовать AI для ускорения тестирования.
⭐️ Спикер Никита Шаченко — QA Automation Engineer в Redhill Games.
Курс «Game QA Engineer» стартует совсем скоро, а все участники открытого урока получат скидку на обучение.
👉 Записывайтесь прямо сейчас: https://vk.cc/cJlmi0
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Что обсудим:
- Какие инструменты нужны для тестирования игр и зачем.
- Как работать с документацией, замерять производительность и автоматизировать рутину.
- Как собрать идеальный инструментарий для эффективной работы.
- Как использовать AI для ускорения тестирования.
⭐️ Спикер Никита Шаченко — QA Automation Engineer в Redhill Games.
Курс «Game QA Engineer» стартует совсем скоро, а все участники открытого урока получат скидку на обучение.
👉 Записывайтесь прямо сейчас: https://vk.cc/cJlmi0
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🔥 10 Полезных SQL-запросов для Тестировщика
Привет, коллеги! Сегодня хочу поделиться подборкой SQL-запросов, которые спасали меня не раз при тестировании. Если вы работаете с базами данных, то этот список точно пригодится!
📌 1. Проверить количество записей в таблице:
Когда нужно убедиться, что в таблице появилось нужное количество записей после теста.
📌 2. Найти дубликаты в таблице:
Полезно, если проверяете уникальность данных.
📌 3. Вывести последние 10 записей:
Отличный способ проверить свежие данные.
📌 4. Проверить, есть ли в таблице определённая запись:
Помогает быстро найти тестовые данные.
📌 5. Обновить данные в таблице (осторожно!):
Используйте на тестовых базах!
📌 6. Удалить записи по условию (ещё осторожнее!):
Перед выполнением лучше сделать
📌 7. Соединение двух таблиц (JOIN):
Когда тестируете связь между пользователями и их заказами.
📌 8. Найти записи, содержащие слово:
Пригодится для проверки поиска в базе.
📌 9. Посчитать среднюю сумму заказов:
Когда нужно проверить расчёты в отчётах.
📌 10. Найти пользователей, которые не сделали заказ:
Для анализа пользователей без активности.
Попробуйте эти запросы в деле и напишите, какие из них вам пригодились или какие ещё вы используете в тестировании! 👇
#qa #testing
Подпишись👉 @testlab_qa
Привет, коллеги! Сегодня хочу поделиться подборкой SQL-запросов, которые спасали меня не раз при тестировании. Если вы работаете с базами данных, то этот список точно пригодится!
📌 1. Проверить количество записей в таблице:
SELECT COUNT(*) FROM users;
Когда нужно убедиться, что в таблице появилось нужное количество записей после теста.
📌 2. Найти дубликаты в таблице:
SELECT email, COUNT(*)
FROM users
GROUP BY email
HAVING COUNT(*) > 1;
Полезно, если проверяете уникальность данных.
📌 3. Вывести последние 10 записей:
SELECT * FROM orders ORDER BY created_at DESC LIMIT 10;
Отличный способ проверить свежие данные.
📌 4. Проверить, есть ли в таблице определённая запись:
SELECT * FROM users WHERE email = '[email protected]';
Помогает быстро найти тестовые данные.
📌 5. Обновить данные в таблице (осторожно!):
UPDATE users SET status = 'active' WHERE status = 'pending';
Используйте на тестовых базах!
📌 6. Удалить записи по условию (ещё осторожнее!):
DELETE FROM users WHERE created_at < '2024-01-01';
Перед выполнением лучше сделать
SELECT, чтобы убедиться, что удалите именно то, что нужно. 📌 7. Соединение двух таблиц (JOIN):
SELECT u.name, o.total
FROM users u
JOIN orders o ON u.id = o.user_id;
Когда тестируете связь между пользователями и их заказами.
📌 8. Найти записи, содержащие слово:
SELECT * FROM products WHERE name LIKE '%apple%';
Пригодится для проверки поиска в базе.
📌 9. Посчитать среднюю сумму заказов:
SELECT AVG(total) FROM orders;
Когда нужно проверить расчёты в отчётах.
📌 10. Найти пользователей, которые не сделали заказ:
SELECT * FROM users
WHERE id NOT IN (SELECT user_id FROM orders);
Для анализа пользователей без активности.
Попробуйте эти запросы в деле и напишите, какие из них вам пригодились или какие ещё вы используете в тестировании! 👇
#qa #testing
Подпишись👉 @testlab_qa
👍9
🛠️ Как тестировщику доказать баг?
Бывало такое, что ты нашел баг, но разработчик говорит: "Это не баг, а фича", или "Не могу воспроизвести, у меня все работает"? Сегодня разберем, как аргументированно доказать существование бага и избежать холиваров с разработчиками.
✅ 1. Четкая и полная баг-репортация
Хороший баг-репорт — 90% успеха. Опиши:
- Ожидаемый результат: Как система должна работать.
- Фактический результат: Как работает на самом деле.
- Шаги воспроизведения: Детальный сценарий с примерами.
- Среда тестирования: ОС, браузер, версия ПО, устройство и т. д.
- Лог-файлы, скриншоты, видео: Визуальное подтверждение бага.
✅ 2. Доказательство на данных
Если баг связан с логикой работы системы, можно показать несоответствия в базе данных, логах или API-запросах. Например, разница между сохраненными и отображаемыми данными.
✅ 3. Использование аналогий
Некоторые баги сложно объяснить словами. В таком случае помогают аналогии:
"Представь, ты заказал кофе, а тебе принесли чай. Вроде тоже напиток, но явно не то, что ожидалось."
✅ 4. Повторное тестирование на разных окружениях
Если разработчик говорит "У меня работает", попробуй:
- Разные браузеры и версии.
- Другое устройство/операционную систему.
- Включение/отключение кэша.
- Использование другого тестового аккаунта.
✅ 5. Сообщение о критичности
Не все баги одинаково важны. Покажи влияние бага:
- Нарушение функциональности?
- Угроза безопасности?
- Блокировка работы пользователя?
👉 Если разработчик все равно не соглашается — можно привлечь тимлида, аналитика или другого QA, чтобы обсудить баг с разных точек зрения.
Как ты доказываешь баги? Поделись в комментариях! 👇
#qa #testing
Подпишись👉 @testlab_qa
Бывало такое, что ты нашел баг, но разработчик говорит: "Это не баг, а фича", или "Не могу воспроизвести, у меня все работает"? Сегодня разберем, как аргументированно доказать существование бага и избежать холиваров с разработчиками.
✅ 1. Четкая и полная баг-репортация
Хороший баг-репорт — 90% успеха. Опиши:
- Ожидаемый результат: Как система должна работать.
- Фактический результат: Как работает на самом деле.
- Шаги воспроизведения: Детальный сценарий с примерами.
- Среда тестирования: ОС, браузер, версия ПО, устройство и т. д.
- Лог-файлы, скриншоты, видео: Визуальное подтверждение бага.
✅ 2. Доказательство на данных
Если баг связан с логикой работы системы, можно показать несоответствия в базе данных, логах или API-запросах. Например, разница между сохраненными и отображаемыми данными.
✅ 3. Использование аналогий
Некоторые баги сложно объяснить словами. В таком случае помогают аналогии:
"Представь, ты заказал кофе, а тебе принесли чай. Вроде тоже напиток, но явно не то, что ожидалось."
✅ 4. Повторное тестирование на разных окружениях
Если разработчик говорит "У меня работает", попробуй:
- Разные браузеры и версии.
- Другое устройство/операционную систему.
- Включение/отключение кэша.
- Использование другого тестового аккаунта.
✅ 5. Сообщение о критичности
Не все баги одинаково важны. Покажи влияние бага:
- Нарушение функциональности?
- Угроза безопасности?
- Блокировка работы пользователя?
👉 Если разработчик все равно не соглашается — можно привлечь тимлида, аналитика или другого QA, чтобы обсудить баг с разных точек зрения.
Как ты доказываешь баги? Поделись в комментариях! 👇
#qa #testing
Подпишись👉 @testlab_qa
👍3❤1🔥1
Подборка Telegram каналов для программистов
https://t.iss.one/bash_srv Bash Советы
https://t.iss.one/win_sysadmin Системный Администратор Windows
https://t.iss.one/lifeproger Жизнь программиста. Авторский канал.
https://t.iss.one/devopslib Библиотека девопса | DevOps, SRE, Sysadmin
https://t.iss.one/rabota1C_rus Вакансии для программистов 1С
Системное администрирование 📌
https://t.iss.one/sysadmin_girl Девочка Сисадмин
https://t.iss.one/srv_admin_linux Админские угодья
https://t.iss.one/linux_srv Типичный Сисадмин
https://t.iss.one/linux_odmin Linux: Системный администратор
https://t.iss.one/devops_star DevOps Star (Звезда Девопса)
https://t.iss.one/i_linux Системный администратор
https://t.iss.one/linuxchmod Linux
https://t.iss.one/sys_adminos Системный Администратор
https://t.iss.one/tipsysdmin Типичный Сисадмин (фото железа, было/стало)
https://t.iss.one/sysadminof Книги для админов, полезные материалы
https://t.iss.one/i_odmin Все для системного администратора
https://t.iss.one/i_odmin_book Библиотека Системного Администратора
https://t.iss.one/i_odmin_chat Чат системных администраторов
https://t.iss.one/i_DevOps DevOps: Пишем о Docker, Kubernetes и др.
https://t.iss.one/sysadminoff Новости Линукс Linux
1C разработка 📌
https://t.iss.one/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://t.iss.one/DevLab1C 1С:Предприятие 8
Программирование C++📌
https://t.iss.one/cpp_lib Библиотека C/C++ разработчика
https://t.iss.one/cpp_knigi Книги для программистов C/C++
https://t.iss.one/cpp_geek Учим C/C++ на примерах
Программирование Python 📌
https://t.iss.one/pythonofff Python академия. Учи Python быстро и легко🐍
https://t.iss.one/BookPython Библиотека Python разработчика
https://t.iss.one/python_real Python подборки на русском и английском
https://t.iss.one/python_360 Книги по Python Rus
Java разработка 📌
https://t.iss.one/BookJava Библиотека Java разработчика
https://t.iss.one/java_360 Книги по Java Rus
https://t.iss.one/java_geek Учим Java на примерах
GitHub Сообщество 📌
https://t.iss.one/Githublib Интересное из GitHub
Базы данных (Data Base) 📌
https://t.iss.one/database_info Все про базы данных
Мобильная разработка: iOS, Android 📌
https://t.iss.one/developer_mobila Мобильная разработка
https://t.iss.one/kotlin_lib Подборки полезного материала по Kotlin
Фронтенд разработка 📌
https://t.iss.one/frontend_1 Подборки для frontend разработчиков
https://t.iss.one/frontend_sovet Frontend советы, примеры и практика!
https://t.iss.one/React_lib Подборки по React js и все что с ним связано
Разработка игр 📌
https://t.iss.one/game_devv Все о разработке игр
Библиотеки 📌
https://t.iss.one/book_for_dev Книги для программистов Rus
https://t.iss.one/programmist_of Книги по программированию
https://t.iss.one/proglb Библиотека программиста
https://t.iss.one/bfbook Книги для программистов
https://t.iss.one/books_reserv Книги для программистов
БигДата, машинное обучение 📌
https://t.iss.one/bigdata_1 Data Science, Big Data, Machine Learning, Deep Learning
Программирование 📌
https://t.iss.one/bookflow Лекции, видеоуроки, доклады с IT конференций
https://t.iss.one/coddy_academy Полезные советы по программированию
https://t.iss.one/rust_lib Полезный контент по программированию на Rust
https://t.iss.one/golang_lib Библиотека Go (Golang) разработчика
https://t.iss.one/itmozg Программисты, дизайнеры, новости из мира IT
https://t.iss.one/php_lib Библиотека PHP программиста 👨🏼💻👩💻
https://t.iss.one/nodejs_lib Подборки по Node js и все что с ним связано
https://t.iss.one/ruby_lib Библиотека Ruby программиста
QA, тестирование 📌
https://t.iss.one/testlab_qa Библиотека тестировщика
Шутки программистов 📌
https://t.iss.one/itumor Шутки программистов
Защита, взлом, безопасность 📌
https://t.iss.one/thehaking Канал о кибербезопасности
https://t.iss.one/xakep_2 Хакер Free
Книги, статьи для дизайнеров 📌
https://t.iss.one/ux_web Статьи, книги для дизайнеров
Математика 📌
https://t.iss.one/Pomatematike Канал по математике
https://t.iss.one/phis_mat Обучающие видео, книги по Физике и Математике
Excel лайфхак📌
https://t.iss.one/Excel_lifehack
https://t.iss.one/tikon_1 Новости высоких технологий, науки и техники💡
https://t.iss.one/mir_teh Мир технологий (Technology World)
Вакансии 📌
https://t.iss.one/sysadmin_rabota Системный Администратор
https://t.iss.one/progjob Вакансии в IT
https://t.iss.one/bash_srv Bash Советы
https://t.iss.one/win_sysadmin Системный Администратор Windows
https://t.iss.one/lifeproger Жизнь программиста. Авторский канал.
https://t.iss.one/devopslib Библиотека девопса | DevOps, SRE, Sysadmin
https://t.iss.one/rabota1C_rus Вакансии для программистов 1С
Системное администрирование 📌
https://t.iss.one/sysadmin_girl Девочка Сисадмин
https://t.iss.one/srv_admin_linux Админские угодья
https://t.iss.one/linux_srv Типичный Сисадмин
https://t.iss.one/linux_odmin Linux: Системный администратор
https://t.iss.one/devops_star DevOps Star (Звезда Девопса)
https://t.iss.one/i_linux Системный администратор
https://t.iss.one/linuxchmod Linux
https://t.iss.one/sys_adminos Системный Администратор
https://t.iss.one/tipsysdmin Типичный Сисадмин (фото железа, было/стало)
https://t.iss.one/sysadminof Книги для админов, полезные материалы
https://t.iss.one/i_odmin Все для системного администратора
https://t.iss.one/i_odmin_book Библиотека Системного Администратора
https://t.iss.one/i_odmin_chat Чат системных администраторов
https://t.iss.one/i_DevOps DevOps: Пишем о Docker, Kubernetes и др.
https://t.iss.one/sysadminoff Новости Линукс Linux
1C разработка 📌
https://t.iss.one/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://t.iss.one/DevLab1C 1С:Предприятие 8
Программирование C++📌
https://t.iss.one/cpp_lib Библиотека C/C++ разработчика
https://t.iss.one/cpp_knigi Книги для программистов C/C++
https://t.iss.one/cpp_geek Учим C/C++ на примерах
Программирование Python 📌
https://t.iss.one/pythonofff Python академия. Учи Python быстро и легко🐍
https://t.iss.one/BookPython Библиотека Python разработчика
https://t.iss.one/python_real Python подборки на русском и английском
https://t.iss.one/python_360 Книги по Python Rus
Java разработка 📌
https://t.iss.one/BookJava Библиотека Java разработчика
https://t.iss.one/java_360 Книги по Java Rus
https://t.iss.one/java_geek Учим Java на примерах
GitHub Сообщество 📌
https://t.iss.one/Githublib Интересное из GitHub
Базы данных (Data Base) 📌
https://t.iss.one/database_info Все про базы данных
Мобильная разработка: iOS, Android 📌
https://t.iss.one/developer_mobila Мобильная разработка
https://t.iss.one/kotlin_lib Подборки полезного материала по Kotlin
Фронтенд разработка 📌
https://t.iss.one/frontend_1 Подборки для frontend разработчиков
https://t.iss.one/frontend_sovet Frontend советы, примеры и практика!
https://t.iss.one/React_lib Подборки по React js и все что с ним связано
Разработка игр 📌
https://t.iss.one/game_devv Все о разработке игр
Библиотеки 📌
https://t.iss.one/book_for_dev Книги для программистов Rus
https://t.iss.one/programmist_of Книги по программированию
https://t.iss.one/proglb Библиотека программиста
https://t.iss.one/bfbook Книги для программистов
https://t.iss.one/books_reserv Книги для программистов
БигДата, машинное обучение 📌
https://t.iss.one/bigdata_1 Data Science, Big Data, Machine Learning, Deep Learning
Программирование 📌
https://t.iss.one/bookflow Лекции, видеоуроки, доклады с IT конференций
https://t.iss.one/coddy_academy Полезные советы по программированию
https://t.iss.one/rust_lib Полезный контент по программированию на Rust
https://t.iss.one/golang_lib Библиотека Go (Golang) разработчика
https://t.iss.one/itmozg Программисты, дизайнеры, новости из мира IT
https://t.iss.one/php_lib Библиотека PHP программиста 👨🏼💻👩💻
https://t.iss.one/nodejs_lib Подборки по Node js и все что с ним связано
https://t.iss.one/ruby_lib Библиотека Ruby программиста
QA, тестирование 📌
https://t.iss.one/testlab_qa Библиотека тестировщика
Шутки программистов 📌
https://t.iss.one/itumor Шутки программистов
Защита, взлом, безопасность 📌
https://t.iss.one/thehaking Канал о кибербезопасности
https://t.iss.one/xakep_2 Хакер Free
Книги, статьи для дизайнеров 📌
https://t.iss.one/ux_web Статьи, книги для дизайнеров
Математика 📌
https://t.iss.one/Pomatematike Канал по математике
https://t.iss.one/phis_mat Обучающие видео, книги по Физике и Математике
Excel лайфхак📌
https://t.iss.one/Excel_lifehack
https://t.iss.one/tikon_1 Новости высоких технологий, науки и техники💡
https://t.iss.one/mir_teh Мир технологий (Technology World)
Вакансии 📌
https://t.iss.one/sysadmin_rabota Системный Администратор
https://t.iss.one/progjob Вакансии в IT
Telegram
Bash Советы
🚀 Секреты и советы по Bash
🔹 Полезные трюки, хитрые однострочники и лайфхаки для работы в терминале.
🔹 Автоматизация, скрипты и оптимизация работы в Linux.
🔹 Стать мастером Bash легко – просто подпишись!
По всем вопросам @evgenycarter
🔹 Полезные трюки, хитрые однострочники и лайфхаки для работы в терминале.
🔹 Автоматизация, скрипты и оптимизация работы в Linux.
🔹 Стать мастером Bash легко – просто подпишись!
По всем вопросам @evgenycarter
Как убедиться, что баг исправлен?
Сегодня поговорим о важной теме – как правильно проверять баг после его исправления. Часто разработчик говорит: "Исправил, проверяй!", и тут важно не просто кликнуть на кнопку, а провести грамотную регрессию.
🔍 Как правильно проверять исправленный баг?
1️⃣ Проверяем, что баг действительно исправлен.
– Берём шаги воспроизведения из бага.
– Повторяем их в той же среде и на той же версии, где было исправление.
– Сравниваем результат с ожидаемым поведением.
2️⃣ Проверяем окрестности бага.
– Часто фиксы ломают соседний функционал. Например, исправили баг в авторизации – проверьте регистрацию, сброс пароля.
3️⃣ Проверяем на разных данных.
– Если баг связан с вводом данных, попробуйте крайние случаи: длинные строки, спецсимволы, пустые значения.
4️⃣ Тестируем в разных окружениях.
– Проверьте на разных браузерах, устройствах, API-запросах (если актуально).
5️⃣ Смотрим логи и консоль.
– Иногда баг "ушёл в тень" – UI работает, но в логах ошибки. Проверьте DevTools или серверные логи.
6️⃣ Запускаем регрессию.
– Если баг был в сложном сценарии, стоит перепройти весь сценарий целиком.
7️⃣ Оцениваем влияние на производительность.
– Если был сложный рефакторинг, проверьте, не замедлился ли интерфейс или API.
💡 Совет: Важно не просто убедиться, что баг "пропал", но и что он не привёл к новым проблемам.
Как вы проверяете баги после фикса? Делитесь своими лайфхаками в комментариях! 👇
#qa #testing
Подпишись👉 @testlab_qa
Сегодня поговорим о важной теме – как правильно проверять баг после его исправления. Часто разработчик говорит: "Исправил, проверяй!", и тут важно не просто кликнуть на кнопку, а провести грамотную регрессию.
🔍 Как правильно проверять исправленный баг?
1️⃣ Проверяем, что баг действительно исправлен.
– Берём шаги воспроизведения из бага.
– Повторяем их в той же среде и на той же версии, где было исправление.
– Сравниваем результат с ожидаемым поведением.
2️⃣ Проверяем окрестности бага.
– Часто фиксы ломают соседний функционал. Например, исправили баг в авторизации – проверьте регистрацию, сброс пароля.
3️⃣ Проверяем на разных данных.
– Если баг связан с вводом данных, попробуйте крайние случаи: длинные строки, спецсимволы, пустые значения.
4️⃣ Тестируем в разных окружениях.
– Проверьте на разных браузерах, устройствах, API-запросах (если актуально).
5️⃣ Смотрим логи и консоль.
– Иногда баг "ушёл в тень" – UI работает, но в логах ошибки. Проверьте DevTools или серверные логи.
6️⃣ Запускаем регрессию.
– Если баг был в сложном сценарии, стоит перепройти весь сценарий целиком.
7️⃣ Оцениваем влияние на производительность.
– Если был сложный рефакторинг, проверьте, не замедлился ли интерфейс или API.
💡 Совет: Важно не просто убедиться, что баг "пропал", но и что он не привёл к новым проблемам.
Как вы проверяете баги после фикса? Делитесь своими лайфхаками в комментариях! 👇
#qa #testing
Подпишись👉 @testlab_qa
👍3
Автоматизация тестирования, которая не ломается при первом редизайне
Меня зовут Артем, я эксперт по тестированию в компании TData — разработчике высоконагруженных корпоративных решений для работы с данными в реальном времени. Мы создаём ПО, где особенно важны стабильность, отказоустойчивость и предсказуемость поведения — вне зависимости от нагрузки и сложности сценариев.
Автоматизация тестирования для нас — не просто способ снять нагрузку с ручных тестировщиков, а часть инженерной культуры. В этой статье поделюсь тем, как мы выстраивали автоматизацию: с чего начали, почему стартовали с UI, какие инструменты прижились, как справлялись с нестабильными тестами. Давайте разберёмся, как не заблудиться на этом увлекательном, но местами запутанном пути.
https://habr.com/ru/companies/rostelecom/articles/894074/
#qa #testing
Подпишись👉 @testlab_qa
Меня зовут Артем, я эксперт по тестированию в компании TData — разработчике высоконагруженных корпоративных решений для работы с данными в реальном времени. Мы создаём ПО, где особенно важны стабильность, отказоустойчивость и предсказуемость поведения — вне зависимости от нагрузки и сложности сценариев.
Автоматизация тестирования для нас — не просто способ снять нагрузку с ручных тестировщиков, а часть инженерной культуры. В этой статье поделюсь тем, как мы выстраивали автоматизацию: с чего начали, почему стартовали с UI, какие инструменты прижились, как справлялись с нестабильными тестами. Давайте разберёмся, как не заблудиться на этом увлекательном, но местами запутанном пути.
https://habr.com/ru/companies/rostelecom/articles/894074/
#qa #testing
Подпишись👉 @testlab_qa
👍2
Как избавиться от нестабильных тестов и ускорить развертывание?
Приглашаем на открытый урок «Оптимизация CI/CD для мобильных тестов на Kotlin»
Настроим CI/CD для мобильных тестов на Kotlin: работа с GitHub Actions/GitLab CI, эмуляторами и реальными устройствами.
Разберем причины флейковых тестов в Android-тестировании: тайминги, нестабильные UI-элементы, инфраструктурные ограничения.
Рассмотрим методы ускорения и инструменты для стабильности и отчетности: Espresso, UIAutomator, Firebase Test Lab, Allure.
✅ Практика: Настроим CI/CD пайплайн для запуска тестов на Android-устройствах и эмуляторах.
👉 Регистрация на урок: https://vk.cc/cKf50g
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
Приглашаем на открытый урок «Оптимизация CI/CD для мобильных тестов на Kotlin»
Настроим CI/CD для мобильных тестов на Kotlin: работа с GitHub Actions/GitLab CI, эмуляторами и реальными устройствами.
Разберем причины флейковых тестов в Android-тестировании: тайминги, нестабильные UI-элементы, инфраструктурные ограничения.
Рассмотрим методы ускорения и инструменты для стабильности и отчетности: Espresso, UIAutomator, Firebase Test Lab, Allure.
✅ Практика: Настроим CI/CD пайплайн для запуска тестов на Android-устройствах и эмуляторах.
👉 Регистрация на урок: https://vk.cc/cKf50g
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
Сегодня хочу напомнить об одной неочевидной ловушке при проверке багфикса.
Допустим, разработчик починил баг, вы повторили шаги — баг не воспроизводится. Всё, можно закрывать?
❌ Нет. Это ошибка новичка.
✅ Проверка багфикса — это не только “воспроизводится/не воспроизводится”.
Нужно всегда делать микро-регрессию вокруг бага. Почему?
Пример из практики:
*Баг — не сохраняется поле "email" при редактировании профиля.*
После фикса вы проверили — теперь email сохраняется. Но из-за изменения логики перестало сохраняться имя. 🤦♂️
🔁 Что делать правильно:
1. Проверить сам баг по шагам
2. Проверить смежные поля, действия, модули
3. Заглянуть в логи (если можете)
4. Задать себе вопрос: “Мог ли фикс задеть что-то ещё?”
Такой подход выделяет сильного тестировщика.
Будь не просто “проверяющим баги”, а гарантом стабильности 💪
А ты делаешь мини-регрессию после фикса или ограничиваешься проверкой одного сценария?
#qa #testing
Подпишись👉 @testlab_qa
Допустим, разработчик починил баг, вы повторили шаги — баг не воспроизводится. Всё, можно закрывать?
❌ Нет. Это ошибка новичка.
✅ Проверка багфикса — это не только “воспроизводится/не воспроизводится”.
Нужно всегда делать микро-регрессию вокруг бага. Почему?
Пример из практики:
*Баг — не сохраняется поле "email" при редактировании профиля.*
После фикса вы проверили — теперь email сохраняется. Но из-за изменения логики перестало сохраняться имя. 🤦♂️
🔁 Что делать правильно:
1. Проверить сам баг по шагам
2. Проверить смежные поля, действия, модули
3. Заглянуть в логи (если можете)
4. Задать себе вопрос: “Мог ли фикс задеть что-то ещё?”
Такой подход выделяет сильного тестировщика.
Будь не просто “проверяющим баги”, а гарантом стабильности 💪
А ты делаешь мини-регрессию после фикса или ограничиваешься проверкой одного сценария?
#qa #testing
Подпишись👉 @testlab_qa
👍6💯1
Подборка Telegram каналов для программистов
https://t.iss.one/bash_srv Bash Советы
https://t.iss.one/win_sysadmin Системный Администратор Windows
https://t.iss.one/lifeproger Жизнь программиста. Авторский канал.
https://t.iss.one/devopslib Библиотека девопса | DevOps, SRE, Sysadmin
https://t.iss.one/rabota1C_rus Вакансии для программистов 1С
Системное администрирование 📌
https://t.iss.one/sysadmin_girl Девочка Сисадмин
https://t.iss.one/srv_admin_linux Админские угодья
https://t.iss.one/linux_srv Типичный Сисадмин
https://t.iss.one/linux_odmin Linux: Системный администратор
https://t.iss.one/devops_star DevOps Star (Звезда Девопса)
https://t.iss.one/i_linux Системный администратор
https://t.iss.one/linuxchmod Linux
https://t.iss.one/sys_adminos Системный Администратор
https://t.iss.one/tipsysdmin Типичный Сисадмин (фото железа, было/стало)
https://t.iss.one/sysadminof Книги для админов, полезные материалы
https://t.iss.one/i_odmin Все для системного администратора
https://t.iss.one/i_odmin_book Библиотека Системного Администратора
https://t.iss.one/i_odmin_chat Чат системных администраторов
https://t.iss.one/i_DevOps DevOps: Пишем о Docker, Kubernetes и др.
https://t.iss.one/sysadminoff Новости Линукс Linux
1C разработка 📌
https://t.iss.one/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://t.iss.one/DevLab1C 1С:Предприятие 8
Программирование C++📌
https://t.iss.one/cpp_lib Библиотека C/C++ разработчика
https://t.iss.one/cpp_knigi Книги для программистов C/C++
https://t.iss.one/cpp_geek Учим C/C++ на примерах
Программирование Python 📌
https://t.iss.one/pythonofff Python академия. Учи Python быстро и легко🐍
https://t.iss.one/BookPython Библиотека Python разработчика
https://t.iss.one/python_real Python подборки на русском и английском
https://t.iss.one/python_360 Книги по Python Rus
Java разработка 📌
https://t.iss.one/BookJava Библиотека Java разработчика
https://t.iss.one/java_360 Книги по Java Rus
https://t.iss.one/java_geek Учим Java на примерах
GitHub Сообщество 📌
https://t.iss.one/Githublib Интересное из GitHub
Базы данных (Data Base) 📌
https://t.iss.one/database_info Все про базы данных
Мобильная разработка: iOS, Android 📌
https://t.iss.one/developer_mobila Мобильная разработка
https://t.iss.one/kotlin_lib Подборки полезного материала по Kotlin
Фронтенд разработка 📌
https://t.iss.one/frontend_1 Подборки для frontend разработчиков
https://t.iss.one/frontend_sovet Frontend советы, примеры и практика!
https://t.iss.one/React_lib Подборки по React js и все что с ним связано
Разработка игр 📌
https://t.iss.one/game_devv Все о разработке игр
Библиотеки 📌
https://t.iss.one/book_for_dev Книги для программистов Rus
https://t.iss.one/programmist_of Книги по программированию
https://t.iss.one/proglb Библиотека программиста
https://t.iss.one/bfbook Книги для программистов
https://t.iss.one/books_reserv Книги для программистов
БигДата, машинное обучение 📌
https://t.iss.one/bigdata_1 Data Science, Big Data, Machine Learning, Deep Learning
Программирование 📌
https://t.iss.one/bookflow Лекции, видеоуроки, доклады с IT конференций
https://t.iss.one/coddy_academy Полезные советы по программированию
https://t.iss.one/rust_lib Полезный контент по программированию на Rust
https://t.iss.one/golang_lib Библиотека Go (Golang) разработчика
https://t.iss.one/itmozg Программисты, дизайнеры, новости из мира IT
https://t.iss.one/php_lib Библиотека PHP программиста 👨🏼💻👩💻
https://t.iss.one/nodejs_lib Подборки по Node js и все что с ним связано
https://t.iss.one/ruby_lib Библиотека Ruby программиста
QA, тестирование 📌
https://t.iss.one/testlab_qa Библиотека тестировщика
Шутки программистов 📌
https://t.iss.one/itumor Шутки программистов
Защита, взлом, безопасность 📌
https://t.iss.one/thehaking Канал о кибербезопасности
https://t.iss.one/xakep_2 Хакер Free
Книги, статьи для дизайнеров 📌
https://t.iss.one/ux_web Статьи, книги для дизайнеров
Математика 📌
https://t.iss.one/Pomatematike Канал по математике
https://t.iss.one/phis_mat Обучающие видео, книги по Физике и Математике
Excel лайфхак📌
https://t.iss.one/Excel_lifehack
https://t.iss.one/tikon_1 Новости высоких технологий, науки и техники💡
https://t.iss.one/mir_teh Мир технологий (Technology World)
Вакансии 📌
https://t.iss.one/sysadmin_rabota Системный Администратор
https://t.iss.one/progjob Вакансии в IT
https://t.iss.one/bash_srv Bash Советы
https://t.iss.one/win_sysadmin Системный Администратор Windows
https://t.iss.one/lifeproger Жизнь программиста. Авторский канал.
https://t.iss.one/devopslib Библиотека девопса | DevOps, SRE, Sysadmin
https://t.iss.one/rabota1C_rus Вакансии для программистов 1С
Системное администрирование 📌
https://t.iss.one/sysadmin_girl Девочка Сисадмин
https://t.iss.one/srv_admin_linux Админские угодья
https://t.iss.one/linux_srv Типичный Сисадмин
https://t.iss.one/linux_odmin Linux: Системный администратор
https://t.iss.one/devops_star DevOps Star (Звезда Девопса)
https://t.iss.one/i_linux Системный администратор
https://t.iss.one/linuxchmod Linux
https://t.iss.one/sys_adminos Системный Администратор
https://t.iss.one/tipsysdmin Типичный Сисадмин (фото железа, было/стало)
https://t.iss.one/sysadminof Книги для админов, полезные материалы
https://t.iss.one/i_odmin Все для системного администратора
https://t.iss.one/i_odmin_book Библиотека Системного Администратора
https://t.iss.one/i_odmin_chat Чат системных администраторов
https://t.iss.one/i_DevOps DevOps: Пишем о Docker, Kubernetes и др.
https://t.iss.one/sysadminoff Новости Линукс Linux
1C разработка 📌
https://t.iss.one/odin1C_rus Cтатьи, курсы, советы, шаблоны кода 1С
https://t.iss.one/DevLab1C 1С:Предприятие 8
Программирование C++📌
https://t.iss.one/cpp_lib Библиотека C/C++ разработчика
https://t.iss.one/cpp_knigi Книги для программистов C/C++
https://t.iss.one/cpp_geek Учим C/C++ на примерах
Программирование Python 📌
https://t.iss.one/pythonofff Python академия. Учи Python быстро и легко🐍
https://t.iss.one/BookPython Библиотека Python разработчика
https://t.iss.one/python_real Python подборки на русском и английском
https://t.iss.one/python_360 Книги по Python Rus
Java разработка 📌
https://t.iss.one/BookJava Библиотека Java разработчика
https://t.iss.one/java_360 Книги по Java Rus
https://t.iss.one/java_geek Учим Java на примерах
GitHub Сообщество 📌
https://t.iss.one/Githublib Интересное из GitHub
Базы данных (Data Base) 📌
https://t.iss.one/database_info Все про базы данных
Мобильная разработка: iOS, Android 📌
https://t.iss.one/developer_mobila Мобильная разработка
https://t.iss.one/kotlin_lib Подборки полезного материала по Kotlin
Фронтенд разработка 📌
https://t.iss.one/frontend_1 Подборки для frontend разработчиков
https://t.iss.one/frontend_sovet Frontend советы, примеры и практика!
https://t.iss.one/React_lib Подборки по React js и все что с ним связано
Разработка игр 📌
https://t.iss.one/game_devv Все о разработке игр
Библиотеки 📌
https://t.iss.one/book_for_dev Книги для программистов Rus
https://t.iss.one/programmist_of Книги по программированию
https://t.iss.one/proglb Библиотека программиста
https://t.iss.one/bfbook Книги для программистов
https://t.iss.one/books_reserv Книги для программистов
БигДата, машинное обучение 📌
https://t.iss.one/bigdata_1 Data Science, Big Data, Machine Learning, Deep Learning
Программирование 📌
https://t.iss.one/bookflow Лекции, видеоуроки, доклады с IT конференций
https://t.iss.one/coddy_academy Полезные советы по программированию
https://t.iss.one/rust_lib Полезный контент по программированию на Rust
https://t.iss.one/golang_lib Библиотека Go (Golang) разработчика
https://t.iss.one/itmozg Программисты, дизайнеры, новости из мира IT
https://t.iss.one/php_lib Библиотека PHP программиста 👨🏼💻👩💻
https://t.iss.one/nodejs_lib Подборки по Node js и все что с ним связано
https://t.iss.one/ruby_lib Библиотека Ruby программиста
QA, тестирование 📌
https://t.iss.one/testlab_qa Библиотека тестировщика
Шутки программистов 📌
https://t.iss.one/itumor Шутки программистов
Защита, взлом, безопасность 📌
https://t.iss.one/thehaking Канал о кибербезопасности
https://t.iss.one/xakep_2 Хакер Free
Книги, статьи для дизайнеров 📌
https://t.iss.one/ux_web Статьи, книги для дизайнеров
Математика 📌
https://t.iss.one/Pomatematike Канал по математике
https://t.iss.one/phis_mat Обучающие видео, книги по Физике и Математике
Excel лайфхак📌
https://t.iss.one/Excel_lifehack
https://t.iss.one/tikon_1 Новости высоких технологий, науки и техники💡
https://t.iss.one/mir_teh Мир технологий (Technology World)
Вакансии 📌
https://t.iss.one/sysadmin_rabota Системный Администратор
https://t.iss.one/progjob Вакансии в IT
Telegram
Bash Советы
🚀 Секреты и советы по Bash
🔹 Полезные трюки, хитрые однострочники и лайфхаки для работы в терминале.
🔹 Автоматизация, скрипты и оптимизация работы в Linux.
🔹 Стать мастером Bash легко – просто подпишись!
По всем вопросам @evgenycarter
🔹 Полезные трюки, хитрые однострочники и лайфхаки для работы в терминале.
🔹 Автоматизация, скрипты и оптимизация работы в Linux.
🔹 Стать мастером Bash легко – просто подпишись!
По всем вопросам @evgenycarter
🔁 Как убедиться, что баг пофикшен?
Привет, коллеги! Сегодня поделюсь одной из простых, но часто игнорируемых практик: как правильно проверять, что баг действительно исправлен.
Многие ограничиваются просто: ну, теперь вроде работает, — и закрывают баг. Но это путь к регрессии.
Вот мой чеклист, который я использую после того, как разработчик говорит: готово, можно проверять:
1. Повторить шаги воспроизведения из описания бага.
Если баг воспроизводился при специфическом сценарии — проверь именно его.
2. Проверить рядом стоящий функционал.
Часто правка одной части кода влияет на соседние участки. Потрать 2–3 минуты на мини-ревизию.
3. Проверить, что баг действительно был.
Если ты не был автором бага — воспроизведи его на предыдущей версии (например, на staging-е или через старую сборку). Так ты точно знаешь, что баг не магическим образом исчез.
4. Погоняй автотесты.
Если есть автотесты — запусти регрессию хотя бы частично. Особенно, если баг был в критичном месте.
5. Коммуникация с разработчиком.
Не бойся задать уточняющие вопросы: что именно поменяли? или может ли это повлиять на X?. Это не придирки — это твоя работа.
Если ты внедришь эту практику — количество возвращающихся багов в спринте ощутимо уменьшится.
#qa #testing
Подпишись👉 @testlab_qa
Привет, коллеги! Сегодня поделюсь одной из простых, но часто игнорируемых практик: как правильно проверять, что баг действительно исправлен.
Многие ограничиваются просто: ну, теперь вроде работает, — и закрывают баг. Но это путь к регрессии.
Вот мой чеклист, который я использую после того, как разработчик говорит: готово, можно проверять:
1. Повторить шаги воспроизведения из описания бага.
Если баг воспроизводился при специфическом сценарии — проверь именно его.
2. Проверить рядом стоящий функционал.
Часто правка одной части кода влияет на соседние участки. Потрать 2–3 минуты на мини-ревизию.
3. Проверить, что баг действительно был.
Если ты не был автором бага — воспроизведи его на предыдущей версии (например, на staging-е или через старую сборку). Так ты точно знаешь, что баг не магическим образом исчез.
4. Погоняй автотесты.
Если есть автотесты — запусти регрессию хотя бы частично. Особенно, если баг был в критичном месте.
5. Коммуникация с разработчиком.
Не бойся задать уточняющие вопросы: что именно поменяли? или может ли это повлиять на X?. Это не придирки — это твоя работа.
Если ты внедришь эту практику — количество возвращающихся багов в спринте ощутимо уменьшится.
#qa #testing
Подпишись👉 @testlab_qa
👍6
✅Зачем нужно контрактное тестирование в Kotlin QA и как гарантировать, что фронтенд и бэкенд понимают друг друга?
Приглашаем вас на открытый урок курса «Kotlin QA Engineer» от Otus, где рассмотрим инструменты для контрактного тестирования на Kotlin: Pact, Spring Cloud Contract и их отличие от интеграционных тестов.
Разберемся, как Kotlin QA-инженеры могут использовать Pact для тестирования API взаимодействия между сервисами.
Проведем интеграцию контрактных тестов на Kotlin в CI/CD
Обсудим best practices для Kotlin QA и разберем кейсы
Регистрация и подробности: 👇
https://vk.cc/cKBaKi
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
Приглашаем вас на открытый урок курса «Kotlin QA Engineer» от Otus, где рассмотрим инструменты для контрактного тестирования на Kotlin: Pact, Spring Cloud Contract и их отличие от интеграционных тестов.
Разберемся, как Kotlin QA-инженеры могут использовать Pact для тестирования API взаимодействия между сервисами.
Проведем интеграцию контрактных тестов на Kotlin в CI/CD
Обсудим best practices для Kotlin QA и разберем кейсы
Регистрация и подробности: 👇
https://vk.cc/cKBaKi
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
👍1