Сегодня пришла мысль, что часто в тестировании приходится догонять разработку, то требования поменяются, а тебя в известность не поставят, то стабильный билд сломается.
Истина в том, что тестировщик должен не догонять изменения, а встречать их. Так жить легче, вспомните хотя бы игру в футбол. Мяч проще встретить чем догнать.
И если вы догоняете, то значит, что то пошло нет так и самое время улучшить процесс.
Поэтому нужно прикладывать усилия, чтобы быть впереди. (вспоминаются слова из Алиса в стране чудес). Конечно, это требует больше усилий, но оно того стоит.
Тестировщик обязан думать, что будет через 3-4 шага и пытаться оказаться там быстрее разработки. Например, заводя баг, задумайтесь, как вы будете его проверять, напишите автотесты, уточните требования.
Создавайте тесты перед новой функциональностью, а не после нее. Держите руку на пульсе проекта, что поменяется, когда и как.
Всегда имейте план Б.
Ну и боритесь с рутиной!
Истина в том, что тестировщик должен не догонять изменения, а встречать их. Так жить легче, вспомните хотя бы игру в футбол. Мяч проще встретить чем догнать.
И если вы догоняете, то значит, что то пошло нет так и самое время улучшить процесс.
Поэтому нужно прикладывать усилия, чтобы быть впереди. (вспоминаются слова из Алиса в стране чудес). Конечно, это требует больше усилий, но оно того стоит.
Тестировщик обязан думать, что будет через 3-4 шага и пытаться оказаться там быстрее разработки. Например, заводя баг, задумайтесь, как вы будете его проверять, напишите автотесты, уточните требования.
Создавайте тесты перед новой функциональностью, а не после нее. Держите руку на пульсе проекта, что поменяется, когда и как.
Всегда имейте план Б.
Ну и боритесь с рутиной!
Мысль про "до", а не "после" здравая. Но почему тестировщик должен "создавать тесты перед новой функциональностью" и думать как автоматизировать проверку бага. Почему не разработчики?
ОтветитьУдалитьболее того, я думаю надо еще и участвовать в принятии решения о том, как будет сделана та или иная фича. Это тоже относиться к самому раннему "до".
УдалитьМаксим, Добрый день.
УдалитьПотому что, сферический тестировщик с навыком автоматизации (программирования) напишет тесты лучше (считай полнее), чем сферический разработчик.
Хмм, направление мысли я понял :) С точки зрения тестов, они скорее всего будут лучше, а вот с точки зрения кода (= повторного использования, скорости работы, читаемости и прочих параметров), то тут скорее всего будут, эээ, проседания. Ну или автоматизатор должен быть реальным программером, с хорошими скилами. А это скорее редкость, чем правило. Но тут я отталкиваюсь от того инструмента (Fitnesse), который мы используем. Но, имхо, просто навыков, в любом случае будет мало.
УдалитьНу или автоматизатор должен быть реальным программером, с хорошими скилами
УдалитьЭто и имел ввиду. Но если уж тестер лезет в автоматизацию, то просто обязан стремиться иметь сильные навыки программирования.
А как же быть, когда в процессе реализации (и внедрения может быть) фичи требования 15 раз поменялись, а спецификация появилась уже по итогам 16й переписки? Переписывать автотесты все 15 раз? В такой ситуации писать после всяко дешевле выходит, имхо.
ОтветитьУдалитьА момент "после" в таком случае как определяется, если постоянно все меняется? ;) И зачем они "после" нужны?
Удалить"Ходить по воде и разрабатывать программы, следуя спецификации, очень просто… если они заморожены. " — Edward V Berard
Удалитьменяется код - меняется реализация тестов. меняются бизнес требования - меняются тесты.
Писать после дешевле и легче, только надо уже тестировать, а тестов у вас нет.