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

Привет, дорогой читатель!

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

Для чего же нужен тест-дизайн? Тест-дизайн — это сердце тестирования. Он позволяет определить, что и как мы будем тестировать. А без хорошего тест-дизайна даже самый умный и опытный тестировщик будет биться головой о стену, пытаясь понять, почему его тесты не находят ошибок.

Начнем, наверное, с самой популярной техники тест-дизайна - Анализ граничных значений.

Привет! Меня зовут Арсений Кононов. На прошлой неделе мы зарелизили трёхмерные развязки и тоннели, которые можно увидеть в режиме навигатора. Я расскажу о простой и гибкой технике, реализованной в графической подсистеме нашего графического движка для отображения плоских объектов на произвольной трехмерной поверхности. Например, линии маршрута на поверхности развязки.

Надеюсь, пост будет полезен интересующимся компьютерной графикой на уровне, абстрагированном от конкретных графических API, но ниже, чем абстракции, предлагаемые большими игровыми движками, такими как Unity или Unreal Engine.

Вопрос ABI (Application Binary Interface), бинарной границы и бинарной совместимости в C++, раскрыт на просторах интернета не так хорошо как хотелось бы. Особенно сложно в его изучении приходится новичкам, потому что эта тема связана со множеством деталей нарочно скрытой от глаз программиста имплементации языка.

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

Подробнее о статье:

Мир С++ многое скрывает от глаз программиста. Это свойство языка — обоюдоострый меч, который с одной стороны позволяет уменьшить порог входа, но в то же время является препятствием при написании программ, уходящих дальше стандартного примера.

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

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

В рамках всей статьи будут рассмотрены темы: системный стек, системные регистры, динамическая память, детали механизма виртуальных функций, стандарт С++ и реальная имплементация, детали механизма исключений, copy elision при линковке библиотек, шаблоны, POD-типы и ODR violation.

Всем привет! Меня зовут Вадим Лунин. Я — QA Manager из Альфа Банка в Беларуси. Этой статьёй  хочу начать цикл статей по инструментам, которые мы используем для тестирования наших продуктов в Альфа Банке.

Всем привет, меня зовут Женя Колесников, я из команды Yandex Infrastructure. Сегодня я расскажу, как мы пришли к написанию документации в концепции Docs as Code, придумали для этого набор инструментов, назвали его красивым именем Diplodoc и выложили в опенсорс — теперь вы тоже можете им воспользоваться.

Если вкратце, Docs as Code — это подход к написанию технической документации, который рассматривает её не как набор текстов, а как код. Исходя из этой концепции, к документации могут применяться все те же принципы, инструменты и процессы, что и к самому коду. Расскажу, как это происходит на примере Diplodoc — и чем он может облегчить вам жизнь.

Всем привет! Меня зовут Даша и я системный аналитик компании SM Lab. Работаю в команде Brand Planning Tool. Наша команда BPT помогает брендам (таким как Fila, Demix, Northland) запускать новые коллекции.

В этом я году закончила бакалавриат и поступила в магистратуру по направлению «Системный анализ и управление». С третьего курса начала работать по специальности.

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

Под катом:

• Моя история
• Важные моменты при планировании
• Методики тайм‑менеджмента
• Выводы

Гуд ньюз эвриван! Спустя полтора года работы восьми айтишников с суммарным опытом в IT 130 лет достигнут результат в виде учебника по тестированию, которого еще никто и никогда не делал.

Знанием как искать информацию в интернете владеют многие люди. Но не все знают как делать это более эффективно. В этой статье я расскажу о том, как эффективнее работать в Google и DuckDuckGo.

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

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

Эту статью я хочу посвятить непростой работе QA-инженера, которую так легко обесценивает реклама курсов по «входу в IT». При этом все хотят работать только с профессионалами, но хорошего тестировщика днём с огнём не найдёшь. Потому что тестировщик — это командный игрок, который создаёт синергию для выпуска хорошего продукта. В слаженной команде QA-инженер становится T-shaped специалистом: умеет погружаться в код, может дать дизайнеру идеи  по UX и т. д. То есть социальные навыки у QA должны быть развиты не хуже технических. 

QA-инженер  — это не волк-одиночка, который только ищет баги. Задача тестирования — проверка работы продукта в соответствии с требованиями заказчика. Есть даже поговорка, что разработчики радуются, когда работает, а тестировщики радуются, когда не работает. Потому что тестировщики проверяют работу программы согласно требованиям к ПО и удостоверяются, что нет багов. Но поиск багов — не цель тестировщика, а следствие его кропотливой работы.

Привет всем.

В данной статье мы немного проанализируем код Windows XP, a также соберем калькулятор c использованием GCC x64 в среде Windows 10. Будут показаны ошибки, с которыми я столкнулся в процессе сборки и подробно расписаны способы их решения. В конце будет продемонстрирован рабочий билд приложения calc.exe.

Всем приятного прочтения!

Привет! Меня зовут Лёша и я тестирую веб в 2ГИС. Расскажу, зачем мы выделили багам бюджет и наделили их весом, и как мы придумали систему исправления ошибок, из-за которой больше не приходится спорить.

Привет! Сегодня наш разговор пойдет про сертификацию ФСТЭК и про тонкости этого процесса. Этот пост — не про теорию, а про практику, которая позволила нам получить одобрение ФСТЭК на версию 2.32 (на тот момент являлась новейшей - сейчас есть еще 2.33). Мы расскажем о том, что все это значит для пользователей нашей BI-платформы (из первых уст), а также почему мы уверены, что сертификация — это правильная практика не только “для бумажки”, но и для реальной пользы дела. Надеюсь, многое из этого текста окажется полезно как разработчикам российского ПО, так и его пользователям. Все подробности процесса нашей сертификации, в том числе мучительные — под катом!

Привет! Меня зовут Андрей, я бэкенд-тимлид в KTS. 

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

В статье расскажу про методику обучения проектированию в нашей компании.

Довелось мне обучать одного знакомого, желающего войти в ИТ (привет, Саша!). Человек он упорный, прошел разные курсы, стажировки, упорно продолжает идти вперед и уже вполне тянет на уровень джуна и решает прикладные задачи. Но иногда внезапно задает такие вопросы, из которых я понимаю, что у него огромные дыры в базовых знаниях и представлениях. На курсах этому, видимо, не учат.

Один из последних вопросов был про устройство сборки, непонимание того как исходный код собирается в исполняемый и запускается. Начинающим обычно говорят в духе «вот создаешь Gradle‑проект, в IDE жмешь кнопочку запуска и все работает». Но как только возникает необходимость что‑то в этом простом процессе усложнить, или понять — начинаются проблемы.

Gradle/Maven при этом представляются таким черным ящиком, в котором есть кнопка сборки и запуска, а внутри — магия, превращающая исходный код в запущенную программу.

В этой статье я пробегусь по основам того, как в Java работает компиляция, а также покажу, как по шагам прийти от компиляции отдельных файлов вручную к идее необходимости системы сборки, и как написать свою простенькую систему. Ведь лучший способ понять, как что‑то устроено внутри — сделать это самому.

Что вообще такое, эта матрица компетенций?

Как ее использовать QA менеджеру?

Как ее строить?

Зачем ее строить?

Причем тут грейды?

Все это мы узнаем в этой статье, без душных терминов (почти).

Добрый день меня зовут Александр и я токсичный душнила с двадцатилетним стажем в айти, готовый откусить вам кадык, как только вы расслабьтесь. Мои характеристики делают меня хорошим техническим собеседующим, поэтому добро пожаловать на моё провальное собеседование. Запомните, вы его никогда не пройдете. А знаете почему?