«Сначала ваши попытки должны были потерпеть крах, чтобы вы были готовы ухватиться за спасательный круг, который вам бросят.»
Е. Херригель
«Дзен и искусство стрельбы из лука»
Ты ручной тестировщик?
На автоматизацию тестирования нет времени?
То, что нужно тестировать, невозможно автоматизировать?
Ты уже достиг вершин, но хочешь посмотреть чей-то чужой путь?
Тогда прошу под кат!
Свою карьеру тестировщика я начал в одной небольшой фирме, занимающейся тестированием самолетного ПО. Там было только автоматизированное тестирование, все процессы были уже построены, в общем — не сильно сложная работа. Мне показали основы написания кода на Visual Basic, показали как запускать тесты, и отправили в дальнее плавание.
Затем моё студенчество закончилось, захотелось больше интересной работы, и я перешел в другую компанию на должность простого ручного тестировщика. Тут нужно сделать небольшое отступление — в небольших кампаниях/отделах тестировщик порой выполняет целую кучу задач, не связанных напрямую с тестированием. Например, развертывание тестовой среды, ведение нескольких веток продукта в сорс контроле, саппорт выпущенных продуктов и т.д. Я попал именно в такую ситуацию.
Поначалу все было хорошо — мы делали свой 1 проект, я все делал руками, и у меня еще оставалась куча свободного времени.
Но постепенно проектов становилось все больше, программисты постоянно фиксили баги, нужно было накатывать билды чуть ли не каждый час. В какой-то момент я заметил, что на собственно тестирование я трачу лишь 40% времени. Остальное время занимают какие-то левые активности. Тогда я понял первое простое правило:
Именно тогда я сделал простую табличку в Excel, и отметил все задачи, на которые тратилось время. И нашел то, что выжирало больше всего времени — банальная выкладка билдов (обновление файлов, екзешников и т.д.). Вечером дома я зарылся в яндекс, и нашел, как убрать эту активность в 0. Я посмотрел синтаксис билдов на нашем билд-сервере, и сделал автоматическую выкладку всего этого хозяйства. После этого я привязал запуск билда к check-in'у в сорс контроле, и обрадовался жизни — у меня опять появилось свободное время! Тогда же я понял второе простое правило:
Постепенно проекты росли, и появились системы, расположенные на нескольких серверах. И, о ужас, — конфиги разработчиков не работали на серверах! А программисты почему-то(!) не хотели их править. Я опять полез ковыряться в билд-машине, и обнаружил, что конфиги можно легко менять на этапе сборки. Тогда я понял третье простое правило:
Примерно тогда же в моем распоряжении появилась первая виртуальная ферма на Hyper-V. Через пару месяцев я уже не представлял себе, как жил до этого. Настолько легко и просто оказалось поднимать тестовые стенды! Отсюда четвертое простое правило:
В то время компания очень сильно выросла, и внезапно оказалось, что для простого заведения учетки в домене нужно писать заявку админам с обоснованием и подтверждениями. Какое-то время мы терпели, а потом я сделал свой тестовый домен. Через месяц я понял, что не только сервер виртуализации был необходим. Отсюда пятое простое правило:
Когда я поднимал тестовый домен, то обнаружил на сервере забавную вещь — Power Shell. Как оказалось, кучу вещей можно сделать без интерфейса — заводить пользователей, настраивать IIS, делать правила в файрволе, устанавливать сервисы и т.д. Кроме того я узнал, что это можно делать не только на своей машине!
И если какую-то задачу на удаленной машине нужно будет сделать больше трёх раз, я всегда пишу скрипт — экономия времени огромна.
В общем, шестое простое правило:
В какой-то момент я осознал, что даже не приступив к автоматизации тестирования, я автоматизировал все остальное!
Тогда я взялся делать свой первый огромный(как мне тогда казалось) проект по автоматизированному тестированию одной огромной монструозной бизнес-функции. Делал я его долго, мучительно, но все-таки сотворил. Вот только там было столько костылей, неявных зависимостей, хардкода и прочего добра, что как-либо поддерживать это создание воспаленного ума оказалось невозможным. Именно тогда я понял, почему эти умные программисты допускают столько косяков… Но это была не последняя монструозная система в моем исполнении — их было еще много. В общем, самое главное седьмое правило:
Именно тут проявила себя цитата, вынесенная в эпиграф. Только сделав несколько ужасных проектов, обломав кучу зубов на поддержке своих творений, я начал понимать то, что написали эти умные дядьки в своих книгах. Только тотальная нехватка времени и тупизна работы по копированию файликов из одного место в другое толкнули меня на путь автоматизации. Только полностью влившись в команду разработки я начал писать относительно нормальный код.
А потом я втянулся. И следующие несколько книжек в плане на прочтение — о программировании. Причем я не буду переходить в программисты, это не моё. Ну а программирующим тестировщиком я уже стал.
И главное, не нужно бояться автоматизации. Это не всегда огромные труды, которые могут принести мифическую прибыль в будущем. Посмотри вокруг! Что-то можно сделать мышкой? С вероятностью в 95% это можно заскриптовать. Ты выполняешь ручные операции уже в пятнадцатый раз? Значит заскриптовать их нужно было еще вчера.
И еще одно пожелание. Научился сам, просвети своих коллег — согласитесь, интереснее работать с людьми, которые делают красивые, сложные проекты, а не ходят в грязном свитере и страдают от своей работы.
Желаю интересных багов, хороших проектов и дружных коллег-программистов!
Е. Херригель
«Дзен и искусство стрельбы из лука»
Ты ручной тестировщик?
На автоматизацию тестирования нет времени?
То, что нужно тестировать, невозможно автоматизировать?
Ты уже достиг вершин, но хочешь посмотреть чей-то чужой путь?
Тогда прошу под кат!
Свою карьеру тестировщика я начал в одной небольшой фирме, занимающейся тестированием самолетного ПО. Там было только автоматизированное тестирование, все процессы были уже построены, в общем — не сильно сложная работа. Мне показали основы написания кода на Visual Basic, показали как запускать тесты, и отправили в дальнее плавание.
Затем моё студенчество закончилось, захотелось больше интересной работы, и я перешел в другую компанию на должность простого ручного тестировщика. Тут нужно сделать небольшое отступление — в небольших кампаниях/отделах тестировщик порой выполняет целую кучу задач, не связанных напрямую с тестированием. Например, развертывание тестовой среды, ведение нескольких веток продукта в сорс контроле, саппорт выпущенных продуктов и т.д. Я попал именно в такую ситуацию.
Поначалу все было хорошо — мы делали свой 1 проект, я все делал руками, и у меня еще оставалась куча свободного времени.
Но постепенно проектов становилось все больше, программисты постоянно фиксили баги, нужно было накатывать билды чуть ли не каждый час. В какой-то момент я заметил, что на собственно тестирование я трачу лишь 40% времени. Остальное время занимают какие-то левые активности. Тогда я понял первое простое правило:
1. Если ты тестировщик, то можно и нужно автоматизировать не только тестирование
Именно тогда я сделал простую табличку в Excel, и отметил все задачи, на которые тратилось время. И нашел то, что выжирало больше всего времени — банальная выкладка билдов (обновление файлов, екзешников и т.д.). Вечером дома я зарылся в яндекс, и нашел, как убрать эту активность в 0. Я посмотрел синтаксис билдов на нашем билд-сервере, и сделал автоматическую выкладку всего этого хозяйства. После этого я привязал запуск билда к check-in'у в сорс контроле, и обрадовался жизни — у меня опять появилось свободное время! Тогда же я понял второе простое правило:
2. Автоматизируй то, что даст наибольший выигрыш по времени
Постепенно проекты росли, и появились системы, расположенные на нескольких серверах. И, о ужас, — конфиги разработчиков не работали на серверах! А программисты почему-то(!) не хотели их править. Я опять полез ковыряться в билд-машине, и обнаружил, что конфиги можно легко менять на этапе сборки. Тогда я понял третье простое правило:
3. Полностью изучи работу билд-машины
Примерно тогда же в моем распоряжении появилась первая виртуальная ферма на Hyper-V. Через пару месяцев я уже не представлял себе, как жил до этого. Настолько легко и просто оказалось поднимать тестовые стенды! Отсюда четвертое простое правило:
4. Подними сервер виртуализации
В то время компания очень сильно выросла, и внезапно оказалось, что для простого заведения учетки в домене нужно писать заявку админам с обоснованием и подтверждениями. Какое-то время мы терпели, а потом я сделал свой тестовый домен. Через месяц я понял, что не только сервер виртуализации был необходим. Отсюда пятое простое правило:
5. Сделай, наконец, свой тестовый домен
Когда я поднимал тестовый домен, то обнаружил на сервере забавную вещь — Power Shell. Как оказалось, кучу вещей можно сделать без интерфейса — заводить пользователей, настраивать IIS, делать правила в файрволе, устанавливать сервисы и т.д. Кроме того я узнал, что это можно делать не только на своей машине!
И если какую-то задачу на удаленной машине нужно будет сделать больше трёх раз, я всегда пишу скрипт — экономия времени огромна.
В общем, шестое простое правило:
6. Разберись с PowerShell/cmd/bash
В какой-то момент я осознал, что даже не приступив к автоматизации тестирования, я автоматизировал все остальное!
Тогда я взялся делать свой первый огромный(как мне тогда казалось) проект по автоматизированному тестированию одной огромной монструозной бизнес-функции. Делал я его долго, мучительно, но все-таки сотворил. Вот только там было столько костылей, неявных зависимостей, хардкода и прочего добра, что как-либо поддерживать это создание воспаленного ума оказалось невозможным. Именно тогда я понял, почему эти умные программисты допускают столько косяков… Но это была не последняя монструозная система в моем исполнении — их было еще много. В общем, самое главное седьмое правило:
7. Хочешь автоматизировать? Учись правильно программировать! Прочитай книги по архитектуре программ
Именно тут проявила себя цитата, вынесенная в эпиграф. Только сделав несколько ужасных проектов, обломав кучу зубов на поддержке своих творений, я начал понимать то, что написали эти умные дядьки в своих книгах. Только тотальная нехватка времени и тупизна работы по копированию файликов из одного место в другое толкнули меня на путь автоматизации. Только полностью влившись в команду разработки я начал писать относительно нормальный код.
А потом я втянулся. И следующие несколько книжек в плане на прочтение — о программировании. Причем я не буду переходить в программисты, это не моё. Ну а программирующим тестировщиком я уже стал.
И главное, не нужно бояться автоматизации. Это не всегда огромные труды, которые могут принести мифическую прибыль в будущем. Посмотри вокруг! Что-то можно сделать мышкой? С вероятностью в 95% это можно заскриптовать. Ты выполняешь ручные операции уже в пятнадцатый раз? Значит заскриптовать их нужно было еще вчера.
И еще одно пожелание. Научился сам, просвети своих коллег — согласитесь, интереснее работать с людьми, которые делают красивые, сложные проекты, а не ходят в грязном свитере и страдают от своей работы.
Желаю интересных багов, хороших проектов и дружных коллег-программистов!
