Когда разработчик начинает тестировать код, возникает логичный вопрос: а на что тогда тестировщики?

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

Среди братьев наших разработчиков бытуют некоторые стереотипы, связанные с тестированием собственного кода:

  1. «Тестировщики лучше справятся с этой задачей, они же профи»
    Да, это так :) Но ведь никто не требует от разработчика проводить полный цикл тестирования, достаточно лишь пары-тройки acceptance тестов для того, чтобы убедиться: твое «детище» работает.
  2. «У тестировщиков уже есть готовые тест-кейсы, а нам, разработчикам, нужно заново их «придумывать»
    Мы не жадные — можем поделиться :) Вероятно, разработчикам будет сложно и непривычно выполнять развернутые кейсы или проходить длинные чек-листы, но выполнить простое smoke-тестирование «своей» фичи вполне по силам каждому. Простейшее регрессионное тестирование при рефакторинге также не отнимет много сил и времени.
  3. «Время разработчика стоит дороже»
    Смоделируем ситуацию: разработчик написал фичу, потестил, нашел мелкий баг, пофиксил. Или: разработчик написал фичу, собрал новый билд, тестировщик установил билд, потестил, нашел баг, запустил багтрекер, описал баг, отправил его тимлиду, тимлид назначил его на разработчика, разработчик вспомнил, что он менял, поправил баг, закрыл его в трекере, баг ушел тестировщику, тестировщик провалидировал баг и закрыл его (в лучшем случае). В каком случае времени уйдет больше и стоить оно будет дороже?

А как еще разработчики могут тестировать?

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

  1. он делает свою работу быстро, чтобы поскорее отделаться от нее;
  2. делает ее качественно, чтобы не пришлось переделывать.

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

Какие трудности возникают?

Ошибочно полагать, что весь QA-штат можно заменить разработчиками, ведь и у программистов есть свои маленькие слабости:

  1. Родительская забота о коде
    Все мы знаем, что разработчики любят свой код родительской любовью. К сожалению, иногда это приводит к тому, что они фокусируются не на поиске проблемных мест, а на успешном выполнении тестовых сценариев.
  2. Взгляд изнутри
    Тестировщик оценивает продукт с точки зрения конечного пользователя, который не знает, как устроена программа. Разработчик досконально знает архитектуру кода, вследствие чего ему гораздо сложнее поставить себя на место пользователя.
  3. Раздробленность представления
    Как правило, разные разработчики пишут разные куски кода, из-за чего у каждого из них может отсутствовать ясное представление о работе системы в целом и о взаимосвязи компонентов.

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

Наталия Копычина

RSS