Программисты становятся более эффективными и довольными

Непрерывное тестирование (позволяет группам разработчиков программного обеспечения ежедневно выпускать обновления программного обеспечения. Никаких фальшивых разговоров о CI/CD. Ознакомьтесь с разделами Непрерывная интеграция в Facebook и AgileWay Continuous Testing Grading). процесс разработки программного обеспечения. Это приносит пользу всем заинтересованным сторонам программного проекта.

В любом случае разработчики тратят более 50% своего времени на ручное тестирование.

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

Если я скажу вам, что программисты, работающие в agile-команде, обычно тратят более 50% своего времени на функциональное тестирование приложений, вы, вероятно, удивитесь. На самом деле, как профессиональный программист с более чем 20-летним стажем, я бы сказал, что 50% — это консервативная цифра. Должен признаться, что понял это только после того, как освоил настоящую автоматизацию тестирования, которая помогла мне увидеть этот факт наглядно.

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

  1. Дизайн
  2. Написать/отладить код
  3. Модульное тестирование (только хорошие программисты могут сделать это хорошо)
  4. Развертывание на экземпляре локального сервера
  5. Проверьте функции: откройте браузер, войдите в систему, … и т. д.
  6. Если проблемы обнаружены, вернитесь к шагу 2.

Шаг 1 (дизайн) обычно довольно легкий в agile-командах. Среди четырех повторяющихся шагов (2–5): Шаг 3 и 5 и часть Шага 2 относятся к тестированию, а Шаг 4 (Развертывание на локальном сервере) должен быть молниеносным. Поэтому время, потраченное на это, ничтожно мало.

В контексте веб-приложений большая часть работы связана с настройкой CSS и JavaScript, что требует повторных проверок.

Теперь рассмотрим эти:

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

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

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

Некоторые программисты могут не согласиться: «Я не тестировщик, я НЕ работаю с записанными тест-кейсами, а только для проверки своей работы». Слышали ли вы о «исследовательском тестировании», которое противоположно « тестирование по сценарию? Тот факт, что вы переводите приложение в определенное состояние, выбираете учетные данные для входа, такие как «manager01», и выполняете некоторые проверки, означает, что вы выполняете функциональное тестирование (= этапы тестирования + данные тестирования + проверки). Уважаемые программисты, если вы не освоили автоматизацию тестирования (что бывает редко), вы каждый день делаете много ручных тестов.

Программисты, не расстраивайтесь. В некоторых ведущих ИТ-компаниях, таких как Google, программист с навыками тестирования пользуется большим уважением.

Теперь, надеюсь, вы поняли, что программисты действительно тратят много времени на ручное тестирование (кроме топовых, которые освоили автоматизацию тестирования). Если вы все еще сомневаетесь, вы можете прочитать книги, написанные такими легендами программного обеспечения, как Брайан Керниган, Кент Бек, Стив МакКоннелл, Дэйв Томас, Джеральд Вайнберг и Мартин Фаулер. Пока вы читаете, обратите особое внимание на тестовую часть. Там вы увидите ген тестирования. Тогда вам будет легче увидеть, какие преимущества непрерывное тестирование может дать программистам.

Преимущества автоматизации тестирования для разработчиков

1. Гораздо более быстрый цикл исправления ошибок

Многие программисты, как и я, не любили читать отчеты о дефектах в DFS (таких как Quality Center или Jira). Причина проста: описание, шаги и тестовые данные часто неверны.

Благодаря автоматическим ошибкам тестирования (особенно на сервере CT) разработчики могут быстро (за считанные секунды) просматривать шаги и снимки экрана ошибок. Программист может git pull выполнить тест и запустить его на своем локальном компьютере. Быстро и Объективно! Более того, после того, как программист внес исправление и повторно запустил тот же неудавшийся тест, чтобы убедиться, что он пройден, ощущение незаменимо!

2. Гордитесь своей работой

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

3. Предоставьте разработчикам различные точки зрения на разработку программного обеспечения

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

4. Намного продуктивнее

Как объяснялось ранее, разработчик тратит много времени на ручное тестирование приложения. Если возможно, выполнение автоматизированного теста будет намного быстрее, чтобы перевести приложение в нужное состояние. Например, чтобы работать с карточкой истории: «Менеджер может одобрить страховое возмещение», мне нужно сначала создать страховое возмещение.

5. Отважьтесь на рефакторинг и попробуйте новые технологии

Технический долг распространен в разработке программного обеспечения. Дело не в том, что разработчики не знают о них, им не хватает уверенности, чтобы улучшить/исправить проблемы. Естественно, программист подумал бы: «Если бы я коснулся, я мог бы ввести новые проблемы с регрессией. Лучше перестраховаться, в другой день еще один доллар».

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

Однажды я консультировал проект Ruby on Rails. Один класс контроллера имеет более 7000 строк. Этот класс является основной причиной того, что сервер работает очень медленно (хотя бизнес платил за дорогой план Linode: 960 долларов в месяц). Разработчики патчили класс, который приводил к монстру.

6. Создание тестовых данных

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

7. Автоматизация тестирования — гораздо более сложная и увлекательная задача!

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

  • Сбор пользовательских данных
  • Обработка пользовательского ввода
  • Запрос или обновление базы данных
  • Отображение ответа в пользовательском интерфейсе

Кроме того, фальшивые аджайл-тренеры будут беспокоить вас в основном бесполезными аджайл-церемониями (Кент Бек, отец аджайла, называет это «отходами»); и множество бессмысленных уведомлений об обновлениях бомбардируют вас в MS Teams/Confluence/Jira.

Я люблю программировать со старшей школы (выиграл приз на государственном соревновании по программированию). Мои первые 4 года работы в исследовательском центре были сложными и удовлетворительными (там у меня появилась хорошая привычка регулярно читать книги). Однако, когда я начал работать над EJB (в качестве подрядчика Java), это было очень скучно. Работа после этого была Microsoft BizTalk, что было еще хуже. В то время, на мой взгляд, разработкой программного обеспечения занимались безмозглые зомби. Честно говоря, мне было простительно сделать это «еще один день, еще один доллар», поскольку я был единственным кормильцем семьи.

К счастью, в 2005 году автоматизация тестирования (а позже и непрерывное тестирование) вдохнула новую жизнь в мою карьеру в сфере ИТ. С тех пор это было намного сложнее и веселее!

Тестировать сложнее, чем разрабатывать… если вы хотите получить хорошее тестирование, вам нужно отправить на тестирование своих лучших людей.
- Джерри Вайнберг

Обратите внимание, что всего через несколько месяцев активной практики автоматизации тестирования (на работе, по ночам и в выходные дни) моя эффективность программирования быстро возросла. Я написал больше пользовательских историй, чем все остальные программисты-подрядчики (~4) вместе взятые, причем с более высоким качеством. По просьбе команды я провел презентацию Agile/практики тестирования для разработчиков, которая была хорошо принята. Позже один программист присоединился к Microsoft и Google в США и поблагодарил меня за наставничество.

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

8. Освойте «Простой дизайн»

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

«Делай самое простое, что могло бы сработать»
— Кент Бек

В 2005 году мне посчастливилось попрактиковаться в парном программировании с программистом мирового класса в течение 6 недель. Я был поражен тем, как быстро и элегантно он смог придумать дизайн. Я спросил его: «Как ты это сделал? Как я могу научиться?»». Его ответ: «Дизайн прост. Мне даже тяжело. Чтобы освоить его, вам нужно провести двухлетнее автоматизированное тестирование». Я последовал его совету (после того, как стал свидетелем невероятного, трудно найти причину не делать этого). Следовательно, это основная причина, по которой с 2007 года я мог составить список своего собственного программного обеспечения, пользующегося большим спросом (см. Ниже) в свободное время.

Мой опыт

По сравнению со мной, с тех пор, как я начал практиковать автоматизацию тестирования и непрерывное тестирование в 2005 году, моя продуктивность (как программиста, создающего ПО) как минимум на порядок выше. До 2007 года я и представить себе не мог, что смогу разрабатывать собственное программное обеспечение. За последние 12 лет я создал

  • TestWise (IDE для функционального тестирования)
  • BuildWise (сервер непрерывного тестирования и агент)
  • ClinicWise (веб-система управления клиникой)
  • SiteWise (система управления контентом)
  • WhenWise (приложение для бронирования услуг/ресурсов)
  • SupportWise (наша внутренняя система поддержки)

Вся разработка и поддержка всего вышеперечисленного выполнялись в свободное время, пока я работал независимым консультантом по тестированию программного обеспечения и CI. Это программное обеспечение хорошо принято нашими клиентами. TestWise стал финалистом Международной премии Ruby в 2010 году, а BuildWise получил 2-ю премию Ruby Award в 2018 году.

Мой секрет успешной разработки программного обеспечения: автоматизация тестирования и непрерывное тестирование. Конечно, это еще не все. Но все они основаны на автоматизации тестирования.