Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

«Языковые модели» («Language models») обычно интерпретируются как сложное существительное – нечто, что моделирует язык. Что, если определять models как глагол? Тогда это простое изъявительное предложение с предполагаемым объектом: язык моделирует наше мышление, или же язык моделирует мир.

Как и с любой моделью, замена или изменение одного из ее элементов может натолкнуть нас на что-то интересное, что поможет усовершенствовать ответы на два главных вопроса, которые мы задаем, тестируя. Первый – это вопрос, который мы постоянно, экспансивно и неявно задаем сами себе как тестировщикам: «Есть ли тут проблема?» Второй мы задаем клиентам – время от времени, конкретно и явно, и он касается проблем и продукта: «Вам как, нормально?»

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

Оригинальная публикация

Всем привет! Меня зовут Фефилов Александр, я работаю в QA с 2017 года. По большей части это были компании, которые занимались аутсорсингом, но затем я присоединился к SM Lab.

Как вы уже поняли из названия поста, я расскажу о том, как взаимодействовать с заказчиком (а иногда и с заказчиками) с позиции QA-эксперта.

Под катом личный опыт работы в разных крупных компаниях и ответы на вопросы:

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

• что делать, если ваш заказчик живёт в парадигме «Я плачу деньги, а ты просто делаешь всё, что я говорю»

• как решать процессные задачи

• как находить продуктовые проблемы

• кто такой QA-эксперт и как им стать

• полезная методика, которая может пригодиться вам в работе.

Итак, начнём по порядку.

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

Как вы, вероятно, догадываетесь, мне приходит много писем об инструментах тест-автоматизации. КУЧА. Я открываю почти все и бегло их просматриваю. Если что-то цепляет мой взгляд, неважно, хорошее или плохое, я тщательно читаю письмо. Думаю, многие из нас делают так же.

«Плохие» сообщения – это не что-то, полное ненависти или совершенно неуместное (с таким я управляюсь иным образом) – зачастую они относятся к активному продвижению идей автоматизации вне всякого контекста, для чего эти идеи подходят, и что нужно, чтобы их внедрить. Как правило, я просто удаляю это и еду дальше. Иногда мне хочется – конечно, вежливо, - ответить отправителю, что его компания тем или иным образом отклоняется от цели. Иногда я использую их в качестве идей для статьи; это как раз такой случай.

Автор:  Женя Шаповалов, Senior Android/Flutter Developer в компании Innowise (и хэд mobile department там же). В мобильной разработке я с 2015 года, начинал с Android, а за Flutter мы принялись вместе с коллегами в Innowise - да так мощно, что в итоге в компании появилось отдельное направление разработки.

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

Оригинальная публикация

«Дедушка российского тестирования», тестировщик с 50-летним стажем Александр Александров объясняет, почему классическая научная литература по тестированию по-прежнему актуальна и с каких основополагающих текстов стоит начинать свой путь в этой профессии.

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

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

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

Пост написан Стефаном Шмидтом. Он говорит, что у него за плечами более сорока лет разработки. У меня их столько же (1 января 2024 стукнул 41 год, годовщина моего первого рабочего дня в Dale Disharoon, Inc. Моим первым проектом было создание игры Hey Diddle Diddle для Apple II и С64). Возможно, разница между нами в том, что я всю свою карьеру занимался именно тестированием, а он говорит, что «пишет тесты» в ходе разработки. Между написанием тестов, предполагаю, он пишет код продукта, а это не тестирование. То есть он в лучшем случае поверхностно знаком с нашей отраслью.

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

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

Собеседник: «Я хочу научиться делать это хорошо!» (это здорово!)

Я: «Что вы делали ранее, что работало, что нет?»

Собеседник: «Мы пробовали внедрять это раньше, но получилась ерунда», или «Мы наняли экспертов, чтобы они это сделали, но получилась ерунда» (бывает довольно часто).

Я: «Как я могу помочь вам стать лучше?»

Собеседник: «Нам нужно изучить лучшие практики в области …»

Я (в реальности): «Я могу вас научить/рассказать вам о распространенных практиках, но…»

Я (про себя): «Пожалуйста, нет, только не это!»

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

Знаменитая фраза Аристотеля звучит, как «Чем больше вы знаете, тем больше понимаете, что ничего не знаете». Я давно знаю, что так оно и есть, но не применял это знание на практике.

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

Оригинал опубликован в блоге на Хабре РСХБ-Интех сотрудником Ахметовым Андреем

Меня зовут Андрей Ахметов, я ведущий инженер и тестировщик системы ЕСПП в ООО «РСХБ-Интех», технологической дочке Россельхозбанка. Сегодня расскажу вам шесть небольших историй о том, какие экзотические баги бывают и как их устранять.

ЕСПП (единая система приема платежей) — мидл‑решение, расположенное в центре хитросплетений систем РСХБ. Подробнее о том, что это за система и с какими сервисами она взаимодействует можно почитать в отдельном материале на Хабре. Добавлю лишь, что за последние годы она нам стала практически родной.

Для тестирования ЕСПП мы используем широкий набор инструментов, начиная с привычного всем Postman и заканчивая самописным ПО, созданным для конкретных задач. В процессе работы мы ловим самые разные баги. Некоторые из них удостоились упоминания в этом материале.