Были или планируются у вас сокращения или увольнения в сфере ИТ?
Уже опубликованы предварительные результаты опроса. Чтобы выборка была больше, приглашаем всех присоедениться к опросу, чтобы через 10 дней посмотреть на общую картинку и сравнить свою ситуацию со средним по рынку.
Автор: Рикард Эдгрен (Rikard Edgren) Оригинал Перевод: Ольга Алифанова
Часть тест-дизайна лучше отложить на этап выполнения тестов. Имея под рукой продукт, вы можете лучше принимать решения о деталях, а также поймете, какие вариации и отклонения будут быстрыми и полезными. Вы найдете часть нужной вам информации, а также информацию, о необходимости которой вы и не подозревали. Вы узнаете, какие области подвержены ошибкам, что можно быстро протестировать, о чем стоит узнать больше, что на самом деле можно делать с ПО, как все взаимосвязано, и, возможно, самое важное: что можно улучшить.
Используйте эту информацию в тест-дизайне, пересоздайте и перегруппируйте ваши тесты, вернитесь к источникам информации, которые оказались более важными, чем вы думали изначально.
QA и QC — как камыш и рогоз. Конечно, есть ботаники, которые их различают, но большинство людей всё-таки путают. Иногда самим QA и QC легче согласиться с представлением обывателей, чем пускаться в долгие объяснения, в чём же всё-таки разница. Предлагаю сделать усилие над собой, разобраться с терминами и понятиями, увидеть отличия и больше никогда их не путать.
15-18 июня состоится онлайн-конференция по тестированию Heisenbug 2020 Piter.
Что будет: — Десятки докладов от экспертов со всего мира о практическом и хардкорном тестировании на реальных проектах; — Интервью, развлекательные подкасты, технические ток-шоу и дискуссии со спикерами; — Конференция будет идти 4 дня. Чтобы участники не устали, мы разбили программу на блоки по 4-5 часов; — Каждый день — несколько параллельных треков, между которыми можно переключаться, а доклады перематывать или ставить на паузу; — Розыгрыши с призами от партнеров конференции; — Обсуждение докладов с коллегами и единомышленниками.
Среди спикеров: — Андрей Лушников, разработчик Puppeteer и участник команды разработки Playwright в Microsoft. — Эллиот Расти Гарольд (Elliotte Rusty Harold) — мейнтейнер библиотеки Jaxen XPath, коммитер в проект Apache Maven, автор библиотеки XOM для обработки XML с помощью Java. — Андрей Акиньшин, автор книги «Pro .NET Benchmarking» разработчик проектов BenchmarkDotNet и Rider. — Артем Ерошенко, автор фреймворка для построения отчётов о процессе тестирования Allure. — Адам Торнхилл (Adam Tornhill), специалист по поиску проблем в коде и борьбе с техническим долгом, создатель сервиса для анализа качества кода CodeScene. — Анна Чернышева, Lead Software Test Automation Engineer в EPAM, эксперт в области BDD, одна из создателей Self-healing библиотеки Healenium и BDD-библиотеки Akita.
Автор: Саймон Найт (Simon Knight) Оригинал статьи Перевод: Ольга Алифанова
Если вы в тестировании не первый день, и особенно если вы долго тестируете один и тот же продукт, то вы наверняка заметили, что ваш мозг начинает мыслить о тестируемом продукте определенным устоявшимся образом.
Через какое-то время вы уже знаете, где находятся самые сложные области вашего продукта, и, начиная тестировать, вы сразу нацеливаетесь на эти области, потому что они уже показали себя плодотворной почвой для сочных багов.
Но как же вы попали в эту область системы? Каким маршрутом вы шли, что вы могли упустить по дороге?
Что, если вместо того, чтобы прямой наводкой идти к этой области, вы бы свернули в совершенно ином направлении?
Тестировщики часто сталкиваются с багами, которые зависят от окружения. Иногда приходится долго настраивать все необходимые программы, чтобы проверить какую-то функциональности или запустить автотесты. А уж переезд с одной машины на другую — вечная боль.
Благо, некоторое время назад появился Docker — среда для контейнеризации софта, позволяющая легко создавать и передавать отдельные контейнеры с софтом, которые работают везде одинаково. Долгое время Docker был популярен только среди DevOps, но в последнее время он все чаще используется в тестировании.
И действительно, ведь можно один раз настроить все нужные приложения, положить их в свои контейнеры — а потом запускать где угодно и сколько угодно раз. Это значительно сокращает время тестирования и повышает его удобство.
Про устройство Docker и его преимущества вы можете узнать из видео:
А если вы хотите узнать больше — подписывайтесь на наш youtube-канал и приходите на курс “Docker: инструменты тестировщика”, где вы всего за 2 недели сможете научиться работать с этим инструментом на достаточном для QA уровне.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Все читатели моего блога знают, как я увлечена тестированием API. Мне также очень нравится пользоваться Postman для такого тестирования, потому что, по моему мнению, это самый простой способ проверки API-запросов. Поэтому меня печалит, когда я вижу, что люди тестируют API, убеждаясь только в том, что получили ответ 200! Сегодня я возьму простой GET-запрос и покажу пример 16 тестов, которые можно прогнать вместе с ним.
Автор: Ричард Брэдшоу (Richard Bradshaw) и Сара Дири (Sarah Deery) Оригинал статьи Перевод: Ольга Алифанова
Для любых тест-методов и техник верно то, что глубокое понимание того, что это такое, когда их применять, и каковы их сильные и слабые стороны – это важнейший залог их эффективного использования. Эвристики – не исключение. Вы не можете применять чек-лист эвристических техник в любых контекстах и ожидать одинаковых результатов или решения своих проблем. Их нужно применять со знанием дела, мудро и осторожно.
Как тестировщик, вы, скорее всего, знакомы с использованием эвристик для структурированного создания тестов, генерации новых тест-идей и исследования границ системы, но слышали ли вы об эвристическом праксисе? Праксис – это то, что происходит, когда тест-теория применяется к тест-практике. Это расхождение между теорией и практикой. Теория без практики – сотрясание воздуха. Практика без теории пустой звук. Лучшие тестировщики – это те, кто знает об этом и работает внутри праксис-разрыва.
Знакомая картинка? А вы ведь постоянно сталкиваетесь с этой архитектурой — когда покупаете билет в кино онлайн, бронируете путевку на море или записываетесь к врачу.
На клиент-серверной архитектуре построены все сайты и интернет-сервисы. Также ее используют десктоп-программы, которые передают данные по интернету. Поэтому ИТ-специалисту нужно понимать, что это такое и как работает.
Об этом я и расскажу в статье. Объясню на пальцах, с примерами и забавными картинками =) Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.
