Библиотека тестировщика
3.16K subscribers
435 photos
262 videos
22 files
405 links
Библиотека для тестировщика и QA. По всем вопросам @evgenycarter
Download Telegram
😀 Вы знали, что рынок мобильных игр растёт быстрее, чем вы успеваете обновить свою библиотеку в стиме? И тестирование этих игр — одна из ключевых частей индустрии.

Хотите научиться находить баги, о которых даже разработчики не догадываются? Разобраться, почему игра лагает на одном устройстве и летает на другом?

На открытом вебинаре разберём ключевые особенности тестирования мобильных игр, специфику iOS и Android, автоматизацию тестирования и лучшие практики индустрии.

Спикер Надежда Чертовских — QA Lead в Beresnev Games.

Встречаемся 25 февраля в 20:00 мск. Это ваш первый шаг к карьере в Game QA! Кстати, все участники получат скидку на большое обучение «Game QA Engineer».

👉 Регистрация открыта: https://vk.cc/cIL5T2

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
🔍 7 навыков, которые отличают хорошего тестировщика от отличного

Привет, коллеги! Сегодня я расскажу о навыках, которые делают тестировщика по-настоящему крутым специалистом. Если хочешь расти в профессии — проверь, насколько они у тебя развиты.

1️⃣ Критическое мышление
Хороший тестировщик проверяет приложение. Отличный — сомневается во всем, ставит под вопрос логику требований и находит уязвимости еще до написания кода.

2️⃣ Аналитические способности
Не просто нажимать кнопки, а понимать, зачем и что стоит за каждой функцией. Отличный тестировщик анализирует логи, следит за метриками и глубже погружается в работу продукта.

3️⃣ Знание основ программирования
Минимум — умение читать код. Максимум — написание автотестов и понимание, как работают алгоритмы.

4️⃣ Понимание бизнес-логики
Чем лучше тестировщик понимает бизнес-процессы, тем ценнее его тестирование. Ошибки, влияющие на прибыль, — самые критичные.

5️⃣ Коммуникационные навыки
Хороший тестировщик находит баги. Отличный — аргументированно объясняет их разработчикам и умеет договариваться с командой.

6️⃣ Гибкость и адаптивность
Технологии меняются, процессы меняются — тестировщик должен быстро адаптироваться и обучаться новым подходам.

7️⃣ Автоматизация рутины
Даже если ты ручной тестировщик, базовые знания CI/CD, SQL, API-тестирования и написание простых скриптов облегчат тебе жизнь.

Какой из этих навыков ты считаешь самым важным? Делись своим мнением в комментариях! 👇

#qa #testing

Подпишись👉 @testlab_qa
👍42
Разбираем фреймворк Playwright для тестирования веб-приложений

Привет, коллеги! Сегодня я хочу рассказать вам про Playwright — мощный инструмент для автоматизации тестирования веб-приложений.

Почему он так популярен? Давайте разберёмся!

🔹 Поддержка нескольких браузеров
Можно тестировать в Chromium, Firefox и WebKit без дополнительных настроек.

🔹 Работает с разными языками программирования
Поддерживает JavaScript, TypeScript, Python, Java, C#. Удобно для команд с разными технологиями.

🔹 Автоматическая обработка всплывающих окон, фреймов и вкладок
Не нужно городить сложные костыли — Playwright сам понимает, как работать с элементами.

🔹 Headless-режим и тестирование мобильных устройств
Можно запускать тесты без UI, что ускоряет их выполнение. А эмуляция мобильных устройств помогает тестировать адаптивность.

🔹 API-тестирование
Не только UI, но и API можно тестировать в одном инструменте. Это удобно и экономит время.

Как начать?
👉 Установите Playwright командой:

npm init playwright@latest

👉 Запускайте тесты в разных браузерах

npx playwright test --browser=firefox


Playwright — это будущее автоматизированного тестирования? Делитесь своим мнением в комментариях!

#qa #testing

Подпишись👉 @testlab_qa
👍3
This media is not supported in your browser
VIEW IN TELEGRAM
Тестер объясняет разработчику как воспроизвести баг

#qa #testing

Подпишись👉 @testlab_qa
😁14
#qa #testing

Подпишись👉 @testlab_qa
😁9🤣2😭2
Бесплатный практический вебинар ― Тестировщик с нуля: как начать карьеру в IT без кода и знания математики.

Когда: 6 марта в 19:00 (мск).

За 2 часа вы узнаете как устроено ручное и автоматизированное тестирование, попробуете профессию на практике и протестируете свой первый сайт.

✔️ Познакомитесь с технологиями и навыками, которые требуются для старта в тестировании. Узнаете про зарплаты и перспективы в сфере.

✔️ Протестируете 2 страницы, разберете базовые техники тест-дизайна и тест-кейсы, автоматизируете тестирование при помощи Selenium IDE, составите первый баг-репорт.

🎁 Всем, кто зарегистрировался ― Гайд «Как заговорить на сленге IT-специалистов», а в конце трансляции ― Карту компетенций джуниор тестировщика!
Почему баги возвращаются? 🤔

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

🔹 Разработчик пофиксил, но не проверил код на смежные участки.
Программное обеспечение – это не набор отдельных кусочков, а сложная система. Один фикс может затронуть другие модули. Если не учитывать влияние изменений, баг может всплыть в новом месте.

🔹 Тестировщик проверил только исправленный сценарий.
Частая ошибка – проверить только шаги бага, но не провести регрессию. Нужно учитывать контекст и возможные побочные эффекты.

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

🔹 Команда не ведёт учёт багов.
Если нет системы контроля дефектов или качественного описания фикса, баг может вернуться, потому что его просто не учли в тест-плане.

Что делать?

Проводить регрессию после каждого фикса.
Не проверяй только сам баг – тестируй и связанные модули.

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

Документировать баги и их фиксы.
Чем детальнее ты фиксируешь проблему, тем легче её предотвратить в будущем.

Общаться с разработчиками.
Задавай вопросы: какие части системы могли быть затронуты? Это поможет определить области для дополнительного тестирования.

#qa #testing

Подпишись👉 @testlab_qa
👍5
Разработка эффективных тест-кейсов для автоматизации: Руководство для опытных 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-инженеров. Продолжение.

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()) # Генерирует случайный email


4.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
🔥 10 Полезных SQL-запросов для Тестировщика

Привет, коллеги! Сегодня хочу поделиться подборкой 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
#qa #testing

Подпишись👉 @testlab_qa
😁132
🛠️ Как тестировщику доказать баг?

Бывало такое, что ты нашел баг, но разработчик говорит: "Это не баг, а фича", или "Не могу воспроизвести, у меня все работает"? Сегодня разберем, как аргументированно доказать существование бага и избежать холиваров с разработчиками.

1. Четкая и полная баг-репортация
Хороший баг-репорт — 90% успеха. Опиши:
- Ожидаемый результат: Как система должна работать.
- Фактический результат: Как работает на самом деле.
- Шаги воспроизведения: Детальный сценарий с примерами.
- Среда тестирования: ОС, браузер, версия ПО, устройство и т. д.
- Лог-файлы, скриншоты, видео: Визуальное подтверждение бага.

2. Доказательство на данных
Если баг связан с логикой работы системы, можно показать несоответствия в базе данных, логах или API-запросах. Например, разница между сохраненными и отображаемыми данными.

3. Использование аналогий
Некоторые баги сложно объяснить словами. В таком случае помогают аналогии:
"Представь, ты заказал кофе, а тебе принесли чай. Вроде тоже напиток, но явно не то, что ожидалось."

4. Повторное тестирование на разных окружениях
Если разработчик говорит "У меня работает", попробуй:
- Разные браузеры и версии.
- Другое устройство/операционную систему.
- Включение/отключение кэша.
- Использование другого тестового аккаунта.

5. Сообщение о критичности
Не все баги одинаково важны. Покажи влияние бага:
- Нарушение функциональности?
- Угроза безопасности?
- Блокировка работы пользователя?

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

Как ты доказываешь баги? Поделись в комментариях! 👇

#qa #testing

Подпишись👉 @testlab_qa
👍31🔥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
Как убедиться, что баг исправлен?

Сегодня поговорим о важной теме – как правильно проверять баг после его исправления. Часто разработчик говорит: "Исправил, проверяй!", и тут важно не просто кликнуть на кнопку, а провести грамотную регрессию.

🔍 Как правильно проверять исправленный баг?

1️⃣ Проверяем, что баг действительно исправлен.
– Берём шаги воспроизведения из бага.
– Повторяем их в той же среде и на той же версии, где было исправление.
– Сравниваем результат с ожидаемым поведением.

2️⃣ Проверяем окрестности бага.
– Часто фиксы ломают соседний функционал. Например, исправили баг в авторизации – проверьте регистрацию, сброс пароля.

3️⃣ Проверяем на разных данных.
– Если баг связан с вводом данных, попробуйте крайние случаи: длинные строки, спецсимволы, пустые значения.

4️⃣ Тестируем в разных окружениях.
– Проверьте на разных браузерах, устройствах, API-запросах (если актуально).

5️⃣ Смотрим логи и консоль.
– Иногда баг "ушёл в тень" – UI работает, но в логах ошибки. Проверьте DevTools или серверные логи.

6️⃣ Запускаем регрессию.
– Если баг был в сложном сценарии, стоит перепройти весь сценарий целиком.

7️⃣ Оцениваем влияние на производительность.
– Если был сложный рефакторинг, проверьте, не замедлился ли интерфейс или API.

💡 Совет: Важно не просто убедиться, что баг "пропал", но и что он не привёл к новым проблемам.

Как вы проверяете баги после фикса? Делитесь своими лайфхаками в комментариях! 👇

#qa #testing

Подпишись👉 @testlab_qa
👍3
#qa #testing

Подпишись👉 @testlab_qa
😁18🤣2
Автоматизация тестирования, которая не ломается при первом редизайне

Меня зовут Артем, я эксперт по тестированию в компании 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