вторник, 26 ноября 2013 г.

Тестировщик догоняющий или встречающий

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

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

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

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

Тестировщик обязан думать, что будет через 3-4 шага и пытаться оказаться там быстрее разработки. Например, заводя баг, задумайтесь, как вы будете его проверять, напишите автотесты, уточните требования.

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

Всегда имейте план Б.

Ну и боритесь с рутиной!

8 комментариев:

  1. Мысль про "до", а не "после" здравая. Но почему тестировщик должен "создавать тесты перед новой функциональностью" и думать как автоматизировать проверку бага. Почему не разработчики?

    ОтветитьУдалить
    Ответы
    1. более того, я думаю надо еще и участвовать в принятии решения о том, как будет сделана та или иная фича. Это тоже относиться к самому раннему "до".

      Удалить
    2. Максим, Добрый день.

      Потому что, сферический тестировщик с навыком автоматизации (программирования) напишет тесты лучше (считай полнее), чем сферический разработчик.

      Удалить
    3. Хмм, направление мысли я понял :) С точки зрения тестов, они скорее всего будут лучше, а вот с точки зрения кода (= повторного использования, скорости работы, читаемости и прочих параметров), то тут скорее всего будут, эээ, проседания. Ну или автоматизатор должен быть реальным программером, с хорошими скилами. А это скорее редкость, чем правило. Но тут я отталкиваюсь от того инструмента (Fitnesse), который мы используем. Но, имхо, просто навыков, в любом случае будет мало.

      Удалить
    4. Ну или автоматизатор должен быть реальным программером, с хорошими скилами
      Это и имел ввиду. Но если уж тестер лезет в автоматизацию, то просто обязан стремиться иметь сильные навыки программирования.

      Удалить
  2. А как же быть, когда в процессе реализации (и внедрения может быть) фичи требования 15 раз поменялись, а спецификация появилась уже по итогам 16й переписки? Переписывать автотесты все 15 раз? В такой ситуации писать после всяко дешевле выходит, имхо.

    ОтветитьУдалить
    Ответы
    1. А момент "после" в таком случае как определяется, если постоянно все меняется? ;) И зачем они "после" нужны?

      Удалить
    2. "Ходить по воде и разрабатывать программы, следуя спецификации, очень просто… если они заморожены. " — Edward V Berard

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

      Удалить