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

Если вы тестировщик, начинающий свой путь в мире QA или опытный профессионал, стремящийся к постоянному совершенствованию, то в этой статье вы найдете золотую подборку из 14 книг, которые помогут вам расширить знания, улучшить навыки и поднять свой профессиональный уровень.

Привет, Хабр! У многих IT-специалистов есть свой список настольных пособий, которыми они пользуются или изучают. Сегодня поговорим о тестировании. Мы со своей стороны можем порекомендовать книги, так как они помогают не только изучить базовые положения работы тестировщика, но и открывают другие нюансы профессии, например корпоративные или психологические. Подробности — под катом.

Лонгрид посвящается любителям CLI в знак солидарности лучшего эмулятора терминала на OS Android, который испытывает «кошмарную» монополию Google.

В данной работе вербализация пойдет о нижеизложенном со всеми остановками:

[+] глубоко настраивать средý (флэшка, виджет, стиль, зеркала и конфиги);
[+] управлять серверами через ssh;
[+] скачивать ролики/отрывки с YouTube;
[+] нарезать видео, создавать gif;
[+] воспроизводить текст/музыку/радио прямо в CLI;
[+] нарезать mp3-бигфайлы (аналогов приложений на Android попросту нет), и склеивать аудиофайлы;
[+] редактировать документы;
[+] проверять орфографию: как текстовых файлов, так и различных статей по url, например, проверка орфографии статей на Habr-e;
[+] генерировать словари различной сложности со скоростью Си;
[+] создавать блок-схемы; графики; облако слов и даже 3D-визуализацию;
[+] заниматься Data Science на Android-мощностях;
[+] тестировать интернет соединение/интерфейс (требуется частично Root);
[+] сниффить/сканировать сети (требуется частично Root);
[+] запускать и управлять TOR-сетью (deleted);
[+] управлять приложениями и процессами в ОС Android (требуется Root);
[+] анализировать память;
[+] защищать любые данные от случайного редактирования/уничтожения (требуется Root);
[+] автоматически шифровать и бэкапить по ночам любые данные в своё облако;
[+] чекать username(s) и e-mail(s);
[+] проводить аудит безопасности (об опасности сердить скрипт-кидди с их любимыми: «сниффить, парсить, брутить, дампить, сканить, фишить»);
[+] работать с электропочтой;
[+] изучать UNIX/shell;
[+] программировать на Android (на выбор пользователя. В Termux портированы несколько интерпретируемых и компилируемых языков программирования);
[+] запускать python/php/npm скрипты в т.ч. в одно касание с рабочего стола;
[+] работать с криптографией, стеганографией и цифровыми подписями;
[+] парсить данные;
[*] и даже запускать GNU-GUI-софт из CLI.

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

Недавно мне потребовалось собрать и развернуть документацию для одного из своих небольших проектов на Python. Написал документацию, собрал Sphinx'ом, дальше собрался заливать на readthedocs.org и обнаружил что без VPN сайт не алё. Более того, почему то и с VPN нормально не получалось импортировать свой проект с GitHub.

Не долго думая, решил изучить ситуацию на "рынке" и нашел неплохую альтернативу - GitHub Pages. Эта статья о том, как я деплоил мультиверсионную документацию на GitHub Pages c помощью GitHub Actions и своими собственными "костылями".

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

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

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

Добрый день! Меня зовут Александр, я старший специалист по тестированию в ГК Юзтех. В этой статье я постараюсь кратко рассказать историю создания новых исследовательских сценариев и поделиться с вами опытом их применения.

Перед началом прочтения сразу обозначу две концепции, которые лежат в основе статьи:

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

Рассуждения о сути анонимности.

Вы когда-нибудь задумывались о том, чтобы перенести крупномасштабное программное решение с Oracle на PostgreSQL, а затем развернуть его в общедоступном облаке? Если Вы планируете реализовать подобное, возможно, Вам поможет наш опыт. Данная статья подробно рассказывает о нашем опыте настройки облачного хранилища, используемого PostgreSQL и оптимизации его производительности.

Законы, теории, принципы и закономерности, полезные для разработчиков

Введение

Законы

Закон Амдала

“Разработка API сложна, Postman делает её лёгкой” © Postdot Technologies, Inc

Когда видишь описание инструментов Postman — захватывает дух, просыпается чувство всевластия над своим будущим детищем. Кажется, что и взрощенные в прошлом "монстры" наконец-то падут перед тобой!

В этой статье мы расскажем о Postman и попробуем написать свой первый скрипт.

С каждым годом рекламы в интернете становится все больше, а подают ее с каждым разом все навязчивее. Дошло уже до почты: реклама в интерфейсе почтового ящика выглядит как первое непрочитанное письмо, которое машинально хочется открыть. Я не против рекламы, особенно когда она в тему и не сбивает с толку. Но маскировать её под непрочитанное письмо ‒ это перебор. Чувствуется, что следующим шагом рекламу начнут вставлять прямо в тело письма.

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

Что самое первое, что мы изучаем в тестировании? - Правильно, тест-идеи, которые являются базой для всего тестирования в дальнейшем! Возможно, кому-то покажется, что это очень простая тема - берем требования, пишем на основе требований тесты и тестируем. НО мой практически опыт (15 лет) показывает, что все не так просто, и тесты на основе требований — это в лучшем случае одна треть из того, что можно и нужно протестировать. А две третьих - то, что не отражено в требованиях, что необходимо собирать по крупицам во всем что окружает проект: окружение, код, домен и т.д. На сколько успешным будет подобный сбор чаще всего зависти от опыта тестировщика, кто этим занимается. Но даже опыт тестировщика не может быть гарантией того, что все возможные области будут покрыты. А если в проекте нет опытных тестировщиков, что же делать? Выпускать проект недотестированным?

Так какими же всё таки должны быть идеальные шахматы?

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

Чтобы понять какими могут быть идеальные шахматы, нужно сначала понять что не так с шахматами нынешними (классическими). Давайте попробуем сформулировать недостатки не только геймплея как такового, но и недостатки связанные с психологическим восприятием того, что происходит во время игры.

Финансовые компании находятся в поисках лучших решений, которые оптимизируют внутренние процессы разработки, разовьют IT-инфраструктуру в соответствии с требованиями бизнеса и позволят им выводить на рынок лучшие конкурентные продукты. Так, два года назад мы ступили на путь перевода разработки ЦФТ-банк на платформу CFT Platform IDE. Среди коллег по цеху ходят слухи, что это процесс невероятной сложности, ввиду чего не решаются приступить к делу. На своем примере мы докажем, что это вполне подъемный процесс и для вашей команды.