Comments 156
UFO just landed and posted this here
Я в коммерческой разработке не работала, но, наверное, да, то же самое. Только в разработке средний уровень квалификации выше и нет образа «разработчик = мартышка». А среди тестировщиков много действительно низкоквалифицированных сотрудников, во многом из-за того что у нас отрасль не развита, во-многом из-за того что далеко не все компании понимают его важность. В итоге, низкоквалифицированные сотрудники дискредитируют отрасль как таковую.
А ведь это не так! Тестирование базируется на очень обширном пласте методологии, который просто почти никто либо не знает, либо использовать не умеет. Обидно :(
А ведь это не так! Тестирование базируется на очень обширном пласте методологии, который просто почти никто либо не знает, либо использовать не умеет. Обидно :(
Полностью вас поддерживаю. Хорошего тестера найти гораздо сложнее, чем программиста.
тестировщика
тестер — это лакмусовая бумажка =)
тестер — это лакмусовая бумажка =)
Лакмусовая бумажка — это лакмусовая бумажка. А тот, кто тестирует — тестер.
В русском языке, если верить орфографическому словарю РАН (вплоть до 2007 года), слова «тестировщик» не существует. Специалиста по тестированию, если верить тому же словарю, надо называть тестором.
В английском слово есть, должность/роль называется tester.
Поэтому, можно использовать американизм тестер; неизвестный, но правильный термин тестор или известный, но несуществующий термин тестировщик.
Что плохого в слове «тестер»?
В английском слово есть, должность/роль называется tester.
Поэтому, можно использовать американизм тестер; неизвестный, но правильный термин тестор или известный, но несуществующий термин тестировщик.
Что плохого в слове «тестер»?
Тестер — это приборчик с двумя щупами и индикатором. Показывает наличие электрического контакта, целостность электрической цепи. Простейший — из проводков, батарейки и лампочки. ;)
Вам сюда: maximals.ru/notes/2010/03/23/homonyms/
Простейший — из проводков, батарейки и лампочки называется аркашка ;)
Ну это уже слишком.
Не слишком, согласна с комментарием. Просто у всех складывается впечатление, что тестировщики — это мартышки, нажимающие на кнопочки. И есть причины, это не выдумки — чаще всего так оно и есть! К сожалению :(
Средняя квалификация тестировщиков ниже «прожиточного минимума» и находится за чертой бедности. Это влияет на рынок — каждый чайник может найти себе работу с приемлемой зарплатой.
С разработчиками не так — полного чайника на работу никто не возьмёт, поэтому разработчики в среднем обладают адекватным уровнем квалификации.
Найти грамотного тестировщика в России — задача не из простых, их почти нет. И самое ужасное в том, что неопытные мартышки отказываются это понимать, считая себя грамотными тестерами. В итоге такое горе-тестирование не экономит затраты на разработку, а только увеличивает. И «тестировщикам» скучно-нудно, и программистам мешают больше чем помогают, и качество результата соответствующее.
Средняя квалификация тестировщиков ниже «прожиточного минимума» и находится за чертой бедности. Это влияет на рынок — каждый чайник может найти себе работу с приемлемой зарплатой.
С разработчиками не так — полного чайника на работу никто не возьмёт, поэтому разработчики в среднем обладают адекватным уровнем квалификации.
Найти грамотного тестировщика в России — задача не из простых, их почти нет. И самое ужасное в том, что неопытные мартышки отказываются это понимать, считая себя грамотными тестерами. В итоге такое горе-тестирование не экономит затраты на разработку, а только увеличивает. И «тестировщикам» скучно-нудно, и программистам мешают больше чем помогают, и качество результата соответствующее.
Скажите, а ваша квалификация тестировщика как-то мешает Вам писать автоматизированные функциональные и модульные тесты?
Если мешает, то чем, простите, ваш труд не обезьяний?
Если мешает, то чем, простите, ваш труд не обезьяний?
Автоматизировать тесты мне квалификаия не мешает, в целом комментарий не поняла.
Автоматизация тоже может быть бесполезной, и при тупом рекорд-энд-реплее, и при создании собственного высокотехнологичного keyword-driven фреймворка. Наличие технических навыков — далеко не всегда залог успеха.
Сравнивать навыки разработки и тестирования бессмысленно. В автоматизации навыки разработки нужны и полезны, в других случаях — не уверена. А по Вашему комментарию можно решить, что любой программист, который не умеет сводить бухгалтерские балансы, не умеет строить 5-ступенчатые продажи и не имеем опыт в MLM — тупая мартышка. Но ведь это не так?
Тестирование — не ветвь разработки, это параллельная область деятельности.
Автоматизация тоже может быть бесполезной, и при тупом рекорд-энд-реплее, и при создании собственного высокотехнологичного keyword-driven фреймворка. Наличие технических навыков — далеко не всегда залог успеха.
Сравнивать навыки разработки и тестирования бессмысленно. В автоматизации навыки разработки нужны и полезны, в других случаях — не уверена. А по Вашему комментарию можно решить, что любой программист, который не умеет сводить бухгалтерские балансы, не умеет строить 5-ступенчатые продажи и не имеем опыт в MLM — тупая мартышка. Но ведь это не так?
Тестирование — не ветвь разработки, это параллельная область деятельности.
Что тогда есть тестирование? Прокликивание ссылок и потягивание веб-странички за угол во всех браузерах?
Первая задача тестирования — эмулировать работу конечного пользователя.
Там, где ПО будет использовать человек, проверять пригодность ПО к эксплуатации нужно человеком, а не роботом. Проверять надо глазами, руками, ушами и всем прочим — зрительно, тактильно, смыслово, и много других точек взаимодействия человека с ПО посредством компьютера.
Можно автоматизировать проверку правильной работы чего угодно (речь не об GUI) — любой функции и переплетения взаимодействия нескольких функций, и робот покажет, что действительно все работает как надо, можем выпускать.
Но когда ПО попадет в руки пользователей — «неадекватных вандалов», если будет угодно ;), методы и манеры использования ПО будут отличаться от того, как все это дело проверил робот.
Что такое тестирование вообще: это
* проверка соответствия программы требованиям (что робот может сделать),
* осуществляемая путем наблюдения за ее работой (тут уже нужен человек)
* в специальных, искусственно созданных ситуациях, выбранных определенным образом (сугубо человеческое занятие).
Вот подробности.
То есть, в ходе тестирования можно работать и руками, и роботом, и суждением человеческим, и ощущениями (удобно ли, задалбывает ли, кнопки видны на мониторе или не видны). Обходиться только чем-то одним не дальновидно и результат будет «ущербным».
Да и дешевле обычного человека посадить за комп и предложить давить кнопки, чем программиста, который попытается автоматизировать всё и вся.
Там, где ПО будет использовать человек, проверять пригодность ПО к эксплуатации нужно человеком, а не роботом. Проверять надо глазами, руками, ушами и всем прочим — зрительно, тактильно, смыслово, и много других точек взаимодействия человека с ПО посредством компьютера.
Можно автоматизировать проверку правильной работы чего угодно (речь не об GUI) — любой функции и переплетения взаимодействия нескольких функций, и робот покажет, что действительно все работает как надо, можем выпускать.
Но когда ПО попадет в руки пользователей — «неадекватных вандалов», если будет угодно ;), методы и манеры использования ПО будут отличаться от того, как все это дело проверил робот.
Что такое тестирование вообще: это
* проверка соответствия программы требованиям (что робот может сделать),
* осуществляемая путем наблюдения за ее работой (тут уже нужен человек)
* в специальных, искусственно созданных ситуациях, выбранных определенным образом (сугубо человеческое занятие).
Вот подробности.
То есть, в ходе тестирования можно работать и руками, и роботом, и суждением человеческим, и ощущениями (удобно ли, задалбывает ли, кнопки видны на мониторе или не видны). Обходиться только чем-то одним не дальновидно и результат будет «ущербным».
Да и дешевле обычного человека посадить за комп и предложить давить кнопки, чем программиста, который попытается автоматизировать всё и вся.
Кроме того, 5-ступенчатые продажи и бухгалтерские балансы никак не связаны с программированием.
А тестирование, как Вы сами сказали, это параллельная область деятельности. Придирка к комментарию не засчитана!
А тестирование, как Вы сами сказали, это параллельная область деятельности. Придирка к комментарию не засчитана!
Ну так, конечно убедили. Если дело в соотношении квалифицированных специалистов, то тогда программистам, хотя бы в моем лице, высказывание уже не обидно :)
Просто мне еще и доводилось один раз искать программиста на свое место — было очень не легко (как бы самонадеянно это ни звучало).
Просто мне еще и доводилось один раз искать программиста на свое место — было очень не легко (как бы самонадеянно это ни звучало).
Да не, не самонадеянно. Хороших программистов тоже мало, знаю, искала и сейчас ищу :)
Но «хороший программист» — это хороший программист, они в наших условиях иногда встречаются. А хорошим тестировщиком зачастую кого только не называют, и по-настоящему хороших днём с огнём. Я в американских компаниях работала — у них уровень разработки такой же как у нас или даже в среднем пониже. А уровень тестирования — мама дорогая, мы по сравнению с Америкой в каменном веке, а они уже в космосе :)
Но «хороший программист» — это хороший программист, они в наших условиях иногда встречаются. А хорошим тестировщиком зачастую кого только не называют, и по-настоящему хороших днём с огнём. Я в американских компаниях работала — у них уровень разработки такой же как у нас или даже в среднем пониже. А уровень тестирования — мама дорогая, мы по сравнению с Америкой в каменном веке, а они уже в космосе :)
> нет образа «разработчик = мартышка»
Да ну, даже «термин» такой есть — code monkey )
Да ну, даже «термин» такой есть — code monkey )
UFO just landed and posted this here
UFO just landed and posted this here
Заинтриговали. Хотелось бы почитать о методологии. Есть в интернете достойные, на Ваш взгляд, материалы?
Я бы сказал, то же самое относительно всего. Если ты не умеешь делать свою работу и не хочешь учиться, не видишь в этой работе смысла, и вообще работа не нравится — она будет бесить, вызывать стрессы и ненависть ко всему живому.
Правильно говорят — тестировщиком надо родиться.
Не согласен с пунктом (4). Есть обязательные use case которые просто нуждаются 100% в автоматических тестах. Например, функция «заплатить».
PS: для этого, есть например, selenium. Если выстроить абстракцию над API, тестировать всё будет в несколько порядков проще.
PS: для этого, есть например, selenium. Если выстроить абстракцию над API, тестировать всё будет в несколько порядков проще.
Привет!
Пункт 4 про неподходящесть выбора. Иногда подходит свободное исследовательское, а иногда — нет. Иногда важна строгая отчётность, а иногда она не имеет смысла. Иногда автоматизация возможна, а иногда — нет.
Вопрос в том, оптимален ли выбор.
Пункт 4 про неподходящесть выбора. Иногда подходит свободное исследовательское, а иногда — нет. Иногда важна строгая отчётность, а иногда она не имеет смысла. Иногда автоматизация возможна, а иногда — нет.
Вопрос в том, оптимален ли выбор.
Это всё понятно, тока это всё бла-бла. В любом случае, либо автоматы, либо индусы — при больших размерах проекта. В данном контексте, это для меня почти одно и тоже. У Вас маленький проект. Сколько тестов написали? Посмотрите в проект, где тестов десятки тысячь. Шаг на право, шаг на лево — расстрел.
Я отвечала за тестирование проекта с командой из 40 тестировщиков. Поверьте, я знаю, о чём говорю — творчество возможно ВСЕГДА :)
Приведите примеры Вашего понятия творчества. Возможно мы находимся на разных плоскостях.
Расскажу по своему опыту:
* Создать набор тестов, покрывающий 20 миллионов строк кода за приемлемые ресурсы, используя более 15 паттернов создания тестов — это творчество (творчество тест-аналитика)
* Описать тесты так, чтобы они были понятны людям разной квалификации, располагались в грамотной последовательности и содержали оптимальную плотность проверок для достижения компромисса между затратами на тестирование и прозрачной отчётностью — это творчество (творчество тест-дизайнера)
* Организовать тестирование без пересечения трудозатрат на запуск трёх тысяч тест-кейсов — это творчество (творчество тест-менеджера)
* Проверять готовые тесты (учитывая размер команды, одни и те же не чаще раза в месяц-два), причём не просто тыкнув по шагам и нажав Passed/Failed, а осветив новые, смежные области — это творчество (тестировщика)
* Регулярная проверка BVT, которая либо проводится за 20 минут, либо выявляет баги, которые необходимо локализовать/генерализовать оптимальным образом, чтобы не говорить бесполезное «здесь что-то не работает» — это творчество (тестировщика)
* Автоматизировать тестирование продукта, использующего десятки платформ — это творчество (автоматизатора)
* Найти грамотных людей, заразить их интересом, помочь им понять что им дейтсвительно нравится — это творчество (тест-менеджера)
* Проводить исследовательское тестирование для поиска новых юз-кейсов и нивелирования эффекта пестицида — это творчество (тестировщика)
* Продумать организацию нагрузочного тестирования — это творчество (тестировщика)
*…
Решать простые задачи — это скучно.
Искать новые подходы и непрерывно совершенствовать результаты работы — не скучно.
Будучи тест-менеджером на вышеописанном проекте, я лично участвовала во всех активностях. Потому что это было действительно очень интересно.
* Создать набор тестов, покрывающий 20 миллионов строк кода за приемлемые ресурсы, используя более 15 паттернов создания тестов — это творчество (творчество тест-аналитика)
* Описать тесты так, чтобы они были понятны людям разной квалификации, располагались в грамотной последовательности и содержали оптимальную плотность проверок для достижения компромисса между затратами на тестирование и прозрачной отчётностью — это творчество (творчество тест-дизайнера)
* Организовать тестирование без пересечения трудозатрат на запуск трёх тысяч тест-кейсов — это творчество (творчество тест-менеджера)
* Проверять готовые тесты (учитывая размер команды, одни и те же не чаще раза в месяц-два), причём не просто тыкнув по шагам и нажав Passed/Failed, а осветив новые, смежные области — это творчество (тестировщика)
* Регулярная проверка BVT, которая либо проводится за 20 минут, либо выявляет баги, которые необходимо локализовать/генерализовать оптимальным образом, чтобы не говорить бесполезное «здесь что-то не работает» — это творчество (тестировщика)
* Автоматизировать тестирование продукта, использующего десятки платформ — это творчество (автоматизатора)
* Найти грамотных людей, заразить их интересом, помочь им понять что им дейтсвительно нравится — это творчество (тест-менеджера)
* Проводить исследовательское тестирование для поиска новых юз-кейсов и нивелирования эффекта пестицида — это творчество (тестировщика)
* Продумать организацию нагрузочного тестирования — это творчество (тестировщика)
*…
Решать простые задачи — это скучно.
Искать новые подходы и непрерывно совершенствовать результаты работы — не скучно.
Будучи тест-менеджером на вышеописанном проекте, я лично участвовала во всех активностях. Потому что это было действительно очень интересно.
То, что Вы написали выше называется словом «работа», от слова робот. Робот делает одни и те же движения, каждый день. Извините, но мои представления об интересном, находятся не в вашей плоскости измерения.
ОК. Просто я не делаю то, что мне не интересно и не доставляет удовольствия.
Совсем.
Я могла бы выбрать работу в другой области, которая «не моё», заунывно ходить на неё по утрам и получать деньги. Но я нашла то, что мне действительно нравится, и финансовая сторона вторична. Это — классно, об этом пост, что у всех есть «своё», от которого прёт, и можно делать и ловить кайф и радоваться от работы.
И самое главное — в описанном примере никто не решал одинаковых задач ни разу. Потому что каждый раз всё было по-новому, с улучшениями, учётом обратной связи по результатам и т.д. Потому что при грамотно построенном процессе одинаковых задач нет — для этого есть автоматизация.
Совсем.
Я могла бы выбрать работу в другой области, которая «не моё», заунывно ходить на неё по утрам и получать деньги. Но я нашла то, что мне действительно нравится, и финансовая сторона вторична. Это — классно, об этом пост, что у всех есть «своё», от которого прёт, и можно делать и ловить кайф и радоваться от работы.
И самое главное — в описанном примере никто не решал одинаковых задач ни разу. Потому что каждый раз всё было по-новому, с улучшениями, учётом обратной связи по результатам и т.д. Потому что при грамотно построенном процессе одинаковых задач нет — для этого есть автоматизация.
Всё правильно. Но вместо того чтоб понять, что у другого человека есть своя точка зрения, Вы просто минусуете тех, кто «не по Вашему» мыслит.
Я не ставила Вам минусы, честно слово. Я вообще только плюсы ставлю и те редко :)
Правильно минусуют. Вам про творчество говорят — а Вы где-то «робота» невпопад видите…
Слово «Работа» происходит от слова «раб», если я правильно понимаю русский язык :)
Я хотел этим сказать, что в тестировании задачи ограничены, по сравнению с исследованием. Это была моя мысль.
В программировании кстати задачи тоже ограничены по сравнению с исследованием. Как представлю себе разработку каких-нибудь унылых порталов или бугалтерских приложений… жуть… спроектировать можно, м.б. интересно, а вот все эти миллион одинаковых по сути, но с небольшими отличиями фич реализовывать — тоска тоскливая. А вот проектирование, да прототипирование сложных систем — вот тут жизнь кипит. Это я к тому, что в любой работе есть исследовательская часть, а есть исполнительская, главное оказаться в правильной фазе работ (согласно своим ожиданиям), тогда будет все ок — можно и сложный эффективный авто-верификатор/эмулятор/симулятор для тестирования написать (интересный), а можно и копипастить, формочки делать, да миллион одинаковых проверок реализовывать (более уныло), но в разработке.
Эмм… Не поверие. Как раз «робот» произошел от «работа». Его ввел Карел Чапер, чешский писатель. Работа произошла от слова «раб».
В упор не понимаю людей, которые говорят, что работать — значит быть рабом, потому что такая морфология. Это просто общее наименование, класс. А его объект может быть с любым значением свойств «творчество», «удовольствие» и «бездумная_рутина».
Отвечать собеседнику высокомерным тоном «мои представления находятся не в вашей плоскости измерения» — вообще свинство.
В упор не понимаю людей, которые говорят, что работать — значит быть рабом, потому что такая морфология. Это просто общее наименование, класс. А его объект может быть с любым значением свойств «творчество», «удовольствие» и «бездумная_рутина».
Отвечать собеседнику высокомерным тоном «мои представления находятся не в вашей плоскости измерения» — вообще свинство.
Почему же это свинство? Разные интересы, не больше. Я и не думал никого тут оскорблять.
Да, вы полностью правы, отсылка на «раб» чисто хихическая. Просто для хи-хи. Например, «сторож» = сто рож :)
Писателя фамилия была Чапек.
Писателя фамилия была Чапек.
Да, с Чапеком я малось опечатался. Правда как можно было так промазать..?
Кстати, в качестве списка литературы пользуюсь вашим, за что спасибо.
Кстати, в качестве списка литературы пользуюсь вашим, за что спасибо.
Все перечисленные задачи всё-таки аналитического (или подавляюще аналитического) характера. Где же творчество?
В моём понимании, творчество — синтез, создание чего-то нового.
В моём понимании, творчество — синтез, создание чего-то нового.
Паттернов тестирования заметно больше 15, судя по вот этой книге.
Но вот как не ухитряйся, assert'ы они и остаются assert'ами. Здесь нет сложных интересных алгоритмов, здесь нет процесса творения.
Единственное, что в тестировании действительно любопытно, это нагрузочное тестирование в больших проектах.
Но вот как не ухитряйся, assert'ы они и остаются assert'ами. Здесь нет сложных интересных алгоритмов, здесь нет процесса творения.
Единственное, что в тестировании действительно любопытно, это нагрузочное тестирование в больших проектах.
Приведите, пожалуйста, «набор тестов», по которым Вы (как вы говорите) покрываете «20 миллионов строк кода». Хотелось бы про это послушать.
потому что тестирование — это не просто копание на сайте и подставление чего-угодно неправильного куда угодно. это создание тест-плана на стадии дизайна, где должно подробно описываться что и куда подставлять, что должно выводиться, какой это тип теста. именно это очень тупо и скучно, но позволяет по-хорошему тестировать проект.
Привет!
Иногда тест-планы и тестовые сценарии очень важны, а иногда они не приносят пользы. Тут вопрос в продукте, общем процессе, сотрудниках — очень от многого зависит. Часто важны скрипты — но не всегда, иногда без сценариев результат явно лучше.
Да и скрипты создавать — непрерывное творчество, автоматизировать — непрерывное творчество, проходить ручные скрипты тоже можно по-разному. Кому-то написано «тыкни сюда, нажми сюда» — он и тыкает. А кто-то всегда находит творчество в этом процессе, и результат при таком подходе в разы лучше!
Иногда тест-планы и тестовые сценарии очень важны, а иногда они не приносят пользы. Тут вопрос в продукте, общем процессе, сотрудниках — очень от многого зависит. Часто важны скрипты — но не всегда, иногда без сценариев результат явно лучше.
Да и скрипты создавать — непрерывное творчество, автоматизировать — непрерывное творчество, проходить ручные скрипты тоже можно по-разному. Кому-то написано «тыкни сюда, нажми сюда» — он и тыкает. А кто-то всегда находит творчество в этом процессе, и результат при таком подходе в разы лучше!
В любой работе есть своя рутина, и свое творчество (в той или иной мере).
Вопрос в том, хочется ли человеку креативить в своей области. Программист
Вопрос в том, хочется ли человеку креативить в своей области. Программист
Программист, тестировщик, системный администратор… Нет никакой разницы с такими профессиями как художник, писатель, танцор. Везде своя рутина. Сотый портрет на заказ. Двадцатая космоопера. Ежедневные четырехчасовые тренировки в зале.
Но… В каждой из профессий проявляется свой элемент творчества, если человек хочет этого, и работа тогда оставляет удовлетворение. Не кайф, а именно удоволетворение. Если это есть — человек будет успешным сотрудником, и у него не будет мыслей «на что я трачу свою молодость?».
Но… В каждой из профессий проявляется свой элемент творчества, если человек хочет этого, и работа тогда оставляет удовлетворение. Не кайф, а именно удоволетворение. Если это есть — человек будет успешным сотрудником, и у него не будет мыслей «на что я трачу свою молодость?».
Супер сказано! Полностью согласна. Есть множество вещей, которые я делала и по сто раз и больше. И каждый раз я ищу новые пути, и каждый раз получается лучше.
НО!
Это относится не ко всему. Я не мою каждый раз посуду с творчеством всё лучше и лучше :) Мне это не нравится — потому что НЕ МОЁ. Каждый выбирает то, что ему нравится, к чему душа лежит, в чём можно находить каждый раз творчество.
Но можно и не выбрать, можно считать что «рутина есть всегда, вот и у меня рутина».
НЕТ! Значит, просто, что-то не так :) Если работа в кайф — то она в кайф, если нет — надо искать причины.
НО!
Это относится не ко всему. Я не мою каждый раз посуду с творчеством всё лучше и лучше :) Мне это не нравится — потому что НЕ МОЁ. Каждый выбирает то, что ему нравится, к чему душа лежит, в чём можно находить каждый раз творчество.
Но можно и не выбрать, можно считать что «рутина есть всегда, вот и у меня рутина».
НЕТ! Значит, просто, что-то не так :) Если работа в кайф — то она в кайф, если нет — надо искать причины.
ну вначале тестировать забавно
потом немного приедается — надо что-то менять
например набор знаний
чем больше инструментов — тем уже интересней можно подойти к задаче
и получается не так уж скучно
главное укладываться в сроки))
потом немного приедается — надо что-то менять
например набор знаний
чем больше инструментов — тем уже интересней можно подойти к задаче
и получается не так уж скучно
главное укладываться в сроки))
Да, спасибо, в точку!
«Если у вас только молоток, то любая задача покажется гвоздём» (с) Абрахам Маслоу.
Чем шире диапазон знаний, тем шире диапазон возможностей, тем с большим творчеством можно подходить к решению задач.
«Если у вас только молоток, то любая задача покажется гвоздём» (с) Абрахам Маслоу.
Чем шире диапазон знаний, тем шире диапазон возможностей, тем с большим творчеством можно подходить к решению задач.
Диапазон знаний, это Word, Wiki, IDE + Framework для тестов + пара корявых тулов. Это диапазон знаний?
Тому кто минусует, хочется сказать: «комментарии в студию».
Ну, перечисленные знания смахивают на знания начинающего тестера: отовсюду по чуть-чуть, но главное пропущено.
В тестировании очень важно знание методологии. Техники проектирования тестов очень похожи на паттерны разработки и столь же важны.
Посмотрите на список онлайн-тренингов Алексея Баранцева: software-testing.ru/trainings/records/
20 вебинаров на разные темы! 20! И это — базис, который должен знать каждый! Необходимый минимум.
Тестировщик, который не знает этого — не тестировщик.
В тестировании очень важно знание методологии. Техники проектирования тестов очень похожи на паттерны разработки и столь же важны.
Посмотрите на список онлайн-тренингов Алексея Баранцева: software-testing.ru/trainings/records/
20 вебинаров на разные темы! 20! И это — базис, который должен знать каждый! Необходимый минимум.
Тестировщик, который не знает этого — не тестировщик.
Если это минимум… то у нас в стране единицы тестировщиков =)
Всего 20? Чем Вы хотите меня удивить в линке? Любой язык программирования включает в себя куда более чем 20ать тем.
И вот самое грустное, что да.
20 — это правда мало. А при этом большинство «тестировщиков» и этого не знают — о чём и речь…
20 — это правда мало. А при этом большинство «тестировщиков» и этого не знают — о чём и речь…
Да лан, тот же C# можно выучить за 24 часа (кстати, как технический редактор там Эрик Липперт, один из создателей C#) :)
Если серьезно, то когда я преподавал программирование, то принципы построения программ и неплохие, но функциональные программы мы начинали писать уже после 5-6 занятий. Из них 2 — основы («зачем-и-почему» программируют люди), 3 — синтаксис перемешанный с принцыпами ООП, 1 — вольное плавание (раздача индивидуальных задач)
Я, как разработчик с 10+ лет стажем, действительно снимаю шляпу перед хорошими QA-специалистами. Для меня их работа сравнима с работой дизайнеров — нужно больше чувствовать, чем думать (да не обидятся на меня тестеры :))
И тут нет смысла сравнивать количество «тем», количество книг-семинаров. Тут важно что именно они делают.
Если серьезно, то когда я преподавал программирование, то принципы построения программ и неплохие, но функциональные программы мы начинали писать уже после 5-6 занятий. Из них 2 — основы («зачем-и-почему» программируют люди), 3 — синтаксис перемешанный с принцыпами ООП, 1 — вольное плавание (раздача индивидуальных задач)
Я, как разработчик с 10+ лет стажем, действительно снимаю шляпу перед хорошими QA-специалистами. Для меня их работа сравнима с работой дизайнеров — нужно больше чувствовать, чем думать (да не обидятся на меня тестеры :))
И тут нет смысла сравнивать количество «тем», количество книг-семинаров. Тут важно что именно они делают.
Дальше можно продолжить вот по этому списку: www.softwareqatest.com/qatweb1.html
тем паче хороший тестировщик должен обучаем и любопытен и это должно быть заметно в процессе работы, в противном случае — это хороший исполнитель, но плохой тестировщик)
Всё так. До момента, когда эти 25 багов исправят и попросят вас перепроверить. А потом ещё раз, потому что они исправили 26ой баг, а проверять надо все. И так 40 билдов в месяц.
А автоматическое тестирование на что?
Что-то здесь не так :)
Regression-тестирование это НЕ перетестирование всего и вся. К созданию тестового набора для Regression'a тоже надо подходить творчески, и результат тоже зависит от знаний и навыков. Если Вы прогоняете одни и те же тесты 40 билдов в месяц — значит, у Вас проблема #2… Потому что из-за эффекта пестицида их ROI всё равно очень, очень, очень низкий.
Regression-тестирование это НЕ перетестирование всего и вся. К созданию тестового набора для Regression'a тоже надо подходить творчески, и результат тоже зависит от знаний и навыков. Если Вы прогоняете одни и те же тесты 40 билдов в месяц — значит, у Вас проблема #2… Потому что из-за эффекта пестицида их ROI всё равно очень, очень, очень низкий.
По поводу п. 4. Ведь здесь можно применить автоматические тестирование, что сделает работу еще захватывающей и нетривиальной.
А среди хаброжителей — есть хоть кто-то, кто думает что тестирование это скучно/тупо? Или есть кто-либо, кто ЧАСТЕНЬКО сталкивается с кем то, кто так думает?
За 6ть лет работы в тестировании я практически ни разу не сталкивался с подобной формулировкой… Вот только этот пост и один пост на форуме портала s-t.ru
За 6ть лет работы в тестировании я практически ни разу не сталкивался с подобной формулировкой… Вот только этот пост и один пост на форуме портала s-t.ru
UFO just landed and posted this here
тестировать свои собственные программы скучно/тупо, а тестировать программы коллег — интересно/весело, позволяет отвлечься от своего кода и указать другим на их несовершенство :)
Я думаю, вернее думал до прочтения поста (вернее даже комментов). Например, как-то не считал, что средства автоматизации тестирования это инструмент тестировщика :), думал, что его обязанности заключаются как раз в том, чтобы «ручками» проверить то, что разработчик не смог покрыть автоматическими тестами. Ну и писать тесты на свой, уже написанный, код тоже, по-моему, скучно/тупо. По крайней мере ни одного бага я с их помощью выловить не смог, хотя они должны по определению :), а значит писал их зря.
Автоматизированные тесты пишутся не для того, чтобы находить баги — автотесты полезнее для подтверждения отсутствия багов, и, как следствие, экономии трудозатрат на проверки. Так что может и не зря :)
Есть пласт знаний тестирования, есть пласт знаний разработки, в автоматизированном тестировании они объединяются: требуется как понимание методологии тестирования, так и навыки разработки.
Есть пласт знаний тестирования, есть пласт знаний разработки, в автоматизированном тестировании они объединяются: требуется как понимание методологии тестирования, так и навыки разработки.
Хм… Всегда думал, что тесты нужны, чтобы находить баги на этапе разработки, а не перекладывать «поиск» на конечного пользователя. В большинстве случаев, по-моему, тесты не могут дать гарантии отсутствия багов, а лишь показывают, что с таким-то набором входных данных получается ожидаемый результат, но утверждать на основании этого, что результат будет ожидаемый всегда (читай — багов нет), имхо, нельзя, даже если формально покрыто тестами 100% кода (скорее такие тесты создадут чувство ложной уверенности в отсутствии багов)
Да, всё верно :) Отбираем достаточный для нас набор проверок, которые точно должны работать для релиза, и только их проверяем.
Просто автоматизированными тестами неэффективно искать ошибки — всё равно потом ручками исследовать, фиксить — нет экономии ресурсов… А вручную неэффективно повторять одни и те же тесты, которые всё время (ну или почти всё время) дают Passed. Поэтому автоматизация — это чаще всего проверка стабильно работающего функционала, чтобы подтвердить, что там всё успешно, и освободить время на поиск других дефектов.
А в целом, Вы всё верно написали.
Просто автоматизированными тестами неэффективно искать ошибки — всё равно потом ручками исследовать, фиксить — нет экономии ресурсов… А вручную неэффективно повторять одни и те же тесты, которые всё время (ну или почти всё время) дают Passed. Поэтому автоматизация — это чаще всего проверка стабильно работающего функционала, чтобы подтвердить, что там всё успешно, и освободить время на поиск других дефектов.
А в целом, Вы всё верно написали.
Ключевое слово *Свой* проект, но и небольшой тоже неплохо. :-)
программисты не любят тестирование потому что им приходиться потом эти ошибки исправлять =)
хотя это конечно не проблема самого тестирования
хотя это конечно не проблема самого тестирования
Хорошее тестирование хорошие программисты любят :)
Просто разработчики почти не сталкивались с хорошим тестированием, к сожалению :(
Просто разработчики почти не сталкивались с хорошим тестированием, к сожалению :(
Что-то вы странное что-то сказали. Я и сам разработчик, который стремится исправить всё и вся и в свойм стремлении порой становится неадекватным, стараясь вычестить всё до последней «лодки дёгтя», да и других встречал более адекватных, кто тоже ничего плохого не видел в том, чтобы исправить ошибки.
По-моему ошибок боятся те, кто работать не хочет и старается просто тупо срубить бабла.
И вот ещё мысль, наличие и осознание каких-то ошибок сайчас, позволяет принимать правильные решения в будущем, соответственно совершать как можно меньше ошибок. Видел я разработчиков, которые из года в год один и тот же говнокод писали, так вот они если и исправляли ошибки то либо по остаточному принципу (а если не успевали всё исправить — пофиг), или пока на них не гаркнешь и не заставишь их дело делать, а не просто в носу ковыряться.
По-моему ошибок боятся те, кто работать не хочет и старается просто тупо срубить бабла.
И вот ещё мысль, наличие и осознание каких-то ошибок сайчас, позволяет принимать правильные решения в будущем, соответственно совершать как можно меньше ошибок. Видел я разработчиков, которые из года в год один и тот же говнокод писали, так вот они если и исправляли ошибки то либо по остаточному принципу (а если не успевали всё исправить — пофиг), или пока на них не гаркнешь и не заставишь их дело делать, а не просто в носу ковыряться.
Не хочу лезть в чужой огород (разработка не мой конёк), но по опыту взаимодействия согласна на 100%.
именно, если к делу подходить с умом то пока не пройденны все тесты, то код — тупо не готов.
Хотя мой подход — предугадывать место ошибки и тестировать прямо во время разработки.
Хотя мой подход — предугадывать место ошибки и тестировать прямо во время разработки.
В проекте обязательно должен быть тестировщик — человек, у которотого не замылен глаз вашей разработкой. То, что код должен тестироваться разработчиком — это понятно, но это только начальный этап тестирования. По себе знаю, что если довольно долго работать над какой-то фичей, особенно в огромном проекте, где всех связей с другими компонентами учесть порой просто невозможно (обязательно что-то да забудешь), необходим человек извне (или целый отдел). Сам разработчик как правило не способен полностью действовать как сферический юзер в вакууме.
Снимаю шляпу. Вообще, судя по комментариям, на Хабре преобладают разработчики повышенной адекватности :)
Жаль не все проекты могут позволить себе такую роскошь. В лучшем случае обходятся своими «замыленными» силами, в худшем вообще на тестирование забивают.
Ну даже не знаю… роскошь… ну ладно…
Если проект пока небольшой и только начинается, то вполне наверное достаточно тестирования среди самих разработчиков. Но при этом наверное следует применять такую стратегию, как тестирования функционала друг-друга, т.е. функционал, сделанный одним разработчиком обязательно должны проверить остальные участники разработки. Да и вообще, привлекайте своих друзей, родственников, корешей (возьмите на понт, похвастайтесь в баре, да мало ли ещё какие способы есть), девушку в конце концов — пусть хоть заценят, что вы там клепаете. Бывает, что такие люди со стороны могут даже на начальном этапе сказать что-то дельное… Потом, когда проект наберёт достаточно респекта (сюда входит и «начнёт приносить какую-то прибыль» или появится инвестор, или проявятся явные перспективы, охренительный метод монетизации) и нужен будет человек или люди, которые разработкой заниматься не будут, а будут заниматься проталкиванием и продажей проекта. И вот этим тестировщиком может выступать тот самый первый нанятый менеджер, который будет часть времени посвящать тестированию. Это конечно не мана небесная, но это опять же человек со стороны с пользовательским, а не программистским мышлением, кроме того очень может быть он должен будет научиться пользовать продукт, чтобы потенциальным пользователям не только красивые слайдики показывать — вот и ещё одно тестирование… Также можно пользователей привлечь, выпуская беты и раздавая их за бесплатно, за бесценок или будущие значительные скидки, если они готовы пользоваться даже несколько сыроватой, но всё же какой-то версией и при этом отправлять фидбеки… Пользуйтесь сами, именно пользуйтесь, постоянно, а не просто тестируйте на каком-то наборе примеров (например маленькая студия разрабатываем CMS/фреймворк для создания каких-то там сайтов — возьмитесь за клепание сайтов на определённом этапе разработки с применением своего фреймворка, даже за себестоимость или в «кажущийся» убыток для первых клиентов)… Ну и конечно же не забываем о юнит-тестировании не только при разработке, но и пишите новые юнит-тесты на этапе обнаружения ошибок при получении фидбеков от пользователей, при внутреннем использовании и тестировании своим чудо-менеджером…
В общем всё, что я хочу сказать, так это то, что пути к тестированию, пусть иногда и в чём-то ущербному, но хоть какому-то, найти можно всегда. Но тестировать нужно всегда, если вы действительно хотите, чтобы ваш проект развивался, а не просто застрял на определённом этапе сложности, где вам или переписать всё придётся, или постоянно только и делать, что раздавать костыли на найденные ошибки. И не забывайте вкладывать в эту казалось бы ущербную и убыточную активность дивиденды из денег, человекочасов и прочих ресурсов. Особенно, если проект действительно пошёл и явно будет расти и развиваться — в будущем эти вложения окупятся!
Тестирование — это не роскошь, а необходимость и обязательное условие. Возможно отдел тестирование и является на каком-то (начальном) этапе роскошью, но и тут вроде как извернуться можно. А светлое будущее без отдела тестирования (хоть даже и из одного человека) вообще может не придти.
Вот такие пироги…
Если проект пока небольшой и только начинается, то вполне наверное достаточно тестирования среди самих разработчиков. Но при этом наверное следует применять такую стратегию, как тестирования функционала друг-друга, т.е. функционал, сделанный одним разработчиком обязательно должны проверить остальные участники разработки. Да и вообще, привлекайте своих друзей, родственников, корешей (возьмите на понт, похвастайтесь в баре, да мало ли ещё какие способы есть), девушку в конце концов — пусть хоть заценят, что вы там клепаете. Бывает, что такие люди со стороны могут даже на начальном этапе сказать что-то дельное… Потом, когда проект наберёт достаточно респекта (сюда входит и «начнёт приносить какую-то прибыль» или появится инвестор, или проявятся явные перспективы, охренительный метод монетизации) и нужен будет человек или люди, которые разработкой заниматься не будут, а будут заниматься проталкиванием и продажей проекта. И вот этим тестировщиком может выступать тот самый первый нанятый менеджер, который будет часть времени посвящать тестированию. Это конечно не мана небесная, но это опять же человек со стороны с пользовательским, а не программистским мышлением, кроме того очень может быть он должен будет научиться пользовать продукт, чтобы потенциальным пользователям не только красивые слайдики показывать — вот и ещё одно тестирование… Также можно пользователей привлечь, выпуская беты и раздавая их за бесплатно, за бесценок или будущие значительные скидки, если они готовы пользоваться даже несколько сыроватой, но всё же какой-то версией и при этом отправлять фидбеки… Пользуйтесь сами, именно пользуйтесь, постоянно, а не просто тестируйте на каком-то наборе примеров (например маленькая студия разрабатываем CMS/фреймворк для создания каких-то там сайтов — возьмитесь за клепание сайтов на определённом этапе разработки с применением своего фреймворка, даже за себестоимость или в «кажущийся» убыток для первых клиентов)… Ну и конечно же не забываем о юнит-тестировании не только при разработке, но и пишите новые юнит-тесты на этапе обнаружения ошибок при получении фидбеков от пользователей, при внутреннем использовании и тестировании своим чудо-менеджером…
В общем всё, что я хочу сказать, так это то, что пути к тестированию, пусть иногда и в чём-то ущербному, но хоть какому-то, найти можно всегда. Но тестировать нужно всегда, если вы действительно хотите, чтобы ваш проект развивался, а не просто застрял на определённом этапе сложности, где вам или переписать всё придётся, или постоянно только и делать, что раздавать костыли на найденные ошибки. И не забывайте вкладывать в эту казалось бы ущербную и убыточную активность дивиденды из денег, человекочасов и прочих ресурсов. Особенно, если проект действительно пошёл и явно будет расти и развиваться — в будущем эти вложения окупятся!
Тестирование — это не роскошь, а необходимость и обязательное условие. Возможно отдел тестирование и является на каком-то (начальном) этапе роскошью, но и тут вроде как извернуться можно. А светлое будущее без отдела тестирования (хоть даже и из одного человека) вообще может не придти.
Вот такие пироги…
Это-то само собой имелось в виду (ходя за пару идеек отдельное спасибо :) ). Под роскошью я имел в виду найм (или другие формы сотрудничества) именно профессиональных тестировщиков, которые знают и умеют использовать методологии тестирования, владеют необходимыми инструментами и т. п.
Причём не зная этих методологий, не зная толком, где при нормальном распределении труда начинается область ответственности тестировщика (юнит-тесты кто должен писать, например, а функциональные/интеграционные/приемочные — не знаю даже синонимы эти три названия или нет, вроде да, а может есть различия), каковы его обязанности, как оценивать результат его работы и какой он вообще должен быть этот результат, можно нанять за немалые деньги человека, который профессионалом не является и, как часто пишут на хабре в последнее время, «лишь дискредитирует отрасль». В общем, имхо, у многих весьма смутное представление о том, чем собственно тестировщики должны заниматься. Как-то обещал кто-то в комментах к какому-то топику осветить этот вопрос отдельным постом, но то ли не до того, а может я пропустил.
Причём не зная этих методологий, не зная толком, где при нормальном распределении труда начинается область ответственности тестировщика (юнит-тесты кто должен писать, например, а функциональные/интеграционные/приемочные — не знаю даже синонимы эти три названия или нет, вроде да, а может есть различия), каковы его обязанности, как оценивать результат его работы и какой он вообще должен быть этот результат, можно нанять за немалые деньги человека, который профессионалом не является и, как часто пишут на хабре в последнее время, «лишь дискредитирует отрасль». В общем, имхо, у многих весьма смутное представление о том, чем собственно тестировщики должны заниматься. Как-то обещал кто-то в комментах к какому-то топику осветить этот вопрос отдельным постом, но то ли не до того, а может я пропустил.
посоветуйте литературку по тестированию, хочу брата научить, искали в инете, такой информации как тестирование для чайников или тестирование для проффи практически нет…
software-testing.ru/books/44-review/658-books
К примеру, вот ревью различных книг по тестированию.
Как у брата с английским? Я бы в качестве стартовой посоветовала Ron Patton — «Software Testing». Она, к сожалению, пока что не переводилась.
К примеру, вот ревью различных книг по тестированию.
Как у брата с английским? Я бы в качестве стартовой посоветовала Ron Patton — «Software Testing». Она, к сожалению, пока что не переводилась.
Или вот — бесплатный вводный семинар: software-testing.ru/library/testing/general-testing/921--q-q
Если говорить о тестировании вцелом, просто необходимо упомянуть и об автоматизированном тестировании, а вот это будет интересно как программистам, так и простым тестеровщикам %) Методологии данного тестирования далеко не ограничиваются одним селениумом :)
Наталия, спасибо, текст очень своевременный)
Когда я впервые объявила подругам, не из IT-области, что планирую сменить профессию на тестирование, они были в ужасе. Как это я, «такая коммуникабельная», буду теперь «целый день смотреть в экран». Я посмеялась, и спросила, неужели они думают, что в маркетинге я занималась чем-то другим?
Окунувшись немного в новую профессию, меня очень порадовали следующие вещи:
— Ощущение, что делаешь что-то полезное (не занимаешься впариванием людям товара сомнительного качества, — а обеспечиваешь это качество)
— Измеримый результат работы и эффективность. Даже если количество найденных ошибок снижается, количество пройденных тестов, написанных тест-кейсов, — говорит за себя. Чем больше найдет тестировщик, тем меньше найдет пользователь (в то время как в маркетинге зачастую ней поймешь, был ли хоть какой-то положительный эффект от твоей акции)
Кстати, Наталия, не могли бы вы помочь мне выстроить «план карьеры» тестировщика? Какие навыки необходимы тестеру на раннем этапе, какие в дальнейшем, — если он хочет развиваться?
Пока что у меня получается такая последовательность:
1. Основные понятия тестирования, навыки черноящичного тестирования GUI, написание тест кейсов и баг репортов
2. Автоматизация тестирования: что, как, зачем; Selenium; написание тест плана
3. QTP/SilkTest; тестирование флеш-сайтов и баз данных; grey box testing;
4. Нагрузочное тестирование, load runner; white box testing;
5. ??
Также хотелось бы узнать подробнее про «интересные техники тест-дизайна»)
Когда я впервые объявила подругам, не из IT-области, что планирую сменить профессию на тестирование, они были в ужасе. Как это я, «такая коммуникабельная», буду теперь «целый день смотреть в экран». Я посмеялась, и спросила, неужели они думают, что в маркетинге я занималась чем-то другим?
Окунувшись немного в новую профессию, меня очень порадовали следующие вещи:
— Ощущение, что делаешь что-то полезное (не занимаешься впариванием людям товара сомнительного качества, — а обеспечиваешь это качество)
— Измеримый результат работы и эффективность. Даже если количество найденных ошибок снижается, количество пройденных тестов, написанных тест-кейсов, — говорит за себя. Чем больше найдет тестировщик, тем меньше найдет пользователь (в то время как в маркетинге зачастую ней поймешь, был ли хоть какой-то положительный эффект от твоей акции)
Кстати, Наталия, не могли бы вы помочь мне выстроить «план карьеры» тестировщика? Какие навыки необходимы тестеру на раннем этапе, какие в дальнейшем, — если он хочет развиваться?
Пока что у меня получается такая последовательность:
1. Основные понятия тестирования, навыки черноящичного тестирования GUI, написание тест кейсов и баг репортов
2. Автоматизация тестирования: что, как, зачем; Selenium; написание тест плана
3. QTP/SilkTest; тестирование флеш-сайтов и баз данных; grey box testing;
4. Нагрузочное тестирование, load runner; white box testing;
5. ??
Также хотелось бы узнать подробнее про «интересные техники тест-дизайна»)
Привет!
Спасибо, что так написали про тестирование — всегда очень приятно видеть в этой сфере фанатов своего дела!
Про «план карьеры» — достаточно сложный вопрос, его «наскоком» не обойти. Я на конференции тестировщиков SQA Days, которая будет проходить в этом ноябре в Питере, как раз буду именно по этой теме рассказывать, про построение карьеры в тестировании. Если Вы не сможете попасть на конференцию — после этого доклад в виде слайд-каста будет выложен в сети.
Вкратце, из выделенного Вами: п.1 нужен и необходим, а остальные определяют Вашу специализацию. Если Вы коммуникатор, то автоматизация для Вас врядли будет очень интересной ;-) Коммуникаций в тест-дизайне значительно больше, да и творчества, на мой взгляд, тоже. :)
Самая лучшая книга по тест-дизайну — Lee Copeland, 'Guide to Software Test Design'. Она на русский никогда не переводилась, но написана на очень простом английском. ОЧЕНЬ рекомендую!
Спасибо, что так написали про тестирование — всегда очень приятно видеть в этой сфере фанатов своего дела!
Про «план карьеры» — достаточно сложный вопрос, его «наскоком» не обойти. Я на конференции тестировщиков SQA Days, которая будет проходить в этом ноябре в Питере, как раз буду именно по этой теме рассказывать, про построение карьеры в тестировании. Если Вы не сможете попасть на конференцию — после этого доклад в виде слайд-каста будет выложен в сети.
Вкратце, из выделенного Вами: п.1 нужен и необходим, а остальные определяют Вашу специализацию. Если Вы коммуникатор, то автоматизация для Вас врядли будет очень интересной ;-) Коммуникаций в тест-дизайне значительно больше, да и творчества, на мой взгляд, тоже. :)
Самая лучшая книга по тест-дизайну — Lee Copeland, 'Guide to Software Test Design'. Она на русский никогда не переводилась, но написана на очень простом английском. ОЧЕНЬ рекомендую!
Вместо того, чтобы откинуться в кресле и поиграть в любимые когда-то игрушки, я зачем-то иду на bugs.opera.com, чёрт возьми!
UFO just landed and posted this here
Корень зла пункт 4. Есть компании в которых тестировщик = мартышка и есть люди которые с этим смиряются. При регрессионном тестирование выполнять кейсы знаю что они просто не могли поломаться, это насилие над здравым смыслом.
}}} Кто пишет про «скучно», «рутина» и «тупая работа»?
Те кто тупо не умеют…
Цепочка проста… умеют тестировать -> учились это делать -> этому не учат в школе так что учились по собственному желанию -> значит любят это дело и жаловаться не будут…
А те кто не проф-пригоден те конечно будут жаловаться, им то пофигу на что жаловаться, лишь бы зарплата капала…
Те кто тупо не умеют…
Цепочка проста… умеют тестировать -> учились это делать -> этому не учат в школе так что учились по собственному желанию -> значит любят это дело и жаловаться не будут…
А те кто не проф-пригоден те конечно будут жаловаться, им то пофигу на что жаловаться, лишь бы зарплата капала…
Забавный факт почему-то вспомнился — программисты в основном парни (на 7-8ых максимум 1 девушка, да и то редкость), а вот QA-специалисты (a.k.a. тестировщики, тестеры) в основном девушки (ну минимум половина).
Как говорится, необъяснимо, но факт :)
Как говорится, необъяснимо, но факт :)
А ещё на конвеере девушки работают лучше. Это факт. Девушки лучше справляются с однообразной работой.
Остаётся им только позавидовать. :(
Остаётся им только позавидовать. :(
Погуглил, но не нашел пруфлинка. Можете скинуть ссылку на этот факт?
ссылка: маляры :-)
__________________________________________________
очень чувствую, что культуры тестирования у нас практически нет, инфраструктуры для подготовки тестировщиков нет, даже нет видения по учёбе-карьере тестировщика. «морковка» — и та мне не известна.
сам бывший программер, и иногда просто чувствую бессилие от отсутствия у виденных проектов стройного контроля качества: только «юзер наткнулся, обматерил — делаем».
__________________________________________________
очень чувствую, что культуры тестирования у нас практически нет, инфраструктуры для подготовки тестировщиков нет, даже нет видения по учёбе-карьере тестировщика. «морковка» — и та мне не известна.
сам бывший программер, и иногда просто чувствую бессилие от отсутствия у виденных проектов стройного контроля качества: только «юзер наткнулся, обматерил — делаем».
Как можно делать такие громкие заявления, со столь скудным опытом, да еще и фактически первым опытом работы в этой сфере?
Все верно написали. В каком-то смысле хороший тестировщик гораздо ближе по стилю мышления к хакеру, чем к программисту. В том смысле что нужно уметь «влезть в голову» к тому, кто писал продукт и догадаться, как он рассуждал и где мог ошибиться. Это уже высший пилотаж — почти реверс-инжиниринг, как это может быть скучно? :-)
наверное поэтому я не понимаю тестирования :-) у меня мозги созидательные, как и полагается программисту. соответственно не понимаю хакеров. нужны мозги, жизненная позиция аналитические — «разложить, пробить дырку. может вовсе несколько».
но так же не понимаю и админов. всё время кажется, что админ обязан быть ленивым параноиком. ленивым в смысле «всё должно быть настроено, устойчиво, безопасно, но и удобно людям, чтобы меня не дёргали». а встреченные админы не такие. они — «запарили дёргать. УНВП, БЖСЭ».
но так же не понимаю и админов. всё время кажется, что админ обязан быть ленивым параноиком. ленивым в смысле «всё должно быть настроено, устойчиво, безопасно, но и удобно людям, чтобы меня не дёргали». а встреченные админы не такие. они — «запарили дёргать. УНВП, БЖСЭ».
Безопасно, удобно, дешево. Выберите любые два :)
Поскольку бюджет обычно не резиновый, то либо безопасно, либо удобно. Вот админы и дерганные, потому что постоянно в поисках компромисса :)
Хотя это и оффтопик здесь, вероятно.
Поскольку бюджет обычно не резиновый, то либо безопасно, либо удобно. Вот админы и дерганные, потому что постоянно в поисках компромисса :)
Хотя это и оффтопик здесь, вероятно.
>но так же не понимаю и админов. всё время кажется, что админ обязан быть ленивым параноиком. ленивым в смысле «всё должно быть настроено, устойчиво, безопасно, но и удобно людям, чтобы меня не дёргали». а встреченные админы не такие. они — «запарили дёргать. УНВП, БЖСЭ».
Инстинкт самосохранения в некоторых случаях не позволяет быть «ленивым», нужно постоянно создавать имитацию деятельности, даже если у тебя «всё работает», а то могут зарплату уменьшить, допнагрузку (непрофильную) повесить, а то и вовсе сократить.
Инстинкт самосохранения в некоторых случаях не позволяет быть «ленивым», нужно постоянно создавать имитацию деятельности, даже если у тебя «всё работает», а то могут зарплату уменьшить, допнагрузку (непрофильную) повесить, а то и вовсе сократить.
Высокая концентрация мысли на определённой работе и сосредоточение может сделать любое дело интересным.
Всегда когда заходит речь о тестировщиках которые понимают чем они занимаются и любят это, вспоминается отрывок из романа Демарко «Человеческий фактор...»:
«Материал для легенд
На заре времён (скажем так) в штате Нью-Йорк существовала компания, производившая большие синие компьютеры. Компания также выпускала программное обеспечение для этих компьютеров. Клиенты компании были весьма достойными людьми, но, говоря между нами, имели обыкновение препротивно придираться к программам с ошибками. Какое-то время компания прилагала усилия к обучению клиентов, чтобы сделать их более терпимыми к ошибкам. Но из этого ничего не получилось, поэтому пришлось проглотить пилюлю и начать избавляться от ошибок.
Простой и очевидный подход – заставить программистов удалять все ошибки перед сдачей программы. Этот подход по какой-то причине тоже работал не очень хорошо. Похоже, программисты (по крайней мере, в те времена) были в целом слишком хорошего мнения о своих программах. Как они ни старались, найти все ошибки до последней не могли, поэтому часто объявляли о готовности программ, полных изъянов.
Тяжело было обнаружить последнюю ошибку, но некоторые тестеры справлялись лучше своих коллег. Компания сформировала группу из этих особо одарённых тестеров и предоставила ей право окончательного тестирования критических приложений перед отправкой их клиентам. Так родилась легендарная Чёрная Команда.
Изначально в Чёрную Команду входили люди, проявившие себя в тестировании и превосходившие в этом качестве своих коллег. У них было больше мотивации. Они тестировали также и чужой код, поэтому были свободны от когнитивного диссонанса, сковывающего разработчика при тестировании собственных программ. В конечном итоге руководители, сформировавшие команду, ожидали хотя бы скромных улучшений качества продуктов, но не более того. А вот получили они гораздо больше.
Удивительное заключалось не в том, насколько хороша была Чёрная Команда на заре своего существования, а в том, насколько она улучшилась за последующий год. Происходило что-то волшебное: в команде началось формирование индивидуальности. Эта индивидуальность находилась под влиянием оппозиционной философии тестирования, созданной участниками группы. Философия гласила, что они должны желать и ожидать недостатков в программах.
Они вовсе даже не болели за разработчиков, но напротив находили наслаждение в том, чтобы подвергнуть программу (и программиста) испытаниям, которые были бы не просто тестом. Когда программист приносил программу на тестирование в Чёрную Команду, он чувствовал себя, как на аудиенции у Мина Беспощадного[60].
Жалкие земляне, кто вам теперь поможет?
Поначалу просто ходили шутки, что тесты Чёрной Команды подлые и скверные и что участникам группы очень нравится, когда код работает неправильно. Затем шутки закончились. Члены команды начали культивировать образ разрушителей. Они разрушали не только ваш код, но и весь ваш день. Они делали нечеловечески несправедливые вещи, чтобы добиться сбоя: перегружали буферы, сравнивали пустые файлы, набирали возмутительные последовательности на клавиатуре. Взрослые мужчины и женщины начинали плакать, когда видели ужасное поведение своих программ в руках сумасшедших врагов. Чем хуже вам приходилось, тем большее удовольствие получала группа тестирования.
Чтобы усилить неприятный образ, участники команды начали носить чёрное (отсюда и название «Чёрная Команда»). Они взяли в привычку страшно фыркать, когда программа давала сбой. Некоторые отращивали длинные усы, которые крутили, подражая Саймону Легри[61].
Они собирались, чтобы придумывать ещё более ужасные тестовые уловки. Программисты начали перешёптываться о душевнобольных из Чёрной Команды.
Что и говорить, компания была в восхищении. Каждый дефект, найденный командой, клиентам уже не суждено было увидеть. Команда стала настоящей удачей. Удачей в качестве подразделения тестирования, но, что более важно для нашего изложения, в качестве социальной ячейки. Люди в команде получали такое удовольствие от своей работы, что коллеги вне команды, несомненно, завидовали им. Чёрная одежда и по-детски глупое поведение были частью этого удовольствия, но происходило здесь и кое-что ещё. Химические процессы внутри группы стали самодостаточными.»
Классно
«Материал для легенд
На заре времён (скажем так) в штате Нью-Йорк существовала компания, производившая большие синие компьютеры. Компания также выпускала программное обеспечение для этих компьютеров. Клиенты компании были весьма достойными людьми, но, говоря между нами, имели обыкновение препротивно придираться к программам с ошибками. Какое-то время компания прилагала усилия к обучению клиентов, чтобы сделать их более терпимыми к ошибкам. Но из этого ничего не получилось, поэтому пришлось проглотить пилюлю и начать избавляться от ошибок.
Простой и очевидный подход – заставить программистов удалять все ошибки перед сдачей программы. Этот подход по какой-то причине тоже работал не очень хорошо. Похоже, программисты (по крайней мере, в те времена) были в целом слишком хорошего мнения о своих программах. Как они ни старались, найти все ошибки до последней не могли, поэтому часто объявляли о готовности программ, полных изъянов.
Тяжело было обнаружить последнюю ошибку, но некоторые тестеры справлялись лучше своих коллег. Компания сформировала группу из этих особо одарённых тестеров и предоставила ей право окончательного тестирования критических приложений перед отправкой их клиентам. Так родилась легендарная Чёрная Команда.
Изначально в Чёрную Команду входили люди, проявившие себя в тестировании и превосходившие в этом качестве своих коллег. У них было больше мотивации. Они тестировали также и чужой код, поэтому были свободны от когнитивного диссонанса, сковывающего разработчика при тестировании собственных программ. В конечном итоге руководители, сформировавшие команду, ожидали хотя бы скромных улучшений качества продуктов, но не более того. А вот получили они гораздо больше.
Удивительное заключалось не в том, насколько хороша была Чёрная Команда на заре своего существования, а в том, насколько она улучшилась за последующий год. Происходило что-то волшебное: в команде началось формирование индивидуальности. Эта индивидуальность находилась под влиянием оппозиционной философии тестирования, созданной участниками группы. Философия гласила, что они должны желать и ожидать недостатков в программах.
Они вовсе даже не болели за разработчиков, но напротив находили наслаждение в том, чтобы подвергнуть программу (и программиста) испытаниям, которые были бы не просто тестом. Когда программист приносил программу на тестирование в Чёрную Команду, он чувствовал себя, как на аудиенции у Мина Беспощадного[60].
Жалкие земляне, кто вам теперь поможет?
Поначалу просто ходили шутки, что тесты Чёрной Команды подлые и скверные и что участникам группы очень нравится, когда код работает неправильно. Затем шутки закончились. Члены команды начали культивировать образ разрушителей. Они разрушали не только ваш код, но и весь ваш день. Они делали нечеловечески несправедливые вещи, чтобы добиться сбоя: перегружали буферы, сравнивали пустые файлы, набирали возмутительные последовательности на клавиатуре. Взрослые мужчины и женщины начинали плакать, когда видели ужасное поведение своих программ в руках сумасшедших врагов. Чем хуже вам приходилось, тем большее удовольствие получала группа тестирования.
Чтобы усилить неприятный образ, участники команды начали носить чёрное (отсюда и название «Чёрная Команда»). Они взяли в привычку страшно фыркать, когда программа давала сбой. Некоторые отращивали длинные усы, которые крутили, подражая Саймону Легри[61].
Они собирались, чтобы придумывать ещё более ужасные тестовые уловки. Программисты начали перешёптываться о душевнобольных из Чёрной Команды.
Что и говорить, компания была в восхищении. Каждый дефект, найденный командой, клиентам уже не суждено было увидеть. Команда стала настоящей удачей. Удачей в качестве подразделения тестирования, но, что более важно для нашего изложения, в качестве социальной ячейки. Люди в команде получали такое удовольствие от своей работы, что коллеги вне команды, несомненно, завидовали им. Чёрная одежда и по-детски глупое поведение были частью этого удовольствия, но происходило здесь и кое-что ещё. Химические процессы внутри группы стали самодостаточными.»
Классно
Супер!
Ну раз уж дошло дело до литературы, то можно вспомнить и рассказ «Идеальный тестер».
>>Чем хуже вам приходилось, тем большее удовольствие получала группа тестирования.
Чет мне это не нравится, к сожалению за совсем большие компании говорить не могу, а вот в небольших такие отношения тестировщик-разработчик это жопа.
Разработчики будут тянуть с релизом, просто по тому, что «перед смертью не надышишься». Будут тратить необоснованно много времени на вылизывание кода, необоснованно это когда с вероятность самостоятельно найти баг 1-2% все остальное вычищено и в процессе исправления наделано новых(и вообще ушел в рекурсию). Или наоборот, вообще забьют на проверку работоспособности, «а нах. все равно тестеры зае***».
Не здоровые отношение. Намного лучше, когда после банки пива разработчик Вася будет добадываться до тестировщика Пети, с требованиям сказать в какой области идут его основные косяки. А Вася в свою очередь пойдет к Пети с просьбой «подточить» автомат для Сели, бо он точно знает, что Пети не в западло и он как программист может помочь.
Чет мне это не нравится, к сожалению за совсем большие компании говорить не могу, а вот в небольших такие отношения тестировщик-разработчик это жопа.
Разработчики будут тянуть с релизом, просто по тому, что «перед смертью не надышишься». Будут тратить необоснованно много времени на вылизывание кода, необоснованно это когда с вероятность самостоятельно найти баг 1-2% все остальное вычищено и в процессе исправления наделано новых(и вообще ушел в рекурсию). Или наоборот, вообще забьют на проверку работоспособности, «а нах. все равно тестеры зае***».
Не здоровые отношение. Намного лучше, когда после банки пива разработчик Вася будет добадываться до тестировщика Пети, с требованиям сказать в какой области идут его основные косяки. А Вася в свою очередь пойдет к Пети с просьбой «подточить» автомат для Сели, бо он точно знает, что Пети не в западло и он как программист может помочь.
И правильно, что не нравится.
«Черная команда» возникла в те времена, когда тестирование было чем-то вынужденным, непреднамеренным. В тестировщики «ссылали» программистов, потому что «надо, Федя», больше некому было. Простой человек не мог работать с компьютером, а уж тестировать, рассуждая, что и как должно работать, и что можно проверить…
И негативное отношение к тестировщикам, в общем, родом оттуда.
Парни из «черной команды» все сделали правильно для того времени и окружения. Типа, если вы нас не хотите, то и мы в вас не особо нуждаемся. Проливайте же слезы, смерды! И понеслось…
Сегодня подобное отношение все еще культивируется в малых компаниях, где тестировщиков берут в проект на поздних стадиях, когда манагеры и сами программисты задолбались перепроверять одно и то же, и находить одни и те же «старые» баги снова и снова. Всем уже плохо, а тут еще появляется молодой энтузиаст, который считает доблестью отчитываться по количеству найденных багов :)
А может, и не считает, но ему говорят «Ты, Вася, вчера нашел 12 багов, а сегодня только пять. Нехорошооооо, ленишься. Очень нехорошо».
Вот Вася и старается соответствовать. Нормальное человеческое поведение.
«Черная команда» возникла в те времена, когда тестирование было чем-то вынужденным, непреднамеренным. В тестировщики «ссылали» программистов, потому что «надо, Федя», больше некому было. Простой человек не мог работать с компьютером, а уж тестировать, рассуждая, что и как должно работать, и что можно проверить…
И негативное отношение к тестировщикам, в общем, родом оттуда.
Парни из «черной команды» все сделали правильно для того времени и окружения. Типа, если вы нас не хотите, то и мы в вас не особо нуждаемся. Проливайте же слезы, смерды! И понеслось…
Сегодня подобное отношение все еще культивируется в малых компаниях, где тестировщиков берут в проект на поздних стадиях, когда манагеры и сами программисты задолбались перепроверять одно и то же, и находить одни и те же «старые» баги снова и снова. Всем уже плохо, а тут еще появляется молодой энтузиаст, который считает доблестью отчитываться по количеству найденных багов :)
А может, и не считает, но ему говорят «Ты, Вася, вчера нашел 12 багов, а сегодня только пять. Нехорошооооо, ленишься. Очень нехорошо».
Вот Вася и старается соответствовать. Нормальное человеческое поведение.
ну так и что дальше случилось с этой «Чёрной командой »?
программисты наняли киллеров и всех выловили или как :)?
программисты наняли киллеров и всех выловили или как :)?
Прияно, когда в своей компании есть люди, которые понимают как важно тестирование. НО у нас есть куда стремиться, не так ли? :)
напишите, пожалуйста, статью об упомянутой «методологии тестирования».
где именно в нём творчество, где именно автоматизация.
а то вт тут даже в комментах некотрые считают, что тестирование это расставление ассертов или запуск юниттестов.
а другие вообще не понимают, как можно автоматизировать этот процесс.
привет.
где именно в нём творчество, где именно автоматизация.
а то вт тут даже в комментах некотрые считают, что тестирование это расставление ассертов или запуск юниттестов.
а другие вообще не понимают, как можно автоматизировать этот процесс.
привет.
Не понял о чем статья. Кому-то нравится готовить, кому-то не нравится готовить. Кто-то любит занятие N, кто-то находит его скучным. Что в этом особенного?
Люди вынуждены заниматься скучными вещами, не потому, что они хотят этим заниматься, а потому что вынуждены. Для вас тестирование не скучно, замечательно, тестируйте на здоровье. Я заглянул в статью надеясь, что она подскажет мне, как избежать тестирования, или даст еще несколько весомых аргументов, за то, чтобы не тестировать, а в итоге статья мне предлагает первый пункт «Не моё», спасибо К.О.
Люди вынуждены заниматься скучными вещами, не потому, что они хотят этим заниматься, а потому что вынуждены. Для вас тестирование не скучно, замечательно, тестируйте на здоровье. Я заглянул в статью надеясь, что она подскажет мне, как избежать тестирования, или даст еще несколько весомых аргументов, за то, чтобы не тестировать, а в итоге статья мне предлагает первый пункт «Не моё», спасибо К.О.
Сколько же может длится этот спор?
одни говорят, что тестирование — скучно, нудно, для тупых…
другие, что наоборот.
Сам работаю в тестировании и непонимаю тех кто, работая тестировщиком, начинает оправдываться и как-бы извиняться за то, что он занимается такой работой.
Извините, но это выглядет именно так.
Когда то и я грешил этим :)
Если такая отрасль как тестирование появилась и развивается, значит она нужна, значит это круто.
одни говорят, что тестирование — скучно, нудно, для тупых…
другие, что наоборот.
Сам работаю в тестировании и непонимаю тех кто, работая тестировщиком, начинает оправдываться и как-бы извиняться за то, что он занимается такой работой.
Извините, но это выглядет именно так.
Когда то и я грешил этим :)
Если такая отрасль как тестирование появилась и развивается, значит она нужна, значит это круто.
а некоторые программеры копипастят, это тоже порой тупо, скучно и нудно.
Программисты не могут писать без багов, даже самые крутые синьёры,
а кто же должен эти баги зарепортить и недопустить их в продакшен -конечно же тестировщик
Программеры не могут без тестировщиков, а тестировщики б не получали работу без программеров.
Они все в одной лодке.
Программисты не могут писать без багов, даже самые крутые синьёры,
а кто же должен эти баги зарепортить и недопустить их в продакшен -конечно же тестировщик
Программеры не могут без тестировщиков, а тестировщики б не получали работу без программеров.
Они все в одной лодке.
Очень классный комментарий. Все холливары между тестерами и программерами происходят именно потому, что не все это понимают. Мы в одной лодке, и друг без друга никуда!
Работа строится эффективно только если все участники понимают взаимозависимость своих работ.
Работа строится эффективно только если все участники понимают взаимозависимость своих работ.
вот когда все участники команды понимают это то и работа становится продуктивнее и качественнее.
Всё это говорю из своего личного опыта.
Всё это говорю из своего личного опыта.
Все холливары между всеми и всеми начинаются либо в шутку (посмеяться) либо (если стороны серьёзно уверены что пишут умные вещи) от отсутствия мозгов.
Если тестировщики и программеры работают с умом, то и холиваров у них нет (есть прикольные холиварчики чтоб народ посмешить да самим посмеяться, но не более)
Если тестировщики и программеры работают с умом, то и холиваров у них нет (есть прикольные холиварчики чтоб народ посмешить да самим посмеяться, но не более)
«Выносил я как-то мусорный бак. Замерз. Опрокинул его метра за три до помойки. Минут через пятнадцать к нам явился дворник. Устроил скандал. Выяснилось, что он по мусору легко устанавливает жильца и номер квартиры.
В любой работе есть место творчеству.»
С.Довлатов «Соло на ундервуде»
В любой работе есть место творчеству.»
С.Довлатов «Соло на ундервуде»
Незнаю, может я и не дорос до такого уровня, чтобы привлекать к своим проектам тестера, но для меня эта профессия, пока что, не только нудная и скучная, но и бредовая. Решил поковырятся в инструментах тестирования Appium, Selenium и, знаете, более неоднозначных и бредовых вещей я в жизни не изучал, причем по тратам времени это конкурирует с количеством времени на саму разработку. Может, когда-нибудь, поменяю свое мнение, но пока это так
Sign up to leave a comment.
Почему тестирование — это тупо и скучно?