Решила пойти по горячим следам и оставлять отзывы сразу, а не после всего курса. Пока еще воспоминания свежи. Иначе в конце отчет будет довольно короткий, все ведь не упомнишь.
Так что, если вы еще размышляете, идти ли вам на эти курсы... Добавлю свое мнение к остальным!
Итак, встал вопрос об автоматизации тестирования. Дано добро на курсы, когда мы выберем инструмент. Я нашла себе курсы на специалисте, где автоматизации учат в два этапа, на первом даются основы программирования. Вот эти
Свыше их забраковали:
Скачала себе триалку Тесткомплита и стала думать дальше.
Следующее предложение было уже о тренинге Алексей Баранцева.
Что помогло обосновать? Как раз таки отзывы уже прошедших ))) В которых упоминается домашнее задание, без которого в обучении - никуда. Плюс мое собственное мнение об Алексее как о хорошем докладчике (как раз прошла первая ConfeT&QA)
А вот программисты этот курс обсмеяли, на заметку Алексею, почитав расписание, вердикт был примерно такой же, как в цитате выше - "Первые два занятия вообще вода, лучше книжку почитай". Слова "А пока мы просто научимся решать конкретные практические задачи.
" не очень спасли, оставив ложное мнение о первых уроках.
И вот я участник данного курса :)
До его запуска я успела определиться таки с программой для автоматизации (мой выбор - Watin), и даже написать код. С помощью программиста мы написали тест, потом отрефакторили, потом вообще стерли и переписали )))
Однако что-то усвоить я уже успела. Поэтому первые два занятия мне были более-менее знакомы. И до разделения тестов и UI модельки (так она называется у меня, часть автоматизатора) мы дошли. И до принципа устойчивости тестов.
Формат обучения, если кто-то еще не в теме - просмотр записи вебинара с прошлых курсов. А то меня сильно удивил первый урок, во-первых, я невнимательно прочитала о том, что будут выкладываться записи и настроилась на то, что в понедельник в 5 будет вебинар. Даже время осводила.
А тут - курс прислали в пятницу. Сразу началась паника - это что мне, дз до понедельника надо сделать?!!!
Поняв, что время есть до четверга, поуспокоилась и включила запись. Сбивают с мыслей напоминания о том, что "консультации у нас во вторник", хотя у нас то консультации в четверг)))) Но это в принципе, только на первом занятии удивляет или напрягает. Потом привыкнешь.Зато приятно то, что всегда можно будет вернуться к какому-нибудь уроку. Особенно если понадобится перейти на селениум, а я уже все забуду)))
Первые 4 домашних задания не представили особой сложности. По крайней мере, мне не пришлось рыскать по интернету в поисках ответа на какой-то вопрос, а я читала об этом в других отзывах. Видимо, это еще предстоит!
Но ведь не зря люди ходят на семинары по темам, в которых они и так уже эксперты - всегда можно вынести какую-то новую мысль или идею.
В автоматизаци я далеко не эксперт, так что мысли вынесла. Правда, не прям на занятии, на занятии я как раз думала о том, что это мне, в принципе, уже знакомо, я это делала, просто в другом фреймворке.
А вот когда вернулась к своей работе, вынесенные знания мне очень помогли! Просто знайте - даже если вам ДЗ показались легкими, попробуйте заавтоматизировать свое приложение. Без практики не возникнут вопросы! А они возникнут ))))
Итак, сегодня у меня наконец-то нашлось время снова заняться своими автотестами. В последний раз я размышляла, как мне обращаться к разным страницам. Так-то я с подсказками программиста код писала, а тут решила начать новую ветку, чтобы закрепить свои знания.
И после второго урока я поняла, что мне надо удалить нафиг те новые классы, которые я уже успела создать, и вместо них сделать один - "Навигация". Ну конечно! Это же элементарно, Вадсон (с)
Вдохновленная новой идеей, взяла ручку и бумагу и накидала свои мысли туда. Потом уже перенесла в MindMap. Одобрение "рукописи" я, кстати, получила в одной любопытной книжке, о которой я напишу потом, когда прочитаю :)) Пока я вытащила оттуда мысль "сначала нарисуйте свою презентацию на бумаге, а потом беритесь за компьютер. Конечно, многие скажут, что проще делать сразу в PowerPoint, и это бессмысленная трата времени. Но с помощью карандаша и бумаги вы сможете сгенерировать большое количество идей за небольшой период времени, не отвлекаясь на манипуляции с мышью и клавиатурой"
Перенести мысли в компьютер самостоятельно я, однако, не смогла ))))
Тут же всплыла куча вопросов, пришлось опять прибегнуть к помощи программистов.
Но, по крайней мере, я уже знаю, какая у меня будет структура кода, и я вижу косяки в моем старом коде, я вижу то, что пора менять, пока не стало слишком поздно :)))
Тут и вылез новый вопрос. Есть код:
Так и пригодилось первое же занятие. Спасибо рефакторингу! Что бы мы без него делали))))
Очень жду 5 занятия, так как вопрос записи в файл меня мучается уже больше двух недель. И также надеюсь, что еще до этого занятия я научусь с этим работать, а потом сравню методы - свой и Алексея, вытащу идеи, до которых не дошла сама)
Так что, если вы еще размышляете, идти ли вам на эти курсы... Добавлю свое мнение к остальным!
Итак, встал вопрос об автоматизации тестирования. Дано добро на курсы, когда мы выберем инструмент. Я нашла себе курсы на специалисте, где автоматизации учат в два этапа, на первом даются основы программирования. Вот эти
Свыше их забраковали:
Основы программирования и баз данных - полная чухняХотя я нашла много незнакомых слов в описании основ программирования :)) Ну ладно.
Во-первых, Ольга, эти вещи должны были читать в бауманке на первом-втором курсах (кроме запросов SQL)
Во-вторых, тебе это точно не нужно для тестирования.
Обзорные знание методологий, языков и структур данных тебе никак не поможет.
Мое мнение - этот курс отметаем.
Скачала себе триалку Тесткомплита и стала думать дальше.
Следующее предложение было уже о тренинге Алексей Баранцева.
Что помогло обосновать? Как раз таки отзывы уже прошедших ))) В которых упоминается домашнее задание, без которого в обучении - никуда. Плюс мое собственное мнение об Алексее как о хорошем докладчике (как раз прошла первая ConfeT&QA)
А вот программисты этот курс обсмеяли, на заметку Алексею, почитав расписание, вердикт был примерно такой же, как в цитате выше - "Первые два занятия вообще вода, лучше книжку почитай". Слова "А пока мы просто научимся решать конкретные практические задачи.
" не очень спасли, оставив ложное мнение о первых уроках.
И вот я участник данного курса :)
До его запуска я успела определиться таки с программой для автоматизации (мой выбор - Watin), и даже написать код. С помощью программиста мы написали тест, потом отрефакторили, потом вообще стерли и переписали )))
Однако что-то усвоить я уже успела. Поэтому первые два занятия мне были более-менее знакомы. И до разделения тестов и UI модельки (так она называется у меня, часть автоматизатора) мы дошли. И до принципа устойчивости тестов.
Формат обучения, если кто-то еще не в теме - просмотр записи вебинара с прошлых курсов. А то меня сильно удивил первый урок, во-первых, я невнимательно прочитала о том, что будут выкладываться записи и настроилась на то, что в понедельник в 5 будет вебинар. Даже время осводила.
А тут - курс прислали в пятницу. Сразу началась паника - это что мне, дз до понедельника надо сделать?!!!
Поняв, что время есть до четверга, поуспокоилась и включила запись. Сбивают с мыслей напоминания о том, что "консультации у нас во вторник", хотя у нас то консультации в четверг)))) Но это в принципе, только на первом занятии удивляет или напрягает. Потом привыкнешь.Зато приятно то, что всегда можно будет вернуться к какому-нибудь уроку. Особенно если понадобится перейти на селениум, а я уже все забуду)))
Первые 4 домашних задания не представили особой сложности. По крайней мере, мне не пришлось рыскать по интернету в поисках ответа на какой-то вопрос, а я читала об этом в других отзывах. Видимо, это еще предстоит!
Но ведь не зря люди ходят на семинары по темам, в которых они и так уже эксперты - всегда можно вынести какую-то новую мысль или идею.
В автоматизаци я далеко не эксперт, так что мысли вынесла. Правда, не прям на занятии, на занятии я как раз думала о том, что это мне, в принципе, уже знакомо, я это делала, просто в другом фреймворке.
А вот когда вернулась к своей работе, вынесенные знания мне очень помогли! Просто знайте - даже если вам ДЗ показались легкими, попробуйте заавтоматизировать свое приложение. Без практики не возникнут вопросы! А они возникнут ))))
Итак, сегодня у меня наконец-то нашлось время снова заняться своими автотестами. В последний раз я размышляла, как мне обращаться к разным страницам. Так-то я с подсказками программиста код писала, а тут решила начать новую ветку, чтобы закрепить свои знания.
И после второго урока я поняла, что мне надо удалить нафиг те новые классы, которые я уже успела создать, и вместо них сделать один - "Навигация". Ну конечно! Это же элементарно, Вадсон (с)
Вдохновленная новой идеей, взяла ручку и бумагу и накидала свои мысли туда. Потом уже перенесла в MindMap. Одобрение "рукописи" я, кстати, получила в одной любопытной книжке, о которой я напишу потом, когда прочитаю :)) Пока я вытащила оттуда мысль "сначала нарисуйте свою презентацию на бумаге, а потом беритесь за компьютер. Конечно, многие скажут, что проще делать сразу в PowerPoint, и это бессмысленная трата времени. Но с помощью карандаша и бумаги вы сможете сгенерировать большое количество идей за небольшой период времени, не отвлекаясь на манипуляции с мышью и клавиатурой"
Перенести мысли в компьютер самостоятельно я, однако, не смогла ))))
Тут же всплыла куча вопросов, пришлось опять прибегнуть к помощи программистов.
Но, по крайней мере, я уже знаю, какая у меня будет структура кода, и я вижу косяки в моем старом коде, я вижу то, что пора менять, пока не стало слишком поздно :)))
Тут и вылез новый вопрос. Есть код:
private Div ГоризонтальноеМеню()
{
var div = Browser.Div(Find.BySelector("#id"));
return div;
}
public void ПереходимВМодуль()
{
var div = ГоризонтальноеМеню();
div.Span(s => s.Text.Equals("НазваниеМодуля")).Click();
}
Но первая строка с div - это повторяющийся код, с него можно в несколько мест попасть. А если его id изменится? Везде менять?
А как достать? Ведь если мы вытащим var, сможем ли мы к нему обратиться? И как??
В сомнении я выделила эту строку и нажала волшебную комбинацию, на которую указал Алексей еще в первом занятии: Рефактор - Excract Metod. И получила такой же гениальный по простоте ответ:
public void ПереходимВМодуль()
{
var div = Browser.Div(Find.BySelector("#id"));
div.Span(s => s.Text.Equals("НазваниеМодуля")).Click();
}
Сама бы я долго думала, как же это написать))))Так и пригодилось первое же занятие. Спасибо рефакторингу! Что бы мы без него делали))))
Очень жду 5 занятия, так как вопрос записи в файл меня мучается уже больше двух недель. И также надеюсь, что еще до этого занятия я научусь с этим работать, а потом сравню методы - свой и Алексея, вытащу идеи, до которых не дошла сама)
Жесть, неужели вы не понимаете, что тестировщик так и не научится программировать? Да оно и не нужно никому. Это попросту невыгодно как финансово так и с точки зрения качества кода. Разработчики педалят ежедневно несколько лет чтобы писать качественный код, который легко поддерживать. А тестировщик будет это совмещать с тестированием. :) Послушайте моего совета - сосредоточьтесь на тестировании. Оставьте программирование программистам. :)
ОтветитьУдалитьА тестировщику и не нужно программировать как правило. С другой стороны фигачить скрипты это уже, как правило, зверская экономия времени (в ручную переборы миллионов строк делать сложно). Это просто отличный инструментарий, как LaTeX, фактически, только с уклоном в специфику тестирования.
ОтветитьУдалитьПравда фигачить скрипты на жабе или в шарпах это особое извращение.
С другой стороны автоматизация тестирования (unit-api-gui тесты) в большинстве своем самое натуральное программирование и есть. Жаль только, что не все это понимают. Отсюда мы имеем монструозные наборы тестов на которые без слез не посмотреть и кучу других неприятных артефактов. "Паттерны? Какие паттерны? Я знаю только Page Objects, остального нам не надо" (с)
А вот это уже совсем не выгодно экономически, т.к. написание автоматических тестов неквалифицированным персоналом это как софт от студентов-первокурсников второй раз в жизни схватившихся за клавиатуру - бессмысленный и беспощадный.
Mikalai Alimenkou
ОтветитьУдалитьДа, действительно! Срочно отменяем все курсы, увольняем нафиг всех автоматизаторов и набираем вместо них программистов. И как же мы раньше то не догадались?
Я вас вообще не понимаю, в блоге о ручной работе вы мне советуете автоматизировать (записывать скрипты, признавая, что записи рекордером недостаточно), в блоге автоматизации вы мне предлагаете срочно бросать это дело о_О
При чем тут вообще программирование? Я учусь автоматизировать, а не программировать. Почувствуйте разницу. Даже написав кучу кода, я не смогу написать код, который создаст веб-страницу без дополнительного изучения. Потому что я не программирую, я беру уже написанный код...
К тому же "Жесть, неужели вы не понимаете, что тестировщик так и не научится программировать?" - что за бред? Некоторые вообще тестировщиками идут просто потому, что хотели в определенную компанию, а программисты туда были не нужны, потом доросли до программиста. Некоторые начинают с тестирования, но потом переходят в программисты.
И я точно также могу пойти на вашу презентацию "а мы работаем без тестировщиков" и написать коммент "жесть, неужели вы не понимаете, что программист так и не научится тестировать? Грамотному тест-дизайну некоторые учатся очень долго, а программист будет совмещать это с написанием нового кода и исправлением старого? :) Смешно же".
На то и нужны разделения ролей. Заставлять программистов тестировать - это та же потеря времени. Хороший программист за время, которое он провел в рамках тестирования, весьма посредственного, мог бы написать кусок полезного и грамотного кода. Только давайте не будем рассказывать сказки о том, что программисты с 10-летним стажем пишут ну такой прекрасный код, который полностью покрывается юнит-тестами и в нем больше нет ошибок.
По вашему мнению, видимо, вообще при поиске работы тестировщиком надо отметать все компании с предложениями о работе "при наличии знаний основ программирования", как глупые и нелепые. "И как они не понимаю, что это не работа тестировщиков?"
Тем не менее, тестировщики участся автоматизации. По собственной инициативе или по настоянию руководства. Но им это надо. И чтобы они могли выбрать, на какие именно курсы им идти, и написан мой отзыв.
Разумеется, я не собираюсь посещать все-все-все курсы программирования для написания отчета новичкам. Но, я напишу отзыв на курс, на котором была я, на другой напишут те, кто был там. А тот, кто будет потом искать, сможет почитать про оба и сделать выводы для себя.
Собственно, комментарий на курс автоматизаторов. Если его будут читать - его будут читать именно люди, которые УЖЕ РЕШИЛИ, что им это для чего-то надо (ну и пока блог "свежий", его, конечно, прочитают и те, кто читает обновления в блогах, но потом - уже с конкретной целью, узнать мнение о курсе).
А раз они решили, я сильно сомневаюсь, что после вашего комментария они прозреют и пойдут говорить руководству, что это плохая затея, давайте мы лучше программистов заставим тесты писать))
То Сергей Высоцкий: все с чего то начинают... Разумеется, первый блин комом, но с опытом все придет))
Намного хуже, имхо, когда человек сидит на попе ровно, даже не пытаясь что-то сделать, потому что "у меня с 1 раза не получится"...
Не надо никого увольнять. :) Я постараюсь пояснить, что я имел ввиду. Для автоматизации тестирования вам не нужно особо уметь программировать и тратить время на обучение этому.
ОтветитьУдалитьНапример, понадобилось вам список объектов из базы достать. Вы можете корячиться, разыскивать в инете как это сделать, найти корявый пример и переписать его под свои нужны за несколько часов. А можете попросить сделать это за 5-10 минут программиста (именно за столько, потому что для него это примитивная операция). Ну или хотя бы рассказать в деталях и потом проверить. Или нужно вам файлик прочитать и на строки его разбить. Ох вы можете и напрограммировать в этой простой задаче. Но грамотный разработчик знает как это сделать одной функцией сторонней библиотечки. И это опять дело пары минут.
Почему я люблю инструменты для автоматизации, основанные на принципе словарей команд (FitNesse, Concordion, Cucumber и прочие). В них вы пишете тесты, оперируя набором понятных команд. Вы можете дополнять набор, изменять параметры команд, но у вас нет доступа к реализации этих команд. А реализуют их быстро и эффективно люди, которые умеют это делать (программисты или редко встречающиеся программисты-тестировщики). И все живут в счастье и гармонии, занимаясь каждый своим делом.
Теперь коснемся тестрировщиков, которые временно работали ими пока не было работы программиста. Да у них же мышление и навыки совершенно другие. Это самый ядовитый случай из всех, когда человек совершенно не на своем месте и ждет пока "дорастет" до разработчика. Как вы думаете, будет ли он вкладывать себя в тестирование? Нет конечно! Зачем ему это? Это то же самое, что нанять маникюрщицу, которая потом "дорастет" до парихмахера. Или верить, что яблоко в лимон превратится, когда лимоны закончатся.
Программист так и не научится смотреть со стороны на написанный код. Не научится, так природа устроила. Ему помогает TDD на уровне разработки классов, чтобы маленькими шажками двигаться и не пропустить ошибку. А в глобальном плане ему тяжело. Именно поэтому мне и жалко тратить время тестировщика на программирование, когда для меня огромнейшая польза от него в другом месте.
Полностью покрытый модульными тестами код не обязательно без ошибок. Попросту потому, что разработчик склонен пропускать некоторые логические сценарии (в основном негативные), а значит просто не иметь их ввиду. Вот тут то вы и нужны со своей помощью. Но технических ошибок у опытного разработчика, работающего по TDD, очень мало.
А вот по поводу отметания всех компаний с предложениями о работе "при наличии знаний основ программирования" вы в точку. Не то чтобы отметать, но относиться с недоверием. Я много занимался наймом сотрудников и видел как в проект ищут тестировщика с невероятными требованиями к программированию. В итоге искали очень долго, платили очень много, получали "звезд". Зачем???
Автоматизировать нужно, но при этом программировать необязательно.
Понятное дело, что когда тебе надо один раз достать список объектов из базы, то проще попросить программиста помочь.
ОтветитьУдалитьА если тебе каждый день надо доставать, чуть-чуть что-то меняя, каждый день программиста дергать?
Для того и ведутся расчеты, а выгодна ли вообще автоматизация. Насколько она эффективна? Не проще ли проверить руками?
Заавтоматизировать все регрессионное тестирование, это вам не на 5 минут, даже для клевого разработчика. Даже если тестировщик сядет и опишет тесты, какими он хочет их видеть, останется "всего лишь" создать нужные классы. Только сколько времени это займет? Стоит ли тратить силы программиста на это?
Тестировщик вполне способен совмещать ручное тестирование с автоматизацией. Это не значит, что он круто кодит. Но это также и не значит, что программист вместо кода сидит и пишет тесты, которые вполне способен написать тестировщик.
И опять же, нужна автоматизация или нет, это вообще не для этого сообщения блога, здесь мы берем за аксиому, что она нам нужна, и "едем дальше" - выбираем курсы для изучения :)
@Mikalai Alimenkou:
ОтветитьУдалитьНе смотря на то что в целом я согласен, что тестировщику совем не обязательно уметь программировать есть ряд ньюансов.
1. "Обратиться к программисту" это плохая задача. Потому что обращаться придется регулярно и много. И программист врятли поймет как сделать много хелперов и т.п. с первого раза, если у него небыло какого-то опыта автоматизации ранее. Можно сразу или перевесить все задачи по тестированию интерфейсов на разработчиков ("код тестов это код продакшена, это общий код" и прочая прочая, читать технобложик etsy или слушать Саймона Стюарта с GTAC 2011), или попилить все (читай BDD). Тут переходим ко второму пункту.
2. BDD нормальное средство, но с весьма узкой применимостью. Т.к. выразительные средства того языка, который в итоге получается, весьма ограниченные и в ряде случаев, когда BDD валится, валится он потому, что в эти ограничения уперлись. В итоге приходится или бороться с ограничениями BDD (что плохо) или оставить в BDD то что туда влазит и другие задачи тестирования решать другими способами (что хорошо).
3. Автоматизация тестирования (в идеале все же) это не только разработка автоматических GUI/API тестов, но и производство инструментов для облегчения ручного труда (генераторы данных, тестовые клиенты под интерфейсы и прочая прочая), обеспечение Testability, опять же. Google и Microsoft решили эту проблему таким явлением как SDET. Т.е. программистами, которые заняты работой вокруг тестирования. Заниматься чем-то еще, как правило, при этом не получается.
Это все автоматизация. Там нужно программировать, причем часто хорошо бы чтобы этим занимался человек хоть что-то понимающий в программировании. А вот тестировать там нужно очень мало. Достаточно того чтобы ваши тестировщики научились формулировать требования (а с этим очень плохо, как правило).
Да, есть такие артефакты как нагрузки, MBT и прочая деятельность, где нужны люди умеющие программировать, тестировать и много всего еще (в основном математика, да), но на постсоветском пространстве эти люди нужны далеко не всем.
@okiseleva:
ОтветитьУдалитьРасчеты того нужна ли вам автоматизация это профанация чистой воды. Это примерно как считать выгоду от TDD. Прямо никак не получится. Слишком много косвенной выгоды. Более того - автоматизация это продукт. Считать ROI продукта пока его нет могут многие, но вот успешных SW продуктов пока сильно меньше 100%.
"Заавтоматизировать все регрессионное тестирование" это как правило тоже бесполезное занятие. Все не получится. Дальше вопрос качества и целесообразности конкретного регрессионного тестирования. Часто можно урезать в 2-3 раза набор регрессионных тестов и ничего не изменится.
Единственное полезное для тестировщика программирование которое я знаю - everyday scripting. Учите ruby, учите shell, учите python и тысячи других скриптовых средств. Там выгода как правило очевидна. Но это не та автоматизация о которой говорят на постсоветском пространстве как об автоматизации.
Ну и еще раз - уметь читать код полезно, да. Просто потому что это еще один источник информации о приложении. Но тут хорошие коммуникации с разработчиками могут все заменить. А вот писать совсем не обязательно.
"Учите ruby, учите shell, учите python и тысячи других скриптовых средств. "
ОтветитьУдалитьСергей, ну вы же понимаете, что эти слова включают в себя очень долгий процесс :)
Я же говорю о том, что нужно мне здесь и сейчас. Не вижу выгоды руби перед Си шарпом, не могу придумать, что конкретно мне повесить на shell, ведь мне в нем придется долго разбираться, стоит ли оно того?
Если просто для саморазвития, то "в очередь", мне есть что почитать - поизучать, ну и отдыхать тоже когда-то надо, так и до выгорания недалеко
Я таки ещё немного подолью масла в огонь :)
ОтветитьУдалитьВо-первых, Николай, мне кажется, что Вы ущемляете права тестировщиков :) Позвольте людям (как лично тестировщикам, так и их работодателям) самостоятельно принимать решения о том, что им следует знать и уметь, а чего не следует. "Вам этого знать не положено, потому что вы тестировщики!" -- лично я такую позицию категорически неприемлю.
Есть софт, и есть софт, и тестировать его надо по разному. Есть тестировщики, и есть тестировщики, и хорошо, что некоторые из них умеют программировать, а некоторые не умеют.
Во-вторых, уметь программировать полезно вообще, не только в контексте автоматизации выполнения тестов, как верно отметил Сергей. Написать несложный генератор данных, парсер логов, генератор отчётов, эмулятор или заглушку, автоматизировать инсталляцию и/или подготовку тестового окружения и так далее и так далее.
Если это действительно занимает пять минут работы -- неужели нужно постоянно отвлекать программиста (который наверняка не бездельничает) для этого? Ну раз, два, три -- но потом он скажет "слушай, ты что сам не можешь это сделать? ведь это же совсем просто!" И его можно понять.
Кстати, Вы были когда-нибудь в роли тестировщика, который приходит к программисту с подобной просьбой? Попробуйте как-нибудь, прежде чем такие советы давать :)
В-третьих, действительно некоторые работают тестировщиками просто потому, что так проще "зацепиться", ниже квалификационные требования. И что, теперь это навсегда? Это клеймо на всю жизнь? "Тестируй, нефиг учиться программировать! Тебе это не нужно!"
Нет, нет и нет! Пусть люди повышают квалификацию, пусть те, кто хочет, уходят из тестировщиков в программисты, если им там больше нравится. Пусть! Это -- нормально!
@okiseleva
ОтветитьУдалитьПрактика показывает, что научиться скриптовому языку для ежедневного применения довольно несложно. Уж всяко проще чем на жабе или шарпах что-то дельное писать начать.
Опять же - питоний и руби имеют сильно более удобные средства для работы как с системой, так и с текстами. Парсер xml с какой-то нехитрой обработкой в скриптах делается в 4-5 строк, в шарпах в несколько десятков придется укладывать и с запуском с командной строки проблемы.
Про shell берите powershell. Он в виндовой среде очень нужен. Хотя те же unix utils это grep/cat/tail и тысячи всего.
Ну и да, языки с динамической типизацией для нужд тестирования более удобны.
ОтветитьУдалитьВы лучше подумайте зачем вам конкретно C#
Как это зачем? На нем пишут окружающие меня разработчики - всегда можно попросить помощи :)
ОтветитьУдалитьА что за жаба?))
И зачем все-таки нужен powershell? Я никак не могу придумать, что с ним сделать полезного, чего я не могу сделать ручками...
С помощью powershell можно автоматизировать то, что руками приходится делать снова и снова: скопировать 5 файлов в 6 разных мест, переименовать, сгенерировать список файлов с сегодняшней датой, создать 5 пользователей в AD, запустить программку / тест, прибить пользователей... Продолжать можно бесконечно. Надо просто понять, какие возможности инструмент дает. Зачем учить C# вы уже сказали: на нем пишут программисты. Но для рутинных операций это плохой инструмент. У программиста их довольно много (начиная от длинного списка аргументов, передающегося рантайму при запуске программы), не думаю, что у тестировщиков их меньше.
ОтветитьУдалитьВот по идее да, не меньше, но найти их для себя я пока не могу. Доступа в AD у меня нет...
ОтветитьУдалитьВот файлы разве что генерить, если нельзя будет в имени повторяться...
А остальные действия у меня не рутинные, автоматизировать их дороже, чем сделать руками
@okiseleva
ОтветитьУдалить"На нем пишут мои разработчики" это плохой аргумент. Я как-нибудь соберусь и напишу почему. Правда-правда.
@Leeb
Вообще большую часть перечисленного можно без всякого PowerShell сделать.
Сергей, да понятно, что можно. Но раз уж спрашивалось "зачем ps", то я и отвечаю зачем. Все-таки это же продвинутая консоль, ответ майкрософта линуксоидам.
ОтветитьУдалить@Сергей Высоцкий Очень интересно, да.
ОтветитьУдалить"На нем пишут мои разработчики" это плохой аргумент для того, кто знает пяток разных языков и может выбрать подходящий под задачу.
ОтветитьУдалитьА для того, кто учит первый язык -- это очень даже хороший аргумент, потому что есть, с кем быстро проконсультироваться, когда возникают затруднения с языком.
@okiseleva: у вас сылочка "Вот эти" битая. Из адреса надо запятую убрать... :)
ОтветитьУдалитьНемного протроллю :)
ОтветитьУдалитьПо существу вопроса - хочешь стать автотестером - выучи хотя бы один язык программирования. На уровне написания простых алгоритмов на доске мелом или ручкой на листе бумаги.
Правильный тестировщик не только багу найдет, но и скажет, как НАДО сделать :))
ОтветитьУдалить@Alexei Barantsev
ОтветитьУдалитьНененен. Learning curve и читабельность у тех же Python или Ruby как правило в разы лучше чем у жабы и прочих шарпов.
В Python и Ruby для того чтобы начать писать тестовые скрипты не нужно учить кучу бесполезного на первых порах (а зачастую вообще бесполезного для автоматизации тестирования) мусора. В шарпах так не получится.
Опять же - учитывая озвученные шаблоны общения с разработчиками там консультациями не пахнет.
Эй! Я бы попросила!
ОтветитьУдалитьВо-первых, почему сразу "мусора"??? Да даже если не пригодится в автоматизации, почему сразу знание мусором то становится, тупеют от них люди, чтоли?))
Во-вторых, не путайте удаленную работу (на которой у меня 3 программиста) и основную. Помощь я получаю, задерживаясь на основной, в реальном общении. Да и удаленные программисты - ну, с кем не бывает поругаться\обидеться? Сразу все, отношения дефакто плохие? оО
У меня хорошие программисты и в том блоге я сама признавала, что бывают проблемы непонимания и из-за непонятного описания с моей стороны.
Так что не все так плохо )))
Информацию я таскаю с 6 разработчиков, это лучше, чем с нуля. Опять же, даже в выходные кого-нибудь, да найдешь онлайн :))
Сергей, я учу людей уже давно, сначала студентов в вузе, сейчас тренинги провожу. И пробовал разные языки. У меня сложилось впечатление, что для начального освоения языки со строгой типизацией лучше подходят. Потому что они не дают слишком сильно косячить, многие тривиальные ошибки находятся на этапе компиляции. Есть альтернативный опыт?
ОтветитьУдалить@Alexei Barantsev
ОтветитьУдалитьТам есть ряд бонусов.
1. Они скриптовые, т.е. часть работы можно делать просто в консольке.
2. Они скриптовые, т.е. не нужно разбираться с объектным джанком чтобы начать что-то писать.
3. По ним тонна очень хороших учебников из разряда "Ruby для домохозяек"
Ну и динамическая типизация на простых примерах не должна мешать никак. Наоборот - одна логическая сущность и ничего никуда кастить не надо.
Ruby не простой в изучении язык. На нем можно достаточно легко начать писать что-то работающее, когда знаешь какой-то другой ЯП. При этом это не будет ruby кодом, но со временем проникаешься.
ОтветитьУдалитьНо я тоже придерживаюсь мнения, что скриптовые (интерпретируемые) языки с динамической типизацией для тестирования подходят лучше.
1. Серегей, зачем в консоли, когда есть замечательные среды разработки, с автопродолжением, контекстными подсказками и прочими удобностями? Не путайте освоение языка (+библиотек) и "надо-быстро-быстро-сделать-маленькую-штучку-прямо-сейчас-из-консоли!"
ОтветитьУдалить2. Увы, надо разбираться с объектным джанком, будь то питон или руби, чтобы писать что-нибудь длиннее линейного сценария из 20 строчек. Как только начинается выстраиваться хоть какой-нибудь архитектурный рисунок, так сразу весь этот джанк появляется, а "скриптовость" заканчивается.
3. Книжки для домохозяек это классно, но что потом? Какой следующий шаг? Где книжки по шаблонам проектирования с примерами на руби и питоне?
Лично я не считаю, что тестировщики должны уметь писать только примитивные программы из 20 строчек. Основами архитектурного проектирования нужно владеть, и базовые шаблоны проектирования надо уметь использовать.
1. В консоли потому что не надо ничего компилировать. Написал строку - получил результат. Написал еще - получил еще. Для простейших операций самое то. Про IDE отдельный холивар. Мне последний год vim более чем достаточным средством кажется.
ОтветитьУдалить2. Первое и самое главное - не нужно сразу писать что-то длиннее 20 строк. Пусть для начала на кошках тренируются, а то результаты потом ужасающие (плавали, видели, плакали, рефакторили в смысле переписывали все с нуля). Второе - ООП совсем не обязательно для тестов и архитектуры. Но это уже еще один холивар про функциональщину.
3. Книжки есть. Более того - паттерны проектирования в большинстве своем универсальны. Но прежде чем начать что-то серьезное кодить, лучше с такими вещами как PEP8 разобраться, например.
Понимаешь, то, что у топикстартера написано, вообще паттернами проектирования и рядом не пахнет. И несколько более серьезные вещи там, мягко говоря, рано. Видно по приведенны кускам кода и рассуждениям.
Сергей, Вы преувеличиваете сложность "процесса компиляции". Взять ту же Java + Eclipse -- сохраняем файл, что-то в бэкграунде происходит -- и можно запускать. Впрочем, научиться нажимать в какой-нибудь Visial Studio кнопку Build -- тоже не ахти как сложно.
ОтветитьУдалитьС другой стороны, ещё раз повторю, Вы недооцениваете того факта, что компилятор многие ошибки обнаруживает на этапе компиляции. Это гораздо удобнее, чем на этапе выполнения. Особенно, когда человек учится программировать и делает много ошибок. Строгая типизация здесь очень полезна. Даже в программах из 20 строчек.
Кроме того, я не очень понял -- против чего нацелено недовольство -- против языков или против компиляторов? Ну не нравится компилировать Java -- берите BeanShell и будет вам интерпретируемый язык и консоль. В чём разница-то?
>> И несколько более серьезные вещи там, мягко говоря, рано. Видно по приведенны кускам кода и рассуждениям.
ОтветитьУдалитьА личные выпады я бы предложил вообще не применять, хорошо? Тем более основываясь на столь малом количестве информации. А то можно найти в книжке Страуструпа метод из трёх строчек, который почти ничего не делает, и на основании чтения этого кусочка кода обвинить товарища Бьярна в том, что он в программировании полный профан.
Честно говоря, я вообще не понимаю, какая идея стоит за Вашими комментариями. Вы хотите поддержать Ольгу в её намерении научиться программировать? Или поддерживаете точку зрения Николая "неужели вы не понимаете, что тестировщик так и не научится программировать? да оно и не нужно никому"? Или ...?
Я, вот, поддержу Сергея в том, что Java и C# - это плохие языки, чтобы учиться программированию вообще. IDE - это плохой инструмент для обучения программированию тоже. Насчет первых двух аргументов не добавлю: слишком много вещей не важных с алгоритмической точки зрения, но без них никуда не уедешь! Когда создавалась Java, OOP считался чуть ли не серебряной пулей. Когда поняли, что не все функции обязаны находиться в классах, было уже поздно, хорошо хоть с шарпом немного одумались, и сделали-таки нормальные анонимные функции (впрочем, в итоге они тоже становятся всем-известно-чем, чтобы вписаться в модель CLR).
ОтветитьУдалитьК шарпу, кстати, в этом ключе вопросов не меньше. Писать без классов он все равно не дает, а те самые лямбды - это уже своего рода джедайство, коего в языке пруд пруди (в отличие от Джавы), что, конечно, повышает его выразительность, утягивая вслед и Learning Curve.
Прямо на моих глазах два тестировщика осваивают Джаву. Я бы не сказал, что все у них хорошо. То проблемы с доступом к полям, то еще что-нибудь.
За Ruby, конечно, не скажу (мне почему-то кажется, появись Perl на 8 лет позже, он бы и назывался Ruby), но Python в этом плане гораздо лучше. Да, статическая типизация бы помогла (вы, Алексей, кстати, путаете строгую и статическую типизацию, которая в Питоне вполне строгая). Но и на нем свет клином не сошелся, в принципе. Зато на питоне можно взять и писать (и не учить OOP, а точку на объектах типа строк можно принять как данность или объяснив это проще, чем существованием объектной модели; и быть не далеким от истины). И REPL там есть. Очень полезная штука, причем не только для новичков. Насколько ценна возможность написать строку и сразу проверить, так ли она работает или не так (тут, кстати, можно проверить и правильно ли ты ее записал; но это есть и в IDE, которыми, тем не менее, лучше по началу не пользоваться). Сколько строк для такой проверки понадобится написать в Java?
Теперь про зло в виде IDE. Любая абстракция всегда скрывает детали. Хорошо, когда эти детали не важны. Но для написания программ порядок, способ, правила разрешения имен, связывания модулей и их компиляции не могут быть не существенными. Если что-то пойдет не так и ты не сможешь собрать свою программу, что делать? Это опасное непонимание процесса, которое игнорировать по первости "просто нажал на кнопочку" довольно опасно. Не обязательно же в мелочах разбираться, но думать надо. С другой стороны мощная система подсказок, переходов к объявлениям и рефакторинга позволяют не заботится о вроде бы мелочах (МЕЛОЧАХ?) типа логической организации кода. Что для маленьких проектов и программулинок вообще несущественный плюс, а для больших существенный минус. Там без мощной IDE и не разобраться уже. И код часто проще переписать, чем исправить. Хорошо, что это можно быстро сделать, правда (автодополнение нам поможет)? А без ide приходится постоянно следить за простотой и логичностью конструкций, за лаконичностью кода. Результат: проект растет, но дебаг простой, расширение простое, навигация в ворохе исходников проста, как никогда. Без IDE, без "перейти к". Даже подстветки синтаксиса не надо: nano, cat, grep и find.
И да, на OOP реально не сошелся клином свет. Учить его только потому, что на нем все пишут: вот так и случается паттерн головного мозга. Если так хочется жабовской экосистемы (потому что она, действительно, распространена и может действительно использоваться фирмой), можно без OOP взять, например, кожуру (Clojure). Для .NET и Mono есть IronPython. А если выбор экосистемы вообще так жестко не стоит, тогда какие проблемы-то?
@Alexei Barantsev
ОтветитьУдалитьЯ скорее против мнимых благ IDE и Java/C#. Но мне кажется мы тут быстро не договоримся.
Про код и рассуждения это не личные выводы, это констатация факта. Ничего плохого в этом факте не вижу - все учатся, все с чего-то начинают.
Большая часть аргументов про паттерны проектирования и блага IDE/языков без динамической типизации мне не нравятся вне зависимости от того кто топикстартер. Причины я вроде уже озвучил, только вот вольное метание в обсуждении от уровня "новичков" до уровня написания серьезных тестов на пользу не идет. Это разные вещи.
На этом я откланиваюсь.
Этот комментарий был удален автором.
ОтветитьУдалить@Alexei Barantsev
ОтветитьУдалитьСвое мнение на полезность програмирования для тестировщиков я вроде ясно обозначил.
На всякий случай повторю:
1. Тестировщику програмировать не обязательно. Можно, но не the must.
2. Автоматизация рутинных операция и gui/api тесты это разные вещи. Не надо мешать все в кучу.
3. Мне претит пищевая цепочка сложившаяся в нашей индустрии, когда все примерно так: "начинающий тестировщик -> тестировщик -> автоматизатор или начальник -> ну теперь уж точно начальник".
Хоть и не мне последнее высказывание.
ОтветитьУдалитьНасчет первых двух пунктов. Можно то можно, но когда система уже более-менее большая, ручное тестирование, регрессионное, верификация билда и тд гораздо приятнее автоматизировать.
Это:
1. Дешевле. Потому что релизимя мы не в последний раз, а базовые модули... Ну меняются, конечно, но не все сразу, если архитектура есть, и она устойчивая - отрефакторить не сложно.
2. Эффективнее. У меня уходит час на верификацию билда, релизы проходят в 9 вечера. Если я буду проверять ВСЕ... Я не буду проверять все ))))
Проверяем основное. А иногда падает то, что упустили. Не продумали в импакт анализе и тд. Ошибки, выявленные с помощью автоматизированной сборки, помогают нам выдавать Заказчику более качественный продукт, а ведь именно оно нам и надо!
Насчет 3 пункта согласна :) Я даже писала об этом в самом первом посте, но там длинно. А так - если человеку нравится тестировать, зачем от него ждать желания непременно стать начальником?
Хотя я вас, возможно, не так поняла и вы имели в виду всего лишь звено "автоматизатор" в этой цепи :)
Автоматизация - это шаг вперед, наверх. Но не обязательно по карьерной лестнице (начальник). Просто в саморазвитии. И это хорошо!
Автоматизация (регрессии) через GUI ниразу не дешевле и не эффективнее. Это миф. Во многом сложившийся потому, что люди почему-то думаю что избыточные тесты на уровне GUI, пусть и выполненные роботами, это дешевле и эффективнее чем нормальный процесс. Это не так.
ОтветитьУдалитьАвтоматизация (в том числе и регрессии через GUI) это не средство замещения человека в проверках того или иного рода, а средство получения дополнительной, более качественной информации на основе которой будут приниматься решения. Решения будут приниматься человеком. А вот тут вы уже получаете совершенно другие риски и совершенно другую косвенную выгоду. Померить их нормально невозможно. Померить можно только выгоду от того что вы перестанете прогонять избыточные регрессионные тесты, но тут и автоматизация (через GUI) не обяззательна.
В идеале автоматизация это набор быстрых детекторов изменений, вот и все. Не важно через GUI или через что вам там удобнее (скорее всего через все разом).
С другой стороны автоматизация это средство для глубоких и полезных исследований. Но это уже MBT и прочие радости жизни.
И да, я не только про "начальник". "Автоматизатор" это тоже параллельное развитие, т.к. фактически это просто программирование в своей весьма специфичной нише. То, что в контекстной школе принято называть словом toolsmith, например. Для тестировщика это фактически шаг в сторону.
Почему избыточные то?
ОтветитьУдалитьПросто у нас, например, нет комплексного тестирования. А его вполне можно заавтоматизировать. Сгласитесь, регрессионное, что ручное, что автоматическое, занимает время.
Зависит от размера системы, но это все равно какое-то время! И обычно на комплексное тестирование выделяют день-два. В маленьком проекте. Ну или в среднем, когда тестировщик не один.
Зачем-то оно надо, правда ведь? Всегда полезно проверить какой-то старый код.
Особенно если сложный, ну, например... Какой-нибудь ОГРН. Даже если без лишних тестов, все равно проверки всех пунктов на "корректный/некоррекный" займут время, а как приятно, когда это делает система, да еще и с разными значениями.
А ты ручками делаешь это или долго или каждый раз вставляя некие тестовые данные, заготовленные с прошлого раза.
Разумеется, автоматизация не отменяет ручного тестирования. Я так вообще исследователь :)
И юнит-тесты, расписываемые программистами, не спасают систему от элементарных ошибок. Элементарных на уровне GUI, хотя, безусловно, помогают отсеять часть ошибок перед выкладкой.
Ну и конечно, автоматизация в принципе не обязательна, нанимаешь 10 новичков и пущай себе ручками одно и тоже тестируют :)
Но она облегчает жизнь и помогает сосредоточиться именно на исследовании, на интеграции модулей, а не на проверке правильности заполнения полей.
Так что может, оно и шаг в сторону. Но весьма полезный :) И кстати, много где требуемый на рынке труда)))
Заавтоматизировать можно вообще все, при желании. Даже исследовать можно при помощи роботов.
ОтветитьУдалитьПочему вы так боитесь того что ранее работавший функционал сломается? Что такого страшного творят с кодом ваши программисты, а главное почему?
> Зачем-то оно надо, правда ведь?
Расскажите мне зачем оно надо. Я бы хотел послушать. Я работал, видимо, в не очень сложных проектах. В основном всякие автоматизации хостинга, визуализация OLAP, всякие reporting BI тулы и SDK, картографические проекты и серверные бэкэнды с кастомной низкоуровневой оптимизацией. В большинстве случаев в итоге мы сводили к тому, что вполне могли оборачивать новый релиз без потерь за 24 часа и менее (ну кроме случаев, когда переписывалась половина системы). В остальном тестирование упирается в решение скорее концептуальных проблем, тюнинг производительности и т.п. Это практически параллельная деятельность.
У нас были проверки на построение семантических моделей над схемами баз данных. Вроде довольно просто и автоматизируемо. Так и было, пока мы не столкнулись с реальными схемами потенциальных пользователей. Столкновение с реальностью показало, что наши автоматические проверки показывают только, что "продукт не дымится". Все. Пришлось пересматривать модели, ставить эксперименты. Слава богу, что это случилось до релиза.
Бонус: корректность заполнения полей на последнем моем продукте за все его годы жизни ломалась два раза. Оба раза при смене контролов для ввода данных. В итоге проверки разделили на проверки корректности работы инпута (не ввода туда конкретных данных, а именно самого инпута) и массовые проверки обработки вводимых данных (без всякого GUI). Ни один хомячок не пострадал, а цикл правки критичных для системы внутренностей здорово сократился.
Автоматизация не облегчает жизнь сама по себе. Более того - она может ее здорово осложнить. Она не экономит время сама по себе, т.к. в ряде случаев правильный процесс экономит время, а не автоматизация. Избавление от лишних телодвижений в тестировании это тоже процесс.
А на рынке труда востребована не автоматизация, а способность перегнать вот этот вот "тестплан вообще всего" в роботов с долгим продолжительным сопровождением в последствиии. Т.е. тупо фигачить тесты роботам в пустоту, потому что все так делают. И для этого много уметь не надо. Второй вопрос в том, что халява эта рано или поздно закончится (да в общем-то для совсем-совсем востребованности оно и так надо) и придется заниматься человеческой автоматизацией, а тут нужно понимание целей, проблематики и существующих решений. А это сложно.
Но ведь и идти надо от простого к сложному.
ОтветитьУдалитьФактически переложение тест-плана в код помогает тебе - разобрать с IDE, языком, и тд.
Основы программирования в разрезе тестирования :) А потом можно углубляться в "человеческую".
Зачем надо - так или иначе, внося исправления в модуль, программист может сломать все что угодно в модуле. Для того и регрессионное, чтобы не вылить лажу какую-нибудь, проведя всего лишь функциональное.
Часто возникают проблемы в других модулях, но они отлавливаемые по интеграции... Оно, конечно, ручным проверяется.
А вот в исследование с помощью роботов я не верю :)
Я уже писала выше, автоматизация помогает затронутый функционал, но не бездумно сидеть и каждый раз ручками тыкать, а запустить тесты и сидеть, думать, что эти тесты не охватили и что тебе надо проверить руками. Полезнее и приятнее, нежели одно и то же руками чекать, абсолютно бездумно на Н-ный раз
> Фактически переложение тест-плана в код помогает тебе - разобрать с IDE, языком, и тд.
ОтветитьУдалитьНет, это скорее отличный мотиватор почистить тестплан от мусора, пересмотреть стратегию тестирования и осознать зачем и что перекладывать в код. При это если это сразу перекладывать в GUI тесты, то еще и происходит подмена понятий, т.к. зачастую решений сильно больше чем просто переложить в GUI автоматику.
> Основы программирования в разрезе тестирования
В озвученном скорее "основы программирования в разрезе непонятно чего". Не тестирования точно. И не программирования. Какой-то гремучий гибрид скорее.
> программист может сломать все что угодно в модуле
Простите, но когда вы пишите про code review, а потом это, то мне становится не по себе. Это как раз и есть объяснение из разряда "всегда может случиться чудо". Это плохое объяснение, т.к. "чудо" у вас может случиться везде, а от "сглаза" тестовой машинки вы не застрахованы. Не надо плодить паранойю (или это просто халтура?). Найдите хорошее объяснение.
По этой же причине я не люблю людей копающихся в терминологии ради изучения предмета, т.к. там сразу начинаются объяснения "в той книжке написано", "потому что функциональное это функциональное", "потому что [вставить другую магическую фразу]". И это все вместо того чтобы подумать самому.
> А вот в исследование с помощью роботов я не верю :)
Очень зря. Помощь роботов не означает, что кроме роботов ничего не будет. Почитайте Harry Robinson'а, например: http://www.harryrobinson.net/
Да и если задуматься, то даже автоматизация регрессии это своего рода исследования при помощи роботов. Вопрос вашего подхода и отношения к нему, не более того.
> Полезнее и приятнее, нежели одно и то же руками чекать, абсолютно бездумно на Н-ный раз
А вы думайте. Даже на N-й раз. Очень помогает.
Эх, ну вот, комментить комменятят, а никто не сказал, что сам блог опять перекосило. Из-за вставок кода.
ОтветитьУдалить> Нет, это скорее отличный мотиватор почистить тестплан от мусора, пересмотреть стратегию тестирования и осознать зачем и что перекладывать в код.
Не отрицаю :) Помогает, почему нет? А чем вас не устраивают GUI тесты? Нам в первую очередь надо, чтобы все работало в GUI, то есть со стороны пользователей. А юнит тесты это вообще задача программистов, системно свои методы проверять :)
Почему в разрезе "непонятно чего"? Если переложить свои тест-кейсы на язык программирования, это будет программирование в разрезе тестирования :)
> Простите, но когда вы пишите про code review, а потом это
Вообще не поняла этот обзац :)
Код ревью должны проводить - тестировщики своих тестов, программисты - своего кода. Наоборот врядли получится.
Я не могу оценить код программистов (да и кто мне его даст). И я (и не только я) далеко не всегда получаю ответ на вопрос "что ты задел". Зато периодически получаю ответ "да все надо проверить".
> Вопрос вашего подхода и отношения к нему, не более того
Мое отношение - роботы никогда не заменят ручного тестировщика в плане ислледования :)
> А вы думайте. Даже на N-й раз. Очень помогает
О чем? Заранее зная, какого результата я жду и понимая, что конкретно сейчас мне копать глубже не надо, надо проверить вот это и то. Все.
Пусть это сделает робот. А я как раз подумаю - о чем робот забыл.
У нас слишком много тест-кейсов, при выполнении которых надо получить конкретный результат. Если в процессе выполнения думать о другом - можно пропустить нечто важное. Даже если ты думаешь о том, на что это могло повлиять.
Ну и зачем тратить столько времени, чтобы каждый раз продуманно тестировать каждое поле, вводя в него по 5 разных вариаций, если это сделает программа?
Сейчас наверняка спросите, бывает ли, что "ломаются" эти поля, зачем их тестировать))) Бывают! Вот у нас - бывают. Можно кричать, что программисты халтурят, а можно работать над тем, чтобы Заказчик получил нормальный продукт вне зависимости от того, "правильные" у вас программисты или "не очень" с точки зрения некоего стандарта :)
> А чем вас не устраивают GUI тесты? Нам в первую очередь надо, чтобы все работало в GUI, то есть со стороны пользователей. А юнит тесты это вообще задача программистов, системно свои методы проверять :)
ОтветитьУдалитьТем что люди почему-то считают что проверив работу того или иного функционала через драйвер браузера они проверяют то как оно будет со стороны пользователя. Это не так, потому что ваш тест через GUI взаимодействует с набором контролов (зачастую весьма ограниченным), а пользователь со всей отрендеренной страницей в заданном для него разрешении и так далее.
GUI тесты нужны только тогда, когда вы не можете проверить тот или иной функционал другим способом. Или где другие проверки выйдут для вас дороже.
И да, разнообразие автоматических тестов сильно больше чем GUI и Unit.
> Вообще не поняла этот обзац :)
При том, что в нормальном процессе "могут сломать что угодно" звучит странно.
> Если переложить свои тест-кейсы на язык программирования, это будет программирование в разрезе тестирования :)
Нет, это будет перекладывание тест-кейсов на автоматические тестовые скрипты.
> Код ревью должны проводить - тестировщики своих тестов, программисты - своего кода. Наоборот врядли получится.
Почему? Я видел примеры когда очень хорошо получалось.
> Я не могу оценить код программистов (да и кто мне его даст).
Почему? Вам нужна вполне конкретная оценка кода в плане потенциальных проблем, а не его качества как кода.
> И я (и не только я) далеко не всегда получаю ответ на вопрос "что ты задел". Зато периодически получаю ответ "да все надо проверить".
Это же плохо, нет? И уж тем более не аргумент в пользу избыточных GUI тестов. Они вам в таком случае мало чем помогут.
> О чем?
О том что ваши программисты регулярно ломают работающий код и никто никаких действий не предпринимает и в итоге вы лечите симптомы, а не болезнь. Т.е. занимаетесь не обеспечением качества продукта, а маскировкой проблемных мест.
О том что вместо качественного тестирования вы обеспечиваете просто длительное повторяемое тестирование, которое как процесс нацелено на маскировку проблем от заказчика.
> И да, разнообразие автоматических тестов сильно больше чем GUI и Unit.
ОтветитьУдалитьДа я не сомневаюсь, только по вашему и ручное нафиг никому не сдалось - ведь мы проверяем при своих параметрах, а у пользователей и разрешения и другие настройки будут другими..
> При том, что в нормальном процессе "могут сломать что угодно" звучит странно
Нет, а потом мне говорят, что я жалуюсь на своих программистов. НЕсли не верить в свою команду, то зачем в ней работать?)) Да, у нас еще не сильно все крутые и прокачанные и порой я слышу в ответ "ну смотреть тут можно все", ну и что? Пойти повеситься? Или уволиться, сказав, что это фиговая команда?
Тестировщик и сам может составить себе таблицу "что программист мог задеть" и она будет верна на 90+ %, конечно, бывают и сюрпризы :)
Я просто к тому, что такое бывает. И, уверена, не только у меня. Нет ничего идеального :)
> Нет, это будет перекладывание тест-кейсов на автоматические тестовые скрипты.
Ну, об этом речь уже в новом топике пошла - что считать программированием, а что - лишь детской забавой. Для меня это - программирование, так как я пишу программу для своих тестов. Ну такое вот у меня видение
> Почему? Я видел примеры когда очень хорошо получалось
Опять таки, я проецирую ситуацию на себя и свою команду Программисты наши тесты могут проверить, не вопрос, возможно, даже подскажут чего.
Мы их код не проверим. Ну нет таких знаний, вот и все. Разве что на уровне "а тут ты что имел в виду? А тут? А почему тогда нельзя было так и написать", заставляя глупыми вопросами переделывать код на более читабельный и простой ля восприятия, но сколько ж это времени сожрет... И так ли оно надо?
> Почему? Вам нужна вполне конкретная оценка кода в плане потенциальных проблем, а не его качества как кода.
Да, но для этого мне надо четко понимать, что там написано :) А дергать удаленного программиста для подсказок довольно муторное дело... Особенно если учесть их загрузку, мне просто не дадут отнять у них много времени.
> Это же плохо, нет? И уж тем более не аргумент в пользу избыточных GUI тестов. Они вам в таком случае мало чем помогут
Плохо, да. Что вы посоветуете? Абстрактное "поменять ситуацию"? Я пытаюсь, но это не быстро. А пока мы имеем то, что имеем. И тесты "избыточные" тут как раз таки помогут. Потому что моя задача - не допустить ошибок на боевой. И не проверить функционал, потому что "а нефиг было его задевать, ты совсем другое делал" - глупо
> О том что ваши программисты регулярно ломают работающий код и никто никаких действий не предпринимает
Вы знаете, я еще не встречала "хороших" программистов, которые не ломают работающий код :) И даже не верю в то, что такие существуют иначе бы наша профессия давно вымерла - проще платить хорошим программистам, чем средним программистам + тестировщикам и получать на выходе баги.
> О том что вместо качественного тестирования вы обеспечиваете просто длительное повторяемое тестирование, которое как процесс нацелено на маскировку проблем от заказчика
Мне, как тестировщику, вы что предлагаете?
> Да я не сомневаюсь, только по вашему и ручное нафиг никому не сдалось - ведь мы проверяем при своих параметрах, а у пользователей и разрешения и другие настройки будут другими..
ОтветитьУдалитьПо нашему излишняя паника нафиг не сдалась. Надо четко понимать зачем одни вещи нужны, а другие нет. Надо четко понимать почему GUI а не что-то еще. Надо четко понимать чем именно GUI тест отличается от всего остального разнообразия и какие преимущества нам дает. Без этого будет трудно понять область применимости.
> Если не верить в свою команду, то зачем в ней работать?
Почему вы все время в крайности бросаетесь? То у вас есть ревью, то работает оно не так, то сломаться может от любого чиха все что угодно, то еще что-нибудь.
Поломка работающего функционала это не нормальная ситуация. В большинстве случаев она ловится обвесом минимальным набором детекторов изменений. Избыточные тесты со сложной логикой тут не сильно помогут, да к тому же все сильно утяжелят.
Не надо вешаться. Надо стараться сделать процесс как можно более прозрачным. И вам и вашим программистам и менеджеру будет только легче от этого.
> Для меня это - программирование, так как я пишу программу для своих тестов.
Предвыборную? Нет, вы просто перекладываете из одного формального языка в другой чуть более формальный. Это те же тесты. Те же скрипты. С теми же недостатками. Я бы это тестами даже не называл... проверки. Детекторы, может быть.
> Опять таки, я проецирую ситуацию на себя и свою команду Программисты наши тесты могут проверить, не вопрос, возможно, даже подскажут чего.
Мы их код не проверим. Ну нет таких знаний, вот и все.
А не вы ли тут писали про "учиться надо"? Вот вам еще один стимул. Кстати, этот вполне оправдывает изучение языка на котором работает контора (косвенно, т.к. на самом деле для того чтобы читать код язык знать в деталях не нужно как правило).
> Плохо, да. Что вы посоветуете? Абстрактное "поменять ситуацию"? Я пытаюсь, но это не быстро. А пока мы имеем то, что имеем. И тесты "избыточные" тут как раз таки помогут. Потому что моя задача - не допустить ошибок на боевой.
Менять, да. Повышать Testability. Я знаю что это не быстро, но к этому надо стремиться, а не говорить "ну у нас это не работает". Надо говорить "мы работаем над этим", например.
И избыточные тесты тут не помогут. Как я пиал выше - минимальный набор детекторов это все что вам нужно. Если сложно из создать из-за плохого testability (а это, кстати, тоже аттрибут качества), то придется усложнять. А еще нажно поднимать вопрос, т.к. данный атрибут качества напрямую влияет на скорость работы (не только вашей, но и ваших программистов). Я думаю в этом все заинтересованы. А если нет, то это очень плохо и стоит задуматься о смене работы.
> Вы знаете, я еще не встречала "хороших" программистов, которые не ломают работающий код :) И даже не верю в то, что такие существуют иначе бы наша профессия давно вымерла - проще платить хорошим программистам, чем средним программистам + тестировщикам и получать на выходе баги.
Вы просто неправильно понимаете цели тестирования. Если вы хотите приносить пользу проекту, повышать его ценность, то цель "не опустить сотни багов на продакшене" плохая. Так как это действительно можно заменить хорошим процессом и хорошими программистами. Некоторые так и живут - без тестировщиков вида gatekeeper. И еще потом говорят, что тестирование не нужно. И они правы, потому что _такое_ тестирование совсем не обязательно.
> Мне, как тестировщику, вы что предлагаете?
Предоставлять информацию. Учиться правильно формулировать информацию о проблемах. Учиться проводить root cause analysys. Перестать быть узким местом процесса. Изучать продукт вдоль и поперек, начиная от документации и заканчивая технологиями. Учиться задавать правильные вопросы разработчикам и менеджменту. Не те, которые будут сеять панику, а те, которые помогут им принимать взвешенные решения, помогут думать над вашими проблемами в том числе.
> То у вас есть ревью, то работает оно не так, то сломаться может от любого чиха все что угодно, то еще что-нибудь.
ОтветитьУдалитьВы меня неверно прочитали. У нас ревью нет (ну или я о нем не знаю). Когда я говорила о ревью, я говорила "вот у программистов есть...", имея в виду вообще программистов, как класс :) Не своих
И разумеется, все от любого чиха не ломается. Просто импакт анализ выцарапать сложно, а сломаться что-то может, да, пусть и редко, но не хочется же выпускать плохой продукт, правда?
> Я бы это тестами даже не называл... проверки. Детекторы, может быть
Ой... Ну я бы сходила на ваш семинар в духе "тест-дизайн" и послушала, что вы под тестами понимаете :)
> А не вы ли тут писали про "учиться надо"? Вот вам еще один стимул.
Так я ж не против, просто на данный момент времени я не проверю - знаний нет. Да, стимул. Ну так и я на месте не сижу, что-то изучаю вечно в последнее время, а выше головы не прыгнешь :) Потом да, возможно, я и белым ящиком научусь пользоваться.
> Я думаю в этом все заинтересованы
Да, заинтересованы. И мы работаем над этим :) Не хочу вчитываться в то, что писала раньше, я не говорила (вроде?) что "в нашей ситуации это неприменимо", я лишь сказала, что в нашей ситуации пока сложно с импакт анализом. Это да. И это пока, я надеюсь)
И конечно, надо улучшать тестабилити и уменьшать количество тестов. Это все понятно. Но комплексного тестирования это не отменяет, чем плохо его заавтоматизировать? Есть набор минимума, проверки системы на "ничего не упало, ничего не сломалось", пусть это система проверяет!
> Если вы хотите приносить пользу проекту, повышать его ценность, то цель "не опустить сотни багов на продакшене" плохая
А какая она, цель? И под "опустить" вы понимаете что? Странно фраза построена. Главное, чтобы продукт удовлетворял потребности заказчика, с тем минимумом ошибок, которые тот приемлет.
> Изучать продукт вдоль и поперек, начиная от документации и заканчивая технологиями.
А вот кстати, изучать вы предлагаете для своей пользы или в процессе работы? :) Это ведь тоже трудозатраты...
*Что то мы совсем от темы уехали :)
Но я согласна с вашей позицией, что у нас не все гладко и надо это решать. Это правда, есть что улучшать :)
> Просто импакт анализ выцарапать сложно, а сломаться что-то может, да, пусть и редко, но не хочется же выпускать плохой продукт, правда?
ОтветитьУдалитьНу это коммуникационная проблема. Решать опять же вам. Как - вопрос опять же к вам во многом. Решать это автоматизацией по меньшей мере странно, не находите?
На моей практике - когда я сам начинаю в репозитории копаться и вопросы задавать коммуникации касательно изменений внезапно налаживаются.
> Ой... Ну я бы сходила на ваш семинар в духе "тест-дизайн" и послушала, что вы под тестами понимаете :)
Новосибирск, 17 Декабря. U r welcome. Но скоро книжку доперевожу - там тоже будет.
> И конечно, надо улучшать тестабилити и уменьшать количество тестов. Это все понятно. Но комплексного тестирования это не отменяет, чем плохо его заавтоматизировать? Есть набор минимума, проверки системы на "ничего не упало, ничего не сломалось", пусть это система проверяет!
Количество тестов уменьшать не надо. Надо улучшать качество. В первую очередь путем выбрасывания плохих тестов, упрощением. Потом уже мясо наращивать можно будет.
Про комплексные тесты я категорически не понимаю. Можно русским языком без всякого канцелярита объяснить что это такое и почему атомарные проверки операций на GUI ими не являются?
> А какая она, цель? И под "опустить" вы понимаете что? Странно фраза построена. Главное, чтобы продукт удовлетворял потребности заказчика, с тем минимумом ошибок, которые тот приемлет.
Цель чтобы все заинтересованные лица (увы удовлетворение заказчика это задача сильно более простая чем создание хорошего софта, но если у вас только такая цель, то вам повезло в каком-то смысле) были довольны. Чтобы софт решал проблемы, которые должен решать. Количество багов в продакшене это перпендикулярное измерение, ничего не сообщающее о том что это за баги, например. Т.е. по большому счету можно вырезать из вашего предложения все что после слова "заказчика" и ничего не изменится.
опустить = отпустить. Опечатачка вышла.
> А вот кстати, изучать вы предлагаете для своей пользы или в процессе работы? :) Это ведь тоже трудозатраты...
Это уже вопрос вашей совести, желания, возможностей, желания вашего работодателя пойти навстречу.
> *Что то мы совсем от темы уехали :)
Нет, мы вполне рядом. Просто очень хочется чтобы люди понимали что и почему они пытаются решить тем или иным инструментом. И есть ли у вас способы решить это проще и дешевле.
Автоматизация это не магия, единорожки и щеночки.
>> Изучать продукт вдоль и поперек, начиная от документации и заканчивая технологиями.
ОтветитьУдалить> А вот кстати, изучать вы предлагаете для своей пользы или в процессе работы? :) Это ведь тоже трудозатраты...
Ну, кстати, это ваши обязанности по работе - знать продукт. Не все, правда, так считают, а это плохо.
> Ну, кстати, это ваши обязанности по работе - знать продукт. Не все, правда, так считают, а это плохо
ОтветитьУдалитьПо документации продукт я и так знаю. А вот по технологиям - тут сложнее...
Я уже пыталась донести, что мы хотим заавтоматизировать. Все равно всегда есть некий минимальный набор тестов, которые надо прогнать.
И как бы мы не говорили, что надо прогонять их с умом, все равно это периодически скатывается в тупую работу, когда ты 10 раз проводишь smoke test, заранее зная о результате.
Кстати, если вы с этим хотите поспорить, а ведь вы мне на это писали "ну надо каждый раз думать", то мне непонятно, почему в новом топике вы пишите о том, что работа с IDE точно так же "отупляет", ведь автодополнение подталкивает нас не сильно задумываться.
В любом случае, при повторении одно и того же, сложно делать это каждый раз вдумчиво. Плюс если вы проводите одни и те же тесты, то написанные машиной могут дать результат даже лучше, так как на человека влияют еще и окружающие нас факторы - усталость, температура и тд. А тут - "опять эти smoke", проверил некачественно и все.
В любом случае, я рада, что и начальство согласно со мной, и совсем не против автоматизации. А до "умной" автоматизации мы еще дорастем :)
Ну и насчет комплексного тестирования - когда я работала на проекте, где было 5 тестировщиков. То перед релизами обязательно было комплексное. Зачем оно - понятно из названия, комплексно проверить систему. И увы, баги там находились. Даже, если, казалось бы, этот модуль и не трогали.
Все мы люди, могли и программисты накосячить, могли и тестировщики не продумать до конца, что еще могло быть задето...
Хотя, возможно, вы работали на проектах, которые, если проверять полностью функционал, надо потратить месяц и потому знаете и понимаете, что вполне можно обойтись функциональным...
Тем не менее такая практика была, и приносила результаты. На продакшен уходил более качественный продукт :)
> И как бы мы не говорили, что надо прогонять их с умом, все равно это периодически скатывается в тупую работу, когда ты 10 раз проводишь smoke test, заранее зная о результате.
ОтветитьУдалитьsmoke test как правило небольшой. Полностью заменить его автоматическими проверками не всегда возможно, потому как надо хотя бы мельком на скрины глянуть чтобы факапов не случилось.
> то мне непонятно, почему в новом топике вы пишите о том, что работа с IDE точно так же "отупляет", ведь автодополнение подталкивает нас не сильно задумываться.
Я не понял это предложение? Что непонятно? Оно отупляет, да. Потому что мы перестаем понимать и думать. В тестировании это вообще весьма опасный синдром (рассеянное внимание, непреднамеренная слепота).
> В любом случае, при повторении одно и того же, сложно делать это каждый раз вдумчиво.
Делайте это по-разному. Заставит задуматься.
> Плюс если вы проводите одни и те же тесты, то написанные машиной могут дать результат даже лучше, так как на человека влияют еще и окружающие нас факторы - усталость, температура и тд. А тут - "опять эти smoke", проверил некачественно и все.
Не могут. Ваши автоматические тесты не умнее вас. И точно не умнее человека, который их интерпретирует. Опять же побочные эффекты - пестицид, например.
> То перед релизами обязательно было комплексное. Зачем оно - понятно из названия, комплексно проверить систему. И увы, баги там находились. Даже, если, казалось бы, этот модуль и не трогали.
Непонятно. Smoke не комплексно проверяет?
> Хотя, возможно, вы работали на проектах, которые, если проверять полностью функционал, надо потратить месяц и потому знаете и понимаете, что вполне можно обойтись функциональным...
В любом проекте бесконечное количество возможных тестов. Ничто и никогда нельзя проверить полностью. Good enough это основная концепция тестирования.
> Тем не менее такая практика была, и приносила результаты. На продакшен уходил более качественный продукт :)
Меньше багов != более качественный.
> smoke test как правило небольшой. Полностью заменить его автоматическими проверками не всегда возможно, потому как надо хотя бы мельком на скрины глянуть чтобы факапов не случилось
ОтветитьУдалитьЧас рутины - ни фига себе небольшой. А зачем скрины, я и просто за экраном понаблюдать могу :) Это слишком важный "пробег", чтобы просмотреть только результаты
> Делайте это по-разному. Заставит задуматься.
Из песни слов не выкинешь и обязательных проверок - тоже.
> Не могут
Ну тут глупо спорить, каждый останется при своем мнении. Я привела аргументы, почему могут, и банальное "Ваши автоматические тесты не умнее вас" не убедительно
> Непонятно. Smoke не комплексно проверяет?
В общем то да, ну и что? Давайте тогда поспорим про определения тестирования, только смысл?
> Ничто и никогда нельзя проверить полностью
Отлично! Тогда можно вообще ничего не проверять комплексно под этим девизом + "Меньше багов != более качественный"