Тестирование IT-систем *

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

Думаю, по ощущениям это похоже на пилотаж болида Формулы-1 без подготовки.

Коллеги, доброе утро. На этой неделе заканчиваем работу по доработкам swift-rur. На следующей готовим отчётность по нерезидентам. Также нас ждут изменения по санкционным спискам. И еще по дороге мы решили взять под крыло один банк — мигрировать базу будем на новогодние. Нужно обеспечить контроль.

Кстати, сегодня к нам пришел тестировщик...

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

Отчасти это даже правда, но, скорее, для ситуации, которая была на рынке лет 10 назад. Сейчас же всё обстоит несколько иначе. Причин для этого масса, и они самые разные. Если отметить ключевые, то, пожалуй, это:

Возросшие требования к тестировщикам, их знаниям и квалификации, так как всё чаще решаются задачи чуть сложнее, чем «клик-клик — и в продакшен». Работа тестировщиков становится всё более «инженерной», требует технической подкованности, специфических знаний, навыков и компетенций. Тестировщики всё чаще становится QA-инженерами (кто в теме, тот понимает разницу).

Возросшее предложение на рынке, когда толпы вчерашних «гражданских» ринулись в пучину IT, подогреваемые обилием информации: от конференций и книг до статей и курсов по тестированию ПО. Ваш покорный слуга в своё время также приложил руку к созданию пары общедоступных курсов по причине желания тиражировать базовые вещи из своей профессиональной области (посмотреть можно, например, здесь)

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

Безусловно, всё больше компаний стараются выращивать специалистов у себя под крылом, осыпая счастливчиков новыми знаниями и навыками, заодно повышая лояльность к компании. Однако и в этом случае перед компаниями и их специалистами встают животрепещущие и острые вопросы…
Как не потеряться в многообразии информации, которой наполнен интернет и мир вокруг?

Что учить самим или чему учить своих бойцов?

Информационная безопасность напрямую связана с безопасностью граждан и всего государства. Об этом не раз говорилось на международном форуме по практической безопасности Positive Hack Days 11. Живая демонстрация происходила одновременно — в ходе самой масштабной открытой кибербитвы в мире The Standoff. Мероприятия стали самыми посещаемыми в своей истории: за ними наблюдали свыше 127 тысяч зрителей онлайн, а 8700 человек посетили площадку в Москве.

В программу PHDays 11 вошло около 100 докладов, секций и круглых столов, различные конкурсы с денежными призами (например, по взлому банкомата, кассовой системы или POS-терминала), творческие фестивали Positive Wave и HackerToon, финал первого Всероссийского конкурса проектов open source для школьников и студентов, состязание по похищению произведений кибер-арта и многое другое.

Привет! Меня зовут Александра, я работаю в отделе тестирования производительности Тинькофф. Мы продолжаем наш цикл статей, посвященных работе Gatling с различными протоколами. Ранее мы уже рассмотрели работу с HTTP, JDBC и gRPC. В этой статье поговорим о работе Gatling с Kafka.

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

О чём именно захотят поговорить в офлайне участники — виднее самим участникам, а мы поделимся с Хабром тем, о чём расскажут спикеры. Собрали в одном посте описания докладов.

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

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

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

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

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

Кстати, если вы знаете еще способ, как можно было всего этого избежать, то напишите, пожалуйста.

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

На PHDays 19 мая была представлена платформа The Standoff 365 Bug Bounty, которая объединит компании и исследователей безопасности для поиска уязвимостей и оценки защищенности организаций. За первые два дня на платформе зарегистрировались 366 белых хакеров. Первыми на ней разместили свои программы «Азбука вкуса» и Positive Technologies. Спустя всего 20 минут после запуска был получен первый отчет об уязвимости.

Безусловно, тестирование важный аспект разработки ПО. Наличие тестов - это хорошо, а удобное тестирование - еще лучше. В этой статье я расскажу как запускать тесты, написанные на groovy без gradle, maven и даже без предварительной компиляции этих тестов, а также почему JUnit 5 - это намного больше, чем просто хорошая библиотека для unit тестов.

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

Этой статьёй я хочу ещё раз напомнить, как инструменты командного взаимодействия решают проблемы качественной разработки, что ответственность за качество лежит на всей команде и что agile-понятия «Прозрачность» и «Предсказуемость» часто теряются на фоне клепания тасок в Jira. Несмотря на свою очевидность, Agile-практики применяются не везде, где могли бы приносить пользу, либо применяются с ошибками и антипаттернами, противоречащими самой культуре Agile. Я расскажу, с какими сложностями столкнулся на разных этапах распространения этой культуры и что делал, чтобы их преодолеть.

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

Всем привет! Меня зовут Иван Чечиков, я QA-инженер в МТС Digital, работаю над проектом WASD.TV. В этой статье я моделирую стратегию тестирования для Agile/Scrum-проекта. Она может быть полезна небольшим командам, работающим по такой методологии. Стратегия проста, но не универсальна, вы можете дополнить ее на свое усмотрение.

Подробности – под катом.

Мы нечасто задумываемся о том, как работает тот или иной сервис и какой объём работ скрывается за тем, чтобы товар или услуга прибыли к нам вовремя. Взять, например, «чёрную пятницу» и День холостяка в e-com — дни самых больших распродаж. Казалось бы, что там такого? Со стороны может выглядеть, что главное — прогреть аудиторию предложениями разной степени заманчивости и запастись товарами на складах. Конечно, это не так. На деле нескольким дням распродаж предшествует год активной подготовки: от прогнозирования нагрузки и закупки железок до перестройки архитектуры. О том, на что мы обращали внимание и как готовились к высокому сезону, читайте под катом. 

Привет, я Black из Scalable, QA Lead в команде бэкенда по разработке биржевого ядра. Так как уже долгое время занимаюсь развитием высоконагруженной платформы, решил написать о том, как нам удалось поставить QA-процесс с 20 000 тест-кейсов, создать гибкую инфраструктуру для автоматизированного тестирования в нескольких типах API, включая асинхронные бинарные протоколы, и пройти путь разработки от отладочных утилит до специализированных тестовых фреймворков для интеграционного и компонентного тестирования. 

Уважаемые читатели, добрый день!

Многие представляют АЭС и ТЭС как некие сложные установки и системы малопонятных процессов, но пользу от работы атомных и тепловых электростанций понимают практически все. Чтобы повышать безопасность и эффективность работы на станции, оперативный персонал должен постоянно совершенствовать свою профессиональную подготовку. И если реальная станция здесь не помощник, то полномасштабные и аналитические тренажеры – как раз то, что надо. Настолько то, что все приборы, ключи управления точно воспроизводят аппаратуру по составу, цвету, размерам, форме. Информацию, которая отображается на мониторах и индикаторах, не отличить по величине и внешнему виду от той, которая дается на энергоблоке. Ловкость рук, и никакого мошенничества!

Наша команда отвечает в Skyeng за личный кабинет и CJM пользователя до оплаты. Изначально проект был написан на Symfony 4.4 и представлял собой набор слабо связанных компонентов, которые были ответственны за правила работы для фронтенда.

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

У нас были лишь юнит-тесты: каждый покрывал логику одного класса. Все тесты вместе давали покрытие основной логики кода и гарантию, что все работает правильно. Но 100% покрытие кода тесты не обеспечивали. И сейчас не обеспечивают.

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

И мы обратились к функциональным.

Техника тест-дизайна «Таблица решений» - одна из самых сложных для применения, но одна из самых удобных для тестирования сложных бизнес-фич, когда есть более одного условия и одно/несколько действий системы как результат выполнения или не выполнения этих условий.

В этой статье речь пойдет о составлении таблицы решений для тестирования фильтрации с зависимыми фильтрами.

Изучая европейский рынок IT-вакансий, я заметила, что частым пунктом в списке пожеланий работодателей является наличие у кандидата сертификата ISTQB Tester Foundation Level. В некоторых крупных компаниях в области здравоохранения или финансов это было даже обязательным пунктом. Так что при всей моей нелюбви ко всякого рода экзаменам, я решила смахнуть пыль со своего старого намерения сертифицироваться и прикрепить заветную электронную бумажку к своему LinkedIn аккаунту. Действительно ли сертификат дает какое-то преимущество на рынке труда, это конечно отдельный вопрос, и его я затрагивать в этой статье не буду.

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

Итак, из каких этапов состояла моя подготовка и сколько занял каждый этап?

Всем привет! Команда тестирования производительности Тинькофф продолжает цикл статей о нагрузочном тестировании различных протоколов с помощью Gatling.

В прошлой статье мы показали, как протестировать JDBC-протокол с помощью Gatling. В этой — разберем протокол gRPC.