Комментарии 40
ну теперь я точно заскриптую половину своей ежедневной работы)
Я не профессиональный тестировщик (тестировать свои админки и сайты не в счет) но статья реально интересная и полезная!!!
Спасибо!!!
Может офф-топ, но подскажите хорошие книги по архитектуре программ…
Спасибо!!!
Может офф-топ, но подскажите хорошие книги по архитектуре программ…
Мартин Фулер классика:
http://www.ozon.ru/context/detail/id/1616782/
http://www.ozon.ru/context/detail/id/1616782/
Для начала можно почитать также классику «банды четырех»:
www.ozon.ru/context/detail/id/2457392/
В книге довольно хорошо описывается различные приемы проектирования и приводятся примеры их применения.
www.ozon.ru/context/detail/id/2457392/
В книге довольно хорошо описывается различные приемы проектирования и приводятся примеры их применения.
И все перечисленные книги:
depositfiles.com/ru/files/9s7wdpc4x
depositfiles.com/ru/files/rtb9rro7q
depositfiles.com/ru/files/uvtmebdob
depositfiles.com/ru/files/9s7wdpc4x
depositfiles.com/ru/files/rtb9rro7q
depositfiles.com/ru/files/uvtmebdob
Хорошая статья, все по делу. И написана хорошо. Честно говоря первая за последнее время длинная статья про тестирование, что я прочел.
Не думали о том, чтобы выступить на конференции SQA Days? Следующая будет осенью, дата пока официально не объявлена.
Не думали о том, чтобы выступить на конференции SQA Days? Следующая будет осенью, дата пока официально не объявлена.
Думаю об этом. Весеннюю конференцию я как-то провафлил, была куча дел. А на осеннюю собираюсь как минимум слушателем.
Я уверен, что человеку с 5-ти летним опытом уже есть, что рассказать. Судя по тому, как построена ваша статья — вы умеете подавать материал. А выступить и рассказать людям о своем опыте — это будет и слушателям интересно и весьма полезно самому. Я каждый раз много нового узнаю, при подготовке доклада.
Будем рады видеть в рядах докладчиков!
Будем рады видеть в рядах докладчиков!
Предлагаю таки отправиться в качестве докладчика ;)
Аминь, брат!
Блин, ну это вот круто. За пол-года это — самая лучшая статья по теме тестирования, которую я видел.
Виртуальные машины и автоматизированное развёртывание — вещь, конечно, необходимая, но почему этим занимается не тест-менеджер и системный администратор?
Так вот пусть они и сделают это 1 раз. Чтобы потом не терять полезное время сотрудника. А насчёт раздражать… Так профессия такая у тестировщика:) Всё лучше, чем получить потом раздраженного клиента.
побольше бы таких ребят как автор! С огромным удовольствием работал бы с ним в кодной комманде. От себя хочется еще отметить что к сожалению понимание вещей и желание максимально автоматизировать приходят не сразу а после значительного количенства потраченого зря времени, и его так жалко…
Уточню, что автор совершенно правильно заметил что автоматизировал он не максимально, а рационально, то есть то что требовало много времени :)
А вообще всё хорошо написано. У автора раскрыта тема удобства тестирования, есть ещё сторона качества тестирования. По мне, за этим нужно идти к Rex Black в «Managing the Testing Process»
А вообще всё хорошо написано. У автора раскрыта тема удобства тестирования, есть ещё сторона качества тестирования. По мне, за этим нужно идти к Rex Black в «Managing the Testing Process»
Собственно, все вышеописанные правила применимы и к программистам. Автоматизация рулит. Довелось мне как-то работать в серьезном устоявшемся проекте. Процесс требовал обязательного апдейта несметного количества документации, в которую заносился список сиарок, список пройденных/зафэйленых тестов и т.п. и т.д. Это отнимало просто уйму времени, сил и нервов. В конце концов нам это надоело и были написаны скрипты, которые делали это полностью автоматически (всплоть до получения описания сиарок из bugtraq системы). Времени было потрачено прилично, но оно того стоило — жить стало гораздо легче =)
Мораль — всё что может быть автоматизировано — должно быть автоматизировано.
Мораль — всё что может быть автоматизировано — должно быть автоматизировано.
Было бы здорово, если бы в статьей еще дали пару ссылок на хорошие доки по PowerShell (по каким вы разбирались) и другие инструменты автоматизации. А так — статья очень интересная, спасибо!
Хорошая статья для начинающих есть на хабре.
Самое главное понять логику работы оболочки, конкретные команды всегда можно найти в гугле.
Для конкретных действий есть также довольно подробная справка от Microsoft. Там есть разделы по функциональностям, можно довольно быстро найти нужное. Если же что-то совсем непонятное, можно обратиться к коллегам-программистам с конкретным вопросом.
Самое главное понять логику работы оболочки, конкретные команды всегда можно найти в гугле.
Для конкретных действий есть также довольно подробная справка от Microsoft. Там есть разделы по функциональностям, можно довольно быстро найти нужное. Если же что-то совсем непонятное, можно обратиться к коллегам-программистам с конкретным вопросом.
Непосредственно к тестированию относятся лишь последние три пункта, если уж быть совсем честным =)
Это скорей всего статья на тему «выживание тестировщика» +)
Я сам по этому пути прошел и даже подзавяз чуть дальше. А знаете во что это может вылиться и к чему надо быть готовым?
Первое, это то, что вскоре на вас могут свесить администрирование инфраструктуры. Дак что же тут сложно, можете ответить, я ведь её то и создал, тащил скрипты на своем горбу! А то, что сетевые конфликты, переполнение буфера пакетов, детали виртуализации и прочее требует большего, нежели вечер проведенный с поисковиками.
Отсюда и вторая опасность — времени собственно на самое тестирование будет становиться все меньше и меньше.
Ну и до кучи третий фактор, несколько раздражающий — это переключение между обязанностями. Более того, вас будут дергать для поднятия стенда именно в тот момент, когда вы будете в глубоком трансе написания теста, который должен находить все ошибки в системе +)
Но собственно какой в написанном выше смысл? Подобная инициатива очень похвальна и указывает на достаточную зрелость, но неплохо бы это координировать с начальством, потому что описанное автором немного большее нежели автоматизация собственного труда. Какие будут плюсы? Плоды автоматизации смогут пожинать все сотрудники, оставшееся после вас наследие не будет балластом для потомков, широкая общественность отдела будет знать своего героя +)
Это скорей всего статья на тему «выживание тестировщика» +)
Я сам по этому пути прошел и даже подзавяз чуть дальше. А знаете во что это может вылиться и к чему надо быть готовым?
Первое, это то, что вскоре на вас могут свесить администрирование инфраструктуры. Дак что же тут сложно, можете ответить, я ведь её то и создал, тащил скрипты на своем горбу! А то, что сетевые конфликты, переполнение буфера пакетов, детали виртуализации и прочее требует большего, нежели вечер проведенный с поисковиками.
Отсюда и вторая опасность — времени собственно на самое тестирование будет становиться все меньше и меньше.
Ну и до кучи третий фактор, несколько раздражающий — это переключение между обязанностями. Более того, вас будут дергать для поднятия стенда именно в тот момент, когда вы будете в глубоком трансе написания теста, который должен находить все ошибки в системе +)
Но собственно какой в написанном выше смысл? Подобная инициатива очень похвальна и указывает на достаточную зрелость, но неплохо бы это координировать с начальством, потому что описанное автором немного большее нежели автоматизация собственного труда. Какие будут плюсы? Плоды автоматизации смогут пожинать все сотрудники, оставшееся после вас наследие не будет балластом для потомков, широкая общественность отдела будет знать своего героя +)
Это очень хорошо, когда тестировщик занимается только тестированием, администратор — только администрированием, а программисты только пишут код.
Мы с самого начала занимались администрированием тестовой инфраструктуры, т.к. целью тестовой инфраструктуры было уйти от взаимодействия с админами. Наши администраторы, конечно, сделают все лучше и быстрее. Но для этого нужно найти человека и поставить ему задачу. У него тоже есть свои дела, и машину он поднимет к вечеру. А я сейчас делаю новую систему из образа минут за 10, а то и меньше.
Какие плюсы? В нашей команде сейчас 7 тестировщиков. Каждый может создавать стенды для себя, поэтому никто не дергает. Сейчас у нас есть две основных двухпроцессорных фермы по 56 гб оперативки, поэтому проблем в ресурсах не наблюдается. Каждый может настраивать билды в своих проектах и выполнять базовые активности. Каждый делает кучу работы без напряга, поэтому все работают без овертайма. По-мойму, плюсы очевидны :)
Мы с самого начала занимались администрированием тестовой инфраструктуры, т.к. целью тестовой инфраструктуры было уйти от взаимодействия с админами. Наши администраторы, конечно, сделают все лучше и быстрее. Но для этого нужно найти человека и поставить ему задачу. У него тоже есть свои дела, и машину он поднимет к вечеру. А я сейчас делаю новую систему из образа минут за 10, а то и меньше.
Какие плюсы? В нашей команде сейчас 7 тестировщиков. Каждый может создавать стенды для себя, поэтому никто не дергает. Сейчас у нас есть две основных двухпроцессорных фермы по 56 гб оперативки, поэтому проблем в ресурсах не наблюдается. Каждый может настраивать билды в своих проектах и выполнять базовые активности. Каждый делает кучу работы без напряга, поэтому все работают без овертайма. По-мойму, плюсы очевидны :)
Согласен.
Да и описанное это скорее частные случаи. Нет нужды всем тестировщикам знать как работает билд-машина и поднимать свой сервер виртуализации/домен.
Так что это не правила, а просто история развития автора.
Да и описанное это скорее частные случаи. Нет нужды всем тестировщикам знать как работает билд-машина и поднимать свой сервер виртуализации/домен.
Так что это не правила, а просто история развития автора.
Что плохого в том, что все будут знать?
А что в этом хорошего?
Это просто лишние знания на проектах где не будет тестовых окружений как таковых — например на веб проектах, где не надо самим собирать билды.
Куда лучше тестировщику изучать то что необходимо под нужды его проекта, а не ломиться с головой в автоматизацию.
Хорошие «ручные» тестировщики большая редкость.
Это просто лишние знания на проектах где не будет тестовых окружений как таковых — например на веб проектах, где не надо самим собирать билды.
Куда лучше тестировщику изучать то что необходимо под нужды его проекта, а не ломиться с головой в автоматизацию.
Хорошие «ручные» тестировщики большая редкость.
«Ручной» тестировщик, который понимает как работает билд процедура, который сам может построить билд хуже другого «ручного», который этого не умеет? Не думаю, что вы так думаете.
Посмотрите на первое правило из статьи — про автоматзацию не тестирования. Абсолютно верно. Многие под автоматизацией понимают исключительно некий скрипт/тул, который умеет кликать, быстрее и тупее, чем самый быстрый и тупой кликер. Но это ведь не так.
Можно автоматизировать создание тестовых данных, сравнение логов, анализ результатов, да и еще кучу чего. При этом выполняя само тестирование руками.
В нашей профессии, чем больше знает и умеет человек — тем это более ценно.
Программист может годами писать код, пользуясь одним языком и одним фреймфорком, меняя конторы, и накапливая опыт и оттачивая свое умение. Тестировщик же должен быть всегда готов к новым тестам, т.к. если тестировщик годами тестирует одно и тоже он не развивается, а деградирует.
Посмотрите на первое правило из статьи — про автоматзацию не тестирования. Абсолютно верно. Многие под автоматизацией понимают исключительно некий скрипт/тул, который умеет кликать, быстрее и тупее, чем самый быстрый и тупой кликер. Но это ведь не так.
Можно автоматизировать создание тестовых данных, сравнение логов, анализ результатов, да и еще кучу чего. При этом выполняя само тестирование руками.
В нашей профессии, чем больше знает и умеет человек — тем это более ценно.
Программист может годами писать код, пользуясь одним языком и одним фреймфорком, меняя конторы, и накапливая опыт и оттачивая свое умение. Тестировщик же должен быть всегда готов к новым тестам, т.к. если тестировщик годами тестирует одно и тоже он не развивается, а деградирует.
«В нашей профессии, чем больше знает и умеет человек — тем это более ценно.»
Согласен.
===
"«Ручной» тестировщик, который понимает как работает билд процедура, который сам может построить билд хуже другого «ручного», который этого не умеет?"
Если он изучал как работает билд процедура пока другой читал книги по теории — то да, он будет хуже.
===
Важны не любые знания, а те которые нужны на данном конкретном проекте.
Если у меня будет свободное время на обучение — я сяду и буду читать про тестирование безопасности, тестирование локализации, но никак не про то как работает билд сервер.
Согласен.
===
"«Ручной» тестировщик, который понимает как работает билд процедура, который сам может построить билд хуже другого «ручного», который этого не умеет?"
Если он изучал как работает билд процедура пока другой читал книги по теории — то да, он будет хуже.
===
Важны не любые знания, а те которые нужны на данном конкретном проекте.
Если у меня будет свободное время на обучение — я сяду и буду читать про тестирование безопасности, тестирование локализации, но никак не про то как работает билд сервер.
===
Важны не любые знания, а те которые нужны на данном конкретном проекте.
===
С этим трудно поспорить :)
===
Если у меня будет свободное время на обучение — я сяду и буду читать про тестирование безопасности, тестирование локализации, но никак не про то как работает билд сервер.
===
А вот теперь понятно, почему возникли разногласия. Я более склонен к изучению предмета на практике и скорее разберусь в каких-нибудь технических подробностях своего продукта. Возможно появятся мысли о новых тестах или подходах. При изучении теории у меня такие мысли появляются намного реже.
А изучать же теорию по тестированию того, что мне тестировать не нужно я точно не буду вообще. Ну разве что на встрече нашего сообщества тестировщиков кто-нибудь будет рассказывать :)
Важны не любые знания, а те которые нужны на данном конкретном проекте.
===
С этим трудно поспорить :)
===
Если у меня будет свободное время на обучение — я сяду и буду читать про тестирование безопасности, тестирование локализации, но никак не про то как работает билд сервер.
===
А вот теперь понятно, почему возникли разногласия. Я более склонен к изучению предмета на практике и скорее разберусь в каких-нибудь технических подробностях своего продукта. Возможно появятся мысли о новых тестах или подходах. При изучении теории у меня такие мысли появляются намного реже.
А изучать же теорию по тестированию того, что мне тестировать не нужно я точно не буду вообще. Ну разве что на встрече нашего сообщества тестировщиков кто-нибудь будет рассказывать :)
Поддерживаю твою позицию. Практические навыки намного быстрее приносят новые знания. Оглянуться не успеешь, как то, что изложено в теоретических выкладках (книгах), уже давно изучено на опыте.
Даже оглядываясь на свой опыт (а делал я и то, чем занимается автор статьи), не раз замечал, что то, что пишут в книгах уже давно изучено. В некотором роде теория отстает от практики.
Но есть разница прочувствовать все на своем горбу или дождаться умной книжки и уже по ней пытаться что-то делать. Очевидно у кого будет преимущество. Ведь в этом и есть смысл обучения и приобретения опыта.
Даже оглядываясь на свой опыт (а делал я и то, чем занимается автор статьи), не раз замечал, что то, что пишут в книгах уже давно изучено. В некотором роде теория отстает от практики.
Но есть разница прочувствовать все на своем горбу или дождаться умной книжки и уже по ней пытаться что-то делать. Очевидно у кого будет преимущество. Ведь в этом и есть смысл обучения и приобретения опыта.
8. Винда не единственная ОС во вселенной
главное этот скриптовый зоопарк документировать, а то при смене сотрудника может случится казус
Спасибо за отличную статью. Описано большинство граблей, на которые наступал все эти годы.
9. Бросить писать скрипты, сделать нормальный фреймворк.
Пора заскриптовать чтение хабра. Работаешь себе, а хабр сам читается :)
Автору огромный плюс.
Все вышеописанные вещи — очевидны для человека, который хоть раз с ними сталкивался, но для новичков — неоценимы. Серьезный вклад в качественный development process
Все вышеописанные вещи — очевидны для человека, который хоть раз с ними сталкивался, но для новичков — неоценимы. Серьезный вклад в качественный development process
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Семь правил тестировщика