Home

Автор: Майкл Болтон (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 и заканчивая самописным ПО, созданным для конкретных задач. В процессе работы мы ловим самые разные баги. Некоторые из них удостоились упоминания в этом материале.

Автор: Наталья Ханчич (Nataliya Hanchych)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

На картинке этой статьи вы видите прекрасный фронтэнд. Возможно, это не тот "фронтэнд", которого вы ожидали. Это фронтэнд Фольксваген Карманн Гиа 1974 года выпуска. Карманн Гиа славился, как "Порше для бедняков". Это очень необычная машина. По сути это совместный проект Вильгельма Карманна, немецкого производителя автомобилей, и Каррозцерии Гиа, итальянского автодизайнера. Гиа разработал произведение искусства – корпус, а Карманн поставил его на испытанную надежную платформу классического "Фольксваген Жук". Когда машину увидели директора Фольксваген, они не могли не разрешить массовое производство.

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

Хорошее качество, дизайн и опыт – неотъемлемые аспекты фронтэнда, неважно, для классических автомобилей или для Web. В этой статье я поделюсь семью основными тенденциями, которые я наблюдаю в тестировании фронтэнда. В этом мире происходит масса клевых вещей, но держите в уме основной момент: инструменты и технологии могут меняться, но базовые принципы тестирования остаются теми же. Тестирование – это взаимодействие плюс верификация. Тесты вскрывают истину о нашем коде и наших фичах. Мы тестируем в ходе разработки, чтобы получить быструю обратную связь для исправлений и улучшений. Все тренды, о которых я буду говорить, базируются на этих принципах. При хорошем тестировании вы убедитесь, что ваши приложения визуально идеальны, прямо как… сами знаете, что.