За пять лет работы в «Аркадии» — компании-разработчике программного обеспечения на заказ, где я работаю тестировщиком, — мне довелось поучаствовать в самых разных проектах. Большая часть из них была связана с веб-разработкой, меньшая — с мобильной. Некоторые проекты длились более года, другие были краткосрочными (полгода или даже пару месяцев). Менялся и размер команд: от трёх до трёх десятков человек.  

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

В этой статье мы рассмотрим описание процесса тестирования программного обеспечения сквозь призму работы с API. Я попытался собрать полезные факты из книги “Hands on restful API design and the best practices” авторов Harihara Subramanian и Pethuru Raj. В книге подробно описываются этапы проектирования API и есть отдельная глава по тестированию RESTful сервисов в связке с API.

Можно читать в связке с моим предыдущим переводом “Стратегия тестирования REST API: что именно вам нужно тестировать?”. По ходу перевода я привожу примеры из личной практики (выделены курсивом), чтобы наглядно проиллюстрировать каждый этап из книги.

Всем привет, меня зовут Рома Неволин и я много занимаюсь докладами. Готовлю доклады, выступаю с докладами, делаю доклады, ищу докладчиков, ищу темы для докладов, а еще постоянно отвечаю на вопросы про доклады. А их всегда много.

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

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

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

Привет!

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

Но нашу команду поджидали две серьезные проблемы.

Девушка: Нарисуй дерево.
Программист: (рисует бинарное дерево)
Девушка: Нет, другое.
Программист: Я и красно-черное дерево могу нарисовать.

• [ +114 ] Самые полезные приёмы работы в командной строке Linux
  
• [ +70 ] 10 приёмов работы в терминале Linux, о которых мало кто знает
  
• [+65 ] Удивительно полезный инструмент: lsof
  
• [ +32 ] Linux: перенаправление
  
• [ +29 ] PDF-версия статей про Bash-скрипты
  

Понятие IoT (Internet of Things) давно вошло в лексикон IT-шников. Хотя я и не нашел такого хаба, но надеюсь это скоро будет исправлено :)

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

Несмотря на то, что технологии модульного тестирования существуют уже 30 лет (в 1989 году Кент Бек написал статью “Simple Smalltalk Testing: With Patterns”), тем не менее не все программисты владеют этой технологией и не все компании сделали автоматическое тестирование частью своей корпоративной культуры. Даже несмотря на очевидные преимущества автоматического тестирования, все равно поведенческое сопротивление достаточно сильное. Кто пробовал внедрять автоматические тесты, тот знает, что всегда найдется какая-то причина, почему это не удалось сделать.

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

Все возражения я сгруппировал в пирамиду надежного программирования, которая включает четыре уровня: