Сразу оговорюсь - я пишу о своей ситуации, когда тестовый фреймворк (API-тестов) уже готов. Задача тестировщика сводится к его небольшому расширению на свой модуль. Потому что про то, как написать первый автотест на каком-нибудь Selenium для GUI тестов, я пока даже заикаться не хочу, это еще дольше!
Только, пожалуйста, без холиваров. Конечно, через Record And Play можно тест сваять за минуту, но мы все-таки стараемся писать такие тесты, которые потом будет удобно поддерживать. А это уже сложнее.
Итак, когда перед нами стоит задача - создать новую сущность, мы сразу прикидываем, сколько времени нам понадобится. Допустим, заложили 1-2 дня на все-провсе, проверить вручную, написать автотесты итд.
При этом тесты тривиальные, фреймворк есть, а значит, написать тест (2 эксель таблички с состоянием БД) занимает ну минут 5-10 с отладкой. В идеале, ага.
А теперь посмотрим, как это происходит в реальной жизни. Конечно же, на конкретном примере.
Вначале, наверное, пару слов о нашем процессе разработки. Тестировщик может выступать как в роли разработчика (если поправить код довольно легко), так и в роли тестировщика. Если тестировщик сам правит код, то другой тестировщик все равно обязательно проверяет изменения.
Если тестировщик именно тестирует, то он проверяет вручную и пишет автотесты на уровне API. Для киллер-фич или просто сложных задач автотесты пишутся по принципе TDD, то есть до разработки. Но, конечно, всякое в жизни бывает...
Итак, разработчик добавил новую сущность. Я за задачу взялась еще вчера. Попробовала сразу создать эту сущность вручную - интересно же посмотреть сначала с высоты птичьего полета, в целом, а потом нырять в подробности и расписывать автотесты на всяко-разные ситуации.
Дернула SOAP-запрос и сразу получила отлуп с сообщением об ошибке. А все почему? Потому, что надо работать по TDD, блин! Тогда разработчик сам первым делом прогонит тесты и увидит, что что-то разломано. К сожалению, идеальная картина мира не всегда возможна. Так что и проблема всплыла поздновато.
Хорошо, у нас интегрированы два продукта - А и Б. Проблема нашлась в продукте Б, который для данной задачи в целом второстепенный. Ага, думаю, ну тогда, раз ошибка нашлась, напишу тесты в Б, а потом займусь тестами для А. Напомню, фреймворк в продукте А на уровне API, то есть на тесты ошибка в другом продукте никак не повлияет. Только на интеграционные, но их мы отложим на потом.
Итак! Тесты для Б. Тоже нетривиально все, наверное, многие сталкивались с такой ситуацией, когда первый автотест написать довольно сложно (развернуть окружение, написать заглушку, отладить сам тест), а остальные уже идут намного быстрее, так как основа заложена. Так что весь вечер заняли автотесты на продукт Б.
Ну и ладно! У меня же еще сегодня весь день, думала я. Сейчас мы быстренько там тестов напишем. сям, да еще другие задачи сделать успеем!
Как вы думаете, во сколько времени я отладила тот самый "первый автотест", от которого можно было построить остальную цепочку? Правильно, в 15:30!
Но со стороны посмотреть, ну казалось бы, куда, вот куда время ушло? 10 минут писать тест, ну ладно, полчаса, ну ладно, час! Так нет, почти весь день... Давайте посмотрим детальнее, что отнимает наше время?
1. Неточности в документации.
Вообще-то перед согласованием документации с Заказчиком я ее уже читала на предмет корректности, однозначности и далее по списку. Не знаю, чем я тогда думала, может, очень уставшая была? Это вообще тема для отдельной статьи, как тестировать документацию, а не просто читать.
Сегодня я читала ее под лупой тестирования, "ага, требование 1. Значит, надо написать тест такой, такой и сякой. Хм, стоп, а в этом случае как система должна себя повести? Ну-ка ну-ка... Ой ей, в документации этого нет".
Раз пробел (пропущенное место в документации), два пробел, три... Прям реально стыдно стало, как я могла этого не заметить раньше? Даже вот только что, пока писала эти строки, пошла и поставила в календаре на завтра "Киселева с 11", а то никуда не годится такая "проверка" усталым, замыленным взглядом.
Ладно, пока прикинула в голове, какие тесты нужны, нашли проблемы в документации. пара некритичных (уже все реализовано и даже тестировать не надо, просто в данном разделе не указана возможность) и одно пропущенное требование по настройке правил. Должно же с новой сущностью что-то происходить? Вот этих то правил и не было. Ладно, добавили, проблем особых нет, они же стандартные.
А пока мы все это обсуждали и добавляли, я как раз накидала тот самый автотестик. Который первый, от которого потом будут умно копипаститься остальные. Даже прогнала его, упал более менее корректно.
2. Неточности в реализации.
А тут мы сталкиваемся с еще одной замечательной особенностью неполной документации. Разработчик, когда реализовывает, может задать уточняющие вопросы. А может и не задать. Сделать так, как "правильно", с его точки зрения.
Итак, мы пополнили документацию и я сразу полезла в код, посмотреть, а какие тогда правила там настроены сейчас? Ну... Слегка не те... А если точнее, то там просто не все необходимые поля новой сущности были. Ну ладно, ладно, Петя (назовем так разработчика) занят, он находится вообще в другой ветке проекта, зачем его просить добавить пару строчек кода, когда я могу это сделать сама?
Добавила поля в правила и радостно пересобрала проект. Вот нет бы сначала автотест поотлаживать...
3. Баги в коде!
А теперь мы переходим к самой очевидной проблеме с задержками по времени. Любое изменение кода может что-то сломать. И мое изменение, увы, исключением не стало.
Казалось бы, 5 минут работы - добавила поля в xml-файлик.
Но - перезапустила я свой автотест, который теперь должен был пройти (для него правки тоже были внесены), а он перестал даже собираться!
То есть если раньше он падал на Assert-e, то есть полностью выполнялся и падал на сравнении ожидаемого результата с реальным, то теперь перестал даже запускаться. Ок, в чем проблема?
Ага, новые поля я в правила добавила, а для этого их еще в Java-классе надо подкорректировать. Надо сказать, что на это выяснение тоже ушло немного времени.
Ла-а-а-адно, пошли в Java-класс. Сделала все, что надо, просмотрела его глазками и тут...
4. "В первый раз в первый класс". Незнание проекта / его части.
Новые сущности я раньше сама не добавляла, а вот поля в них... Было дело! Мы даже документацию на это все написали красивую. А потом она внезапно пригодилась и выяснилось, что некоторые места не совсем очевидны. Так документация стала еще подробнее и понятнее.
А так как эти "не совсем очевидно" огребала я, то и проблему заметила сразу же. И тут уже не важно, кто занимается модулем в первый раз, разработчик или тестировщик. Это незнание все равно сказывается на результате, его надо учитывать во время планирования и помнить о таких рисках.
Показала разработчику документацию и стала вносить правки сама. Опять же, так быстрее для проекта в целом. И опять же, почему возникла такая ситуация? Правильно, потому что надо работать по TDD!!! Были бы тесты заранее, это все чинил бы разработчик.
Но в данном случае починить быстрее было мне, поэтому Пете я просто показала а) ссылку на документацию и б) места, которые намерена исправить. Чтобы в будущем знал и помнил.
А пока я вносила правки, я заметила, что документация для полей то хороша, а вот для сущности в целом как-то не очень. Отсюда и проблемы! Ну ладно, заодно и документацию пополнила. Пишите, ребята, пишите технические документации! Они вам еще ой как пригодятся в дальнейшем и сильно упростят жизнь, когда придется повторить то действие, которое "ну, это единоразово!". Да-да, знаем, слыхали.
Итого - все сделала, все поправила. Конечно же, не без помощи коллег-разработчиков, у которых я консультировалась для пополнения документации, для выяснения подробностей итд. Но время 15:30, а написан только первый тест...
И ведь знаете, что самое удивительное? То, что все это - НОРМАЛЬНО!
Для себя я вынесла из этой ситуации только "помедитировать над тем, почему сразу проколы в документации не нашла". А все остальное - это стандартный рабочий процесс.
Когда разработчик планирует свое время, он закладывает риск-буфер на возможный рефакторинг кода. Потому что иногда да, рефакторить слишком долго и лучше поставить отдельную задачу в backlog.
Но это плохая практика так делать, если ты можешь все зарефакторить здесь и сейчас. Не сделаешь сейчас -задача будет пинаться на следующую итерацию, потом снова на следующую итд. А в итоге их накопится очень много и код будет не код, а сборище костылей. Так что, видишь, где можно улучшить - улучшай.
То же самое касается и тестировщиков, у которых есть доступ к коду. Если вы сталкивались с похожими задачками часто, вполне возможно, что вы сами сможете подсказать разработчику, что и как тут сделать. Если вы видите ошибку, иногда бывает проще поправить ее самому, чем ждать, когда у разработчика найдется на это время.
Поэтому не стоит думать, что написать 10 автотестов - невелика задача. Всегда стоить помнить о том, что самый первый автотест отлаживать можно долго. Даже не писать, нет, написать можно и правда быстро. А вот чтобы его отладить, иногда приходится и документацию пользователя поправить, и свою, техническую, тоже, и в коде полазить, что-то поправить, где-то отрефакторить, там подкрутить, тут поднастроить... Главное, не забывать, что если ты что-то правишь, кто-то должен это проверить.
И вот тогда-а-а-а, тогда уже вы увидите заветное "BUILD SUCCESS" и можно будет снова возвращаться к исходной роли тестировщика и продолжать писать автотесты
Только, пожалуйста, без холиваров. Конечно, через Record And Play можно тест сваять за минуту, но мы все-таки стараемся писать такие тесты, которые потом будет удобно поддерживать. А это уже сложнее.
Итак, когда перед нами стоит задача - создать новую сущность, мы сразу прикидываем, сколько времени нам понадобится. Допустим, заложили 1-2 дня на все-провсе, проверить вручную, написать автотесты итд.
При этом тесты тривиальные, фреймворк есть, а значит, написать тест (2 эксель таблички с состоянием БД) занимает ну минут 5-10 с отладкой. В идеале, ага.
А теперь посмотрим, как это происходит в реальной жизни. Конечно же, на конкретном примере.
Вначале, наверное, пару слов о нашем процессе разработки. Тестировщик может выступать как в роли разработчика (если поправить код довольно легко), так и в роли тестировщика. Если тестировщик сам правит код, то другой тестировщик все равно обязательно проверяет изменения.
Если тестировщик именно тестирует, то он проверяет вручную и пишет автотесты на уровне API. Для киллер-фич или просто сложных задач автотесты пишутся по принципе TDD, то есть до разработки. Но, конечно, всякое в жизни бывает...
Итак, разработчик добавил новую сущность. Я за задачу взялась еще вчера. Попробовала сразу создать эту сущность вручную - интересно же посмотреть сначала с высоты птичьего полета, в целом, а потом нырять в подробности и расписывать автотесты на всяко-разные ситуации.
Дернула SOAP-запрос и сразу получила отлуп с сообщением об ошибке. А все почему? Потому, что надо работать по TDD, блин! Тогда разработчик сам первым делом прогонит тесты и увидит, что что-то разломано. К сожалению, идеальная картина мира не всегда возможна. Так что и проблема всплыла поздновато.
Хорошо, у нас интегрированы два продукта - А и Б. Проблема нашлась в продукте Б, который для данной задачи в целом второстепенный. Ага, думаю, ну тогда, раз ошибка нашлась, напишу тесты в Б, а потом займусь тестами для А. Напомню, фреймворк в продукте А на уровне API, то есть на тесты ошибка в другом продукте никак не повлияет. Только на интеграционные, но их мы отложим на потом.
Итак! Тесты для Б. Тоже нетривиально все, наверное, многие сталкивались с такой ситуацией, когда первый автотест написать довольно сложно (развернуть окружение, написать заглушку, отладить сам тест), а остальные уже идут намного быстрее, так как основа заложена. Так что весь вечер заняли автотесты на продукт Б.
Ну и ладно! У меня же еще сегодня весь день, думала я. Сейчас мы быстренько там тестов напишем. сям, да еще другие задачи сделать успеем!
Как вы думаете, во сколько времени я отладила тот самый "первый автотест", от которого можно было построить остальную цепочку? Правильно, в 15:30!
Но со стороны посмотреть, ну казалось бы, куда, вот куда время ушло? 10 минут писать тест, ну ладно, полчаса, ну ладно, час! Так нет, почти весь день... Давайте посмотрим детальнее, что отнимает наше время?
1. Неточности в документации.
Вообще-то перед согласованием документации с Заказчиком я ее уже читала на предмет корректности, однозначности и далее по списку. Не знаю, чем я тогда думала, может, очень уставшая была? Это вообще тема для отдельной статьи, как тестировать документацию, а не просто читать.
Сегодня я читала ее под лупой тестирования, "ага, требование 1. Значит, надо написать тест такой, такой и сякой. Хм, стоп, а в этом случае как система должна себя повести? Ну-ка ну-ка... Ой ей, в документации этого нет".
Раз пробел (пропущенное место в документации), два пробел, три... Прям реально стыдно стало, как я могла этого не заметить раньше? Даже вот только что, пока писала эти строки, пошла и поставила в календаре на завтра "Киселева с 11", а то никуда не годится такая "проверка" усталым, замыленным взглядом.
Ладно, пока прикинула в голове, какие тесты нужны, нашли проблемы в документации. пара некритичных (уже все реализовано и даже тестировать не надо, просто в данном разделе не указана возможность) и одно пропущенное требование по настройке правил. Должно же с новой сущностью что-то происходить? Вот этих то правил и не было. Ладно, добавили, проблем особых нет, они же стандартные.
А пока мы все это обсуждали и добавляли, я как раз накидала тот самый автотестик. Который первый, от которого потом будут умно копипаститься остальные. Даже прогнала его, упал более менее корректно.
2. Неточности в реализации.
А тут мы сталкиваемся с еще одной замечательной особенностью неполной документации. Разработчик, когда реализовывает, может задать уточняющие вопросы. А может и не задать. Сделать так, как "правильно", с его точки зрения.
Итак, мы пополнили документацию и я сразу полезла в код, посмотреть, а какие тогда правила там настроены сейчас? Ну... Слегка не те... А если точнее, то там просто не все необходимые поля новой сущности были. Ну ладно, ладно, Петя (назовем так разработчика) занят, он находится вообще в другой ветке проекта, зачем его просить добавить пару строчек кода, когда я могу это сделать сама?
Добавила поля в правила и радостно пересобрала проект. Вот нет бы сначала автотест поотлаживать...
3. Баги в коде!
А теперь мы переходим к самой очевидной проблеме с задержками по времени. Любое изменение кода может что-то сломать. И мое изменение, увы, исключением не стало.
Казалось бы, 5 минут работы - добавила поля в xml-файлик.
Но - перезапустила я свой автотест, который теперь должен был пройти (для него правки тоже были внесены), а он перестал даже собираться!
То есть если раньше он падал на Assert-e, то есть полностью выполнялся и падал на сравнении ожидаемого результата с реальным, то теперь перестал даже запускаться. Ок, в чем проблема?
Ага, новые поля я в правила добавила, а для этого их еще в Java-классе надо подкорректировать. Надо сказать, что на это выяснение тоже ушло немного времени.
Ла-а-а-адно, пошли в Java-класс. Сделала все, что надо, просмотрела его глазками и тут...
4. "В первый раз в первый класс". Незнание проекта / его части.
Новые сущности я раньше сама не добавляла, а вот поля в них... Было дело! Мы даже документацию на это все написали красивую. А потом она внезапно пригодилась и выяснилось, что некоторые места не совсем очевидны. Так документация стала еще подробнее и понятнее.
А так как эти "не совсем очевидно" огребала я, то и проблему заметила сразу же. И тут уже не важно, кто занимается модулем в первый раз, разработчик или тестировщик. Это незнание все равно сказывается на результате, его надо учитывать во время планирования и помнить о таких рисках.
Показала разработчику документацию и стала вносить правки сама. Опять же, так быстрее для проекта в целом. И опять же, почему возникла такая ситуация? Правильно, потому что надо работать по TDD!!! Были бы тесты заранее, это все чинил бы разработчик.
Но в данном случае починить быстрее было мне, поэтому Пете я просто показала а) ссылку на документацию и б) места, которые намерена исправить. Чтобы в будущем знал и помнил.
А пока я вносила правки, я заметила, что документация для полей то хороша, а вот для сущности в целом как-то не очень. Отсюда и проблемы! Ну ладно, заодно и документацию пополнила. Пишите, ребята, пишите технические документации! Они вам еще ой как пригодятся в дальнейшем и сильно упростят жизнь, когда придется повторить то действие, которое "ну, это единоразово!". Да-да, знаем, слыхали.
Итого - все сделала, все поправила. Конечно же, не без помощи коллег-разработчиков, у которых я консультировалась для пополнения документации, для выяснения подробностей итд. Но время 15:30, а написан только первый тест...
И ведь знаете, что самое удивительное? То, что все это - НОРМАЛЬНО!
Для себя я вынесла из этой ситуации только "помедитировать над тем, почему сразу проколы в документации не нашла". А все остальное - это стандартный рабочий процесс.
Когда разработчик планирует свое время, он закладывает риск-буфер на возможный рефакторинг кода. Потому что иногда да, рефакторить слишком долго и лучше поставить отдельную задачу в backlog.
Но это плохая практика так делать, если ты можешь все зарефакторить здесь и сейчас. Не сделаешь сейчас -задача будет пинаться на следующую итерацию, потом снова на следующую итд. А в итоге их накопится очень много и код будет не код, а сборище костылей. Так что, видишь, где можно улучшить - улучшай.
То же самое касается и тестировщиков, у которых есть доступ к коду. Если вы сталкивались с похожими задачками часто, вполне возможно, что вы сами сможете подсказать разработчику, что и как тут сделать. Если вы видите ошибку, иногда бывает проще поправить ее самому, чем ждать, когда у разработчика найдется на это время.
Поэтому не стоит думать, что написать 10 автотестов - невелика задача. Всегда стоить помнить о том, что самый первый автотест отлаживать можно долго. Даже не писать, нет, написать можно и правда быстро. А вот чтобы его отладить, иногда приходится и документацию пользователя поправить, и свою, техническую, тоже, и в коде полазить, что-то поправить, где-то отрефакторить, там подкрутить, тут поднастроить... Главное, не забывать, что если ты что-то правишь, кто-то должен это проверить.
И вот тогда-а-а-а, тогда уже вы увидите заветное "BUILD SUCCESS" и можно будет снова возвращаться к исходной роли тестировщика и продолжать писать автотесты
Комментариев нет:
Отправить комментарий