tag:blogger.com,1999:blog-3194536352323585971.post7017619214314605394..comments2024-03-20T16:01:01.278+04:00Comments on Жизнь - это движение! А тестирование - это жизнь :): Программирование для тестировщиковОльга Назина (Киселева)http://www.blogger.com/profile/03026399106706734657noreply@blogger.comBlogger50125tag:blogger.com,1999:blog-3194536352323585971.post-29064761039411526502011-12-12T08:45:09.486+04:002011-12-12T08:45:09.486+04:00> smoke test как правило небольшой. Полностью з...> smoke test как правило небольшой. Полностью заменить его автоматическими проверками не всегда возможно, потому как надо хотя бы мельком на скрины глянуть чтобы факапов не случилось<br /><br />Час рутины - ни фига себе небольшой. А зачем скрины, я и просто за экраном понаблюдать могу :) Это слишком важный "пробег", чтобы просмотреть только результаты<br /><br />> Делайте это по-разному. Заставит задуматься.<br />Из песни слов не выкинешь и обязательных проверок - тоже.<br /><br />> Не могут<br />Ну тут глупо спорить, каждый останется при своем мнении. Я привела аргументы, почему могут, и банальное "Ваши автоматические тесты не умнее вас" не убедительно<br /><br />> Непонятно. Smoke не комплексно проверяет?<br />В общем то да, ну и что? Давайте тогда поспорим про определения тестирования, только смысл?<br /><br />> Ничто и никогда нельзя проверить полностью<br />Отлично! Тогда можно вообще ничего не проверять комплексно под этим девизом + "Меньше багов != более качественный"Ольга Назина (Киселева)https://www.blogger.com/profile/03026399106706734657noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-55961148726943981202011-12-11T22:20:48.817+04:002011-12-11T22:20:48.817+04:00> И как бы мы не говорили, что надо прогонять и...> И как бы мы не говорили, что надо прогонять их с умом, все равно это периодически скатывается в тупую работу, когда ты 10 раз проводишь smoke test, заранее зная о результате.<br /><br />smoke test как правило небольшой. Полностью заменить его автоматическими проверками не всегда возможно, потому как надо хотя бы мельком на скрины глянуть чтобы факапов не случилось.<br /><br />> то мне непонятно, почему в новом топике вы пишите о том, что работа с IDE точно так же "отупляет", ведь автодополнение подталкивает нас не сильно задумываться.<br /><br />Я не понял это предложение? Что непонятно? Оно отупляет, да. Потому что мы перестаем понимать и думать. В тестировании это вообще весьма опасный синдром (рассеянное внимание, непреднамеренная слепота).<br /><br />> В любом случае, при повторении одно и того же, сложно делать это каждый раз вдумчиво.<br /><br />Делайте это по-разному. Заставит задуматься.<br /><br />> Плюс если вы проводите одни и те же тесты, то написанные машиной могут дать результат даже лучше, так как на человека влияют еще и окружающие нас факторы - усталость, температура и тд. А тут - "опять эти smoke", проверил некачественно и все.<br /><br />Не могут. Ваши автоматические тесты не умнее вас. И точно не умнее человека, который их интерпретирует. Опять же побочные эффекты - пестицид, например.<br /><br />> То перед релизами обязательно было комплексное. Зачем оно - понятно из названия, комплексно проверить систему. И увы, баги там находились. Даже, если, казалось бы, этот модуль и не трогали.<br /><br />Непонятно. Smoke не комплексно проверяет?<br /><br />> Хотя, возможно, вы работали на проектах, которые, если проверять полностью функционал, надо потратить месяц и потому знаете и понимаете, что вполне можно обойтись функциональным... <br /><br />В любом проекте бесконечное количество возможных тестов. Ничто и никогда нельзя проверить полностью. Good enough это основная концепция тестирования.<br /><br />> Тем не менее такая практика была, и приносила результаты. На продакшен уходил более качественный продукт :)<br /><br />Меньше багов != более качественный.Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-82382102384383312912011-12-10T12:57:52.064+04:002011-12-10T12:57:52.064+04:00> Ну, кстати, это ваши обязанности по работе - ...> Ну, кстати, это ваши обязанности по работе - знать продукт. Не все, правда, так считают, а это плохо<br />По документации продукт я и так знаю. А вот по технологиям - тут сложнее...<br /><br />Я уже пыталась донести, что мы хотим заавтоматизировать. Все равно всегда есть некий минимальный набор тестов, которые надо прогнать.<br /><br />И как бы мы не говорили, что надо прогонять их с умом, все равно это периодически скатывается в тупую работу, когда ты 10 раз проводишь smoke test, заранее зная о результате.<br /><br />Кстати, если вы с этим хотите поспорить, а ведь вы мне на это писали "ну надо каждый раз думать", то мне непонятно, почему в новом топике вы пишите о том, что работа с IDE точно так же "отупляет", ведь автодополнение подталкивает нас не сильно задумываться.<br /><br />В любом случае, при повторении одно и того же, сложно делать это каждый раз вдумчиво. Плюс если вы проводите одни и те же тесты, то написанные машиной могут дать результат даже лучше, так как на человека влияют еще и окружающие нас факторы - усталость, температура и тд. А тут - "опять эти smoke", проверил некачественно и все.<br /><br />В любом случае, я рада, что и начальство согласно со мной, и совсем не против автоматизации. А до "умной" автоматизации мы еще дорастем :)<br /><br />Ну и насчет комплексного тестирования - когда я работала на проекте, где было 5 тестировщиков. То перед релизами обязательно было комплексное. Зачем оно - понятно из названия, комплексно проверить систему. И увы, баги там находились. Даже, если, казалось бы, этот модуль и не трогали.<br /><br />Все мы люди, могли и программисты накосячить, могли и тестировщики не продумать до конца, что еще могло быть задето...<br /><br />Хотя, возможно, вы работали на проектах, которые, если проверять полностью функционал, надо потратить месяц и потому знаете и понимаете, что вполне можно обойтись функциональным... <br /><br />Тем не менее такая практика была, и приносила результаты. На продакшен уходил более качественный продукт :)Ольга Назина (Киселева)https://www.blogger.com/profile/03026399106706734657noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-23944502292292214732011-12-09T15:50:27.592+04:002011-12-09T15:50:27.592+04:00>> Изучать продукт вдоль и поперек, начиная ...>> Изучать продукт вдоль и поперек, начиная от документации и заканчивая технологиями.<br />> А вот кстати, изучать вы предлагаете для своей пользы или в процессе работы? :) Это ведь тоже трудозатраты...<br /><br />Ну, кстати, это ваши обязанности по работе - знать продукт. Не все, правда, так считают, а это плохо.Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-88362906803425258532011-12-09T15:46:05.301+04:002011-12-09T15:46:05.301+04:00> Просто импакт анализ выцарапать сложно, а сло...> Просто импакт анализ выцарапать сложно, а сломаться что-то может, да, пусть и редко, но не хочется же выпускать плохой продукт, правда?<br /><br />Ну это коммуникационная проблема. Решать опять же вам. Как - вопрос опять же к вам во многом. Решать это автоматизацией по меньшей мере странно, не находите?<br />На моей практике - когда я сам начинаю в репозитории копаться и вопросы задавать коммуникации касательно изменений внезапно налаживаются.<br /><br />> Ой... Ну я бы сходила на ваш семинар в духе "тест-дизайн" и послушала, что вы под тестами понимаете :)<br /><br />Новосибирск, 17 Декабря. U r welcome. Но скоро книжку доперевожу - там тоже будет.<br /><br />> И конечно, надо улучшать тестабилити и уменьшать количество тестов. Это все понятно. Но комплексного тестирования это не отменяет, чем плохо его заавтоматизировать? Есть набор минимума, проверки системы на "ничего не упало, ничего не сломалось", пусть это система проверяет!<br /><br />Количество тестов уменьшать не надо. Надо улучшать качество. В первую очередь путем выбрасывания плохих тестов, упрощением. Потом уже мясо наращивать можно будет.<br /><br />Про комплексные тесты я категорически не понимаю. Можно русским языком без всякого канцелярита объяснить что это такое и почему атомарные проверки операций на GUI ими не являются?<br /><br />> А какая она, цель? И под "опустить" вы понимаете что? Странно фраза построена. Главное, чтобы продукт удовлетворял потребности заказчика, с тем минимумом ошибок, которые тот приемлет.<br /><br />Цель чтобы все заинтересованные лица (увы удовлетворение заказчика это задача сильно более простая чем создание хорошего софта, но если у вас только такая цель, то вам повезло в каком-то смысле) были довольны. Чтобы софт решал проблемы, которые должен решать. Количество багов в продакшене это перпендикулярное измерение, ничего не сообщающее о том что это за баги, например. Т.е. по большому счету можно вырезать из вашего предложения все что после слова "заказчика" и ничего не изменится.<br /><br />опустить = отпустить. Опечатачка вышла.<br /><br />> А вот кстати, изучать вы предлагаете для своей пользы или в процессе работы? :) Это ведь тоже трудозатраты...<br /><br />Это уже вопрос вашей совести, желания, возможностей, желания вашего работодателя пойти навстречу.<br /><br />> *Что то мы совсем от темы уехали :)<br /><br />Нет, мы вполне рядом. Просто очень хочется чтобы люди понимали что и почему они пытаются решить тем или иным инструментом. И есть ли у вас способы решить это проще и дешевле.<br />Автоматизация это не магия, единорожки и щеночки.Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-16735756490005425082011-12-09T14:51:58.944+04:002011-12-09T14:51:58.944+04:00> То у вас есть ревью, то работает оно не так, ...> То у вас есть ревью, то работает оно не так, то сломаться может от любого чиха все что угодно, то еще что-нибудь.<br /><br />Вы меня неверно прочитали. У нас ревью нет (ну или я о нем не знаю). Когда я говорила о ревью, я говорила "вот у программистов есть...", имея в виду вообще программистов, как класс :) Не своих<br /><br />И разумеется, все от любого чиха не ломается. Просто импакт анализ выцарапать сложно, а сломаться что-то может, да, пусть и редко, но не хочется же выпускать плохой продукт, правда?<br /><br />> Я бы это тестами даже не называл... проверки. Детекторы, может быть<br />Ой... Ну я бы сходила на ваш семинар в духе "тест-дизайн" и послушала, что вы под тестами понимаете :)<br /><br />> А не вы ли тут писали про "учиться надо"? Вот вам еще один стимул. <br />Так я ж не против, просто на данный момент времени я не проверю - знаний нет. Да, стимул. Ну так и я на месте не сижу, что-то изучаю вечно в последнее время, а выше головы не прыгнешь :) Потом да, возможно, я и белым ящиком научусь пользоваться. <br /><br />> Я думаю в этом все заинтересованы<br />Да, заинтересованы. И мы работаем над этим :) Не хочу вчитываться в то, что писала раньше, я не говорила (вроде?) что "в нашей ситуации это неприменимо", я лишь сказала, что в нашей ситуации пока сложно с импакт анализом. Это да. И это пока, я надеюсь)<br /><br />И конечно, надо улучшать тестабилити и уменьшать количество тестов. Это все понятно. Но комплексного тестирования это не отменяет, чем плохо его заавтоматизировать? Есть набор минимума, проверки системы на "ничего не упало, ничего не сломалось", пусть это система проверяет!<br /><br />> Если вы хотите приносить пользу проекту, повышать его ценность, то цель "не опустить сотни багов на продакшене" плохая<br />А какая она, цель? И под "опустить" вы понимаете что? Странно фраза построена. Главное, чтобы продукт удовлетворял потребности заказчика, с тем минимумом ошибок, которые тот приемлет.<br /><br />> Изучать продукт вдоль и поперек, начиная от документации и заканчивая технологиями.<br />А вот кстати, изучать вы предлагаете для своей пользы или в процессе работы? :) Это ведь тоже трудозатраты...<br /><br />*Что то мы совсем от темы уехали :)<br />Но я согласна с вашей позицией, что у нас не все гладко и надо это решать. Это правда, есть что улучшать :)Ольга Назина (Киселева)https://www.blogger.com/profile/03026399106706734657noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-55927478143889522022011-12-09T09:16:37.096+04:002011-12-09T09:16:37.096+04:00> Да я не сомневаюсь, только по вашему и ручное...> Да я не сомневаюсь, только по вашему и ручное нафиг никому не сдалось - ведь мы проверяем при своих параметрах, а у пользователей и разрешения и другие настройки будут другими..<br /><br />По нашему излишняя паника нафиг не сдалась. Надо четко понимать зачем одни вещи нужны, а другие нет. Надо четко понимать почему GUI а не что-то еще. Надо четко понимать чем именно GUI тест отличается от всего остального разнообразия и какие преимущества нам дает. Без этого будет трудно понять область применимости.<br /><br />> Если не верить в свою команду, то зачем в ней работать?<br /><br />Почему вы все время в крайности бросаетесь? То у вас есть ревью, то работает оно не так, то сломаться может от любого чиха все что угодно, то еще что-нибудь.<br />Поломка работающего функционала это не нормальная ситуация. В большинстве случаев она ловится обвесом минимальным набором детекторов изменений. Избыточные тесты со сложной логикой тут не сильно помогут, да к тому же все сильно утяжелят.<br />Не надо вешаться. Надо стараться сделать процесс как можно более прозрачным. И вам и вашим программистам и менеджеру будет только легче от этого.<br /><br />> Для меня это - программирование, так как я пишу программу для своих тестов.<br /><br />Предвыборную? Нет, вы просто перекладываете из одного формального языка в другой чуть более формальный. Это те же тесты. Те же скрипты. С теми же недостатками. Я бы это тестами даже не называл... проверки. Детекторы, может быть.<br /><br />> Опять таки, я проецирую ситуацию на себя и свою команду Программисты наши тесты могут проверить, не вопрос, возможно, даже подскажут чего.<br />Мы их код не проверим. Ну нет таких знаний, вот и все.<br /><br />А не вы ли тут писали про "учиться надо"? Вот вам еще один стимул. Кстати, этот вполне оправдывает изучение языка на котором работает контора (косвенно, т.к. на самом деле для того чтобы читать код язык знать в деталях не нужно как правило).<br /><br />> Плохо, да. Что вы посоветуете? Абстрактное "поменять ситуацию"? Я пытаюсь, но это не быстро. А пока мы имеем то, что имеем. И тесты "избыточные" тут как раз таки помогут. Потому что моя задача - не допустить ошибок на боевой.<br /><br />Менять, да. Повышать Testability. Я знаю что это не быстро, но к этому надо стремиться, а не говорить "ну у нас это не работает". Надо говорить "мы работаем над этим", например.<br />И избыточные тесты тут не помогут. Как я пиал выше - минимальный набор детекторов это все что вам нужно. Если сложно из создать из-за плохого testability (а это, кстати, тоже аттрибут качества), то придется усложнять. А еще нажно поднимать вопрос, т.к. данный атрибут качества напрямую влияет на скорость работы (не только вашей, но и ваших программистов). Я думаю в этом все заинтересованы. А если нет, то это очень плохо и стоит задуматься о смене работы.<br /><br />> Вы знаете, я еще не встречала "хороших" программистов, которые не ломают работающий код :) И даже не верю в то, что такие существуют иначе бы наша профессия давно вымерла - проще платить хорошим программистам, чем средним программистам + тестировщикам и получать на выходе баги.<br /><br />Вы просто неправильно понимаете цели тестирования. Если вы хотите приносить пользу проекту, повышать его ценность, то цель "не опустить сотни багов на продакшене" плохая. Так как это действительно можно заменить хорошим процессом и хорошими программистами. Некоторые так и живут - без тестировщиков вида gatekeeper. И еще потом говорят, что тестирование не нужно. И они правы, потому что _такое_ тестирование совсем не обязательно.<br /><br />> Мне, как тестировщику, вы что предлагаете?<br /><br />Предоставлять информацию. Учиться правильно формулировать информацию о проблемах. Учиться проводить root cause analysys. Перестать быть узким местом процесса. Изучать продукт вдоль и поперек, начиная от документации и заканчивая технологиями. Учиться задавать правильные вопросы разработчикам и менеджменту. Не те, которые будут сеять панику, а те, которые помогут им принимать взвешенные решения, помогут думать над вашими проблемами в том числе.Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-22296456344441645512011-12-08T23:17:14.381+04:002011-12-08T23:17:14.381+04:00> И да, разнообразие автоматических тестов силь...> И да, разнообразие автоматических тестов сильно больше чем GUI и Unit. <br />Да я не сомневаюсь, только по вашему и ручное нафиг никому не сдалось - ведь мы проверяем при своих параметрах, а у пользователей и разрешения и другие настройки будут другими..<br /><br />> При том, что в нормальном процессе "могут сломать что угодно" звучит странно<br />Нет, а потом мне говорят, что я жалуюсь на своих программистов. НЕсли не верить в свою команду, то зачем в ней работать?)) Да, у нас еще не сильно все крутые и прокачанные и порой я слышу в ответ "ну смотреть тут можно все", ну и что? Пойти повеситься? Или уволиться, сказав, что это фиговая команда?<br /><br />Тестировщик и сам может составить себе таблицу "что программист мог задеть" и она будет верна на 90+ %, конечно, бывают и сюрпризы :)<br />Я просто к тому, что такое бывает. И, уверена, не только у меня. Нет ничего идеального :)<br /><br />> Нет, это будет перекладывание тест-кейсов на автоматические тестовые скрипты.<br />Ну, об этом речь уже в новом топике пошла - что считать программированием, а что - лишь детской забавой. Для меня это - программирование, так как я пишу программу для своих тестов. Ну такое вот у меня видение<br /><br />> Почему? Я видел примеры когда очень хорошо получалось<br />Опять таки, я проецирую ситуацию на себя и свою команду Программисты наши тесты могут проверить, не вопрос, возможно, даже подскажут чего.<br />Мы их код не проверим. Ну нет таких знаний, вот и все. Разве что на уровне "а тут ты что имел в виду? А тут? А почему тогда нельзя было так и написать", заставляя глупыми вопросами переделывать код на более читабельный и простой ля восприятия, но сколько ж это времени сожрет... И так ли оно надо?<br /><br />> Почему? Вам нужна вполне конкретная оценка кода в плане потенциальных проблем, а не его качества как кода.<br />Да, но для этого мне надо четко понимать, что там написано :) А дергать удаленного программиста для подсказок довольно муторное дело... Особенно если учесть их загрузку, мне просто не дадут отнять у них много времени.<br /><br />> Это же плохо, нет? И уж тем более не аргумент в пользу избыточных GUI тестов. Они вам в таком случае мало чем помогут<br />Плохо, да. Что вы посоветуете? Абстрактное "поменять ситуацию"? Я пытаюсь, но это не быстро. А пока мы имеем то, что имеем. И тесты "избыточные" тут как раз таки помогут. Потому что моя задача - не допустить ошибок на боевой. И не проверить функционал, потому что "а нефиг было его задевать, ты совсем другое делал" - глупо<br /><br />> О том что ваши программисты регулярно ломают работающий код и никто никаких действий не предпринимает<br />Вы знаете, я еще не встречала "хороших" программистов, которые не ломают работающий код :) И даже не верю в то, что такие существуют иначе бы наша профессия давно вымерла - проще платить хорошим программистам, чем средним программистам + тестировщикам и получать на выходе баги.<br /><br />> О том что вместо качественного тестирования вы обеспечиваете просто длительное повторяемое тестирование, которое как процесс нацелено на маскировку проблем от заказчика<br />Мне, как тестировщику, вы что предлагаете?Ольга Назина (Киселева)https://www.blogger.com/profile/03026399106706734657noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-41937226565673037742011-12-08T18:37:32.625+04:002011-12-08T18:37:32.625+04:00> А чем вас не устраивают GUI тесты? Нам в перв...> А чем вас не устраивают GUI тесты? Нам в первую очередь надо, чтобы все работало в GUI, то есть со стороны пользователей. А юнит тесты это вообще задача программистов, системно свои методы проверять :)<br /><br />Тем что люди почему-то считают что проверив работу того или иного функционала через драйвер браузера они проверяют то как оно будет со стороны пользователя. Это не так, потому что ваш тест через GUI взаимодействует с набором контролов (зачастую весьма ограниченным), а пользователь со всей отрендеренной страницей в заданном для него разрешении и так далее.<br /><br />GUI тесты нужны только тогда, когда вы не можете проверить тот или иной функционал другим способом. Или где другие проверки выйдут для вас дороже.<br /><br />И да, разнообразие автоматических тестов сильно больше чем GUI и Unit.<br /><br />> Вообще не поняла этот обзац :) <br />При том, что в нормальном процессе "могут сломать что угодно" звучит странно.<br /><br />> Если переложить свои тест-кейсы на язык программирования, это будет программирование в разрезе тестирования :)<br /><br />Нет, это будет перекладывание тест-кейсов на автоматические тестовые скрипты.<br /><br />> Код ревью должны проводить - тестировщики своих тестов, программисты - своего кода. Наоборот врядли получится.<br /><br />Почему? Я видел примеры когда очень хорошо получалось.<br /><br />> Я не могу оценить код программистов (да и кто мне его даст).<br /><br />Почему? Вам нужна вполне конкретная оценка кода в плане потенциальных проблем, а не его качества как кода.<br /><br />> И я (и не только я) далеко не всегда получаю ответ на вопрос "что ты задел". Зато периодически получаю ответ "да все надо проверить".<br /><br />Это же плохо, нет? И уж тем более не аргумент в пользу избыточных GUI тестов. Они вам в таком случае мало чем помогут.<br /><br />> О чем?<br /><br />О том что ваши программисты регулярно ломают работающий код и никто никаких действий не предпринимает и в итоге вы лечите симптомы, а не болезнь. Т.е. занимаетесь не обеспечением качества продукта, а маскировкой проблемных мест.<br /><br />О том что вместо качественного тестирования вы обеспечиваете просто длительное повторяемое тестирование, которое как процесс нацелено на маскировку проблем от заказчика.Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-91501783530166067212011-12-08T16:04:16.368+04:002011-12-08T16:04:16.368+04:00Эх, ну вот, комментить комменятят, а никто не сказ...Эх, ну вот, комментить комменятят, а никто не сказал, что сам блог опять перекосило. Из-за вставок кода.<br /><br />> Нет, это скорее отличный мотиватор почистить тестплан от мусора, пересмотреть стратегию тестирования и осознать зачем и что перекладывать в код.<br />Не отрицаю :) Помогает, почему нет? А чем вас не устраивают GUI тесты? Нам в первую очередь надо, чтобы все работало в GUI, то есть со стороны пользователей. А юнит тесты это вообще задача программистов, системно свои методы проверять :)<br /><br />Почему в разрезе "непонятно чего"? Если переложить свои тест-кейсы на язык программирования, это будет программирование в разрезе тестирования :)<br /><br />> Простите, но когда вы пишите про code review, а потом это<br />Вообще не поняла этот обзац :) <br />Код ревью должны проводить - тестировщики своих тестов, программисты - своего кода. Наоборот врядли получится.<br />Я не могу оценить код программистов (да и кто мне его даст). И я (и не только я) далеко не всегда получаю ответ на вопрос "что ты задел". Зато периодически получаю ответ "да все надо проверить".<br /><br />> Вопрос вашего подхода и отношения к нему, не более того<br />Мое отношение - роботы никогда не заменят ручного тестировщика в плане ислледования :)<br /><br />> А вы думайте. Даже на N-й раз. Очень помогает<br />О чем? Заранее зная, какого результата я жду и понимая, что конкретно сейчас мне копать глубже не надо, надо проверить вот это и то. Все.<br />Пусть это сделает робот. А я как раз подумаю - о чем робот забыл.<br /><br />У нас слишком много тест-кейсов, при выполнении которых надо получить конкретный результат. Если в процессе выполнения думать о другом - можно пропустить нечто важное. Даже если ты думаешь о том, на что это могло повлиять. <br /><br />Ну и зачем тратить столько времени, чтобы каждый раз продуманно тестировать каждое поле, вводя в него по 5 разных вариаций, если это сделает программа?<br /><br />Сейчас наверняка спросите, бывает ли, что "ломаются" эти поля, зачем их тестировать))) Бывают! Вот у нас - бывают. Можно кричать, что программисты халтурят, а можно работать над тем, чтобы Заказчик получил нормальный продукт вне зависимости от того, "правильные" у вас программисты или "не очень" с точки зрения некоего стандарта :)Ольга Назина (Киселева)https://www.blogger.com/profile/03026399106706734657noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-44429782919743773062011-12-08T13:43:44.410+04:002011-12-08T13:43:44.410+04:00> Фактически переложение тест-плана в код помог...> Фактически переложение тест-плана в код помогает тебе - разобрать с IDE, языком, и тд. <br /><br />Нет, это скорее отличный мотиватор почистить тестплан от мусора, пересмотреть стратегию тестирования и осознать зачем и что перекладывать в код. При это если это сразу перекладывать в GUI тесты, то еще и происходит подмена понятий, т.к. зачастую решений сильно больше чем просто переложить в GUI автоматику.<br /><br />> Основы программирования в разрезе тестирования<br /><br />В озвученном скорее "основы программирования в разрезе непонятно чего". Не тестирования точно. И не программирования. Какой-то гремучий гибрид скорее.<br /><br />> программист может сломать все что угодно в модуле<br /><br />Простите, но когда вы пишите про code review, а потом это, то мне становится не по себе. Это как раз и есть объяснение из разряда "всегда может случиться чудо". Это плохое объяснение, т.к. "чудо" у вас может случиться везде, а от "сглаза" тестовой машинки вы не застрахованы. Не надо плодить паранойю (или это просто халтура?). Найдите хорошее объяснение.<br /><br />По этой же причине я не люблю людей копающихся в терминологии ради изучения предмета, т.к. там сразу начинаются объяснения "в той книжке написано", "потому что функциональное это функциональное", "потому что [вставить другую магическую фразу]". И это все вместо того чтобы подумать самому.<br /><br />> А вот в исследование с помощью роботов я не верю :)<br /><br />Очень зря. Помощь роботов не означает, что кроме роботов ничего не будет. Почитайте Harry Robinson'а, например: http://www.harryrobinson.net/<br />Да и если задуматься, то даже автоматизация регрессии это своего рода исследования при помощи роботов. Вопрос вашего подхода и отношения к нему, не более того.<br /><br />> Полезнее и приятнее, нежели одно и то же руками чекать, абсолютно бездумно на Н-ный раз<br /><br />А вы думайте. Даже на N-й раз. Очень помогает.Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-15936501014462027392011-12-08T12:36:02.976+04:002011-12-08T12:36:02.976+04:00Но ведь и идти надо от простого к сложному.
Факти...Но ведь и идти надо от простого к сложному. <br />Фактически переложение тест-плана в код помогает тебе - разобрать с IDE, языком, и тд. <br /><br />Основы программирования в разрезе тестирования :) А потом можно углубляться в "человеческую".<br /><br />Зачем надо - так или иначе, внося исправления в модуль, программист может сломать все что угодно в модуле. Для того и регрессионное, чтобы не вылить лажу какую-нибудь, проведя всего лишь функциональное. <br /><br />Часто возникают проблемы в других модулях, но они отлавливаемые по интеграции... Оно, конечно, ручным проверяется.<br />А вот в исследование с помощью роботов я не верю :)<br /><br />Я уже писала выше, автоматизация помогает затронутый функционал, но не бездумно сидеть и каждый раз ручками тыкать, а запустить тесты и сидеть, думать, что эти тесты не охватили и что тебе надо проверить руками. Полезнее и приятнее, нежели одно и то же руками чекать, абсолютно бездумно на Н-ный разОльга Назина (Киселева)https://www.blogger.com/profile/03026399106706734657noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-13769329382855910992011-12-08T11:37:01.663+04:002011-12-08T11:37:01.663+04:00Заавтоматизировать можно вообще все, при желании. ...Заавтоматизировать можно вообще все, при желании. Даже исследовать можно при помощи роботов.<br /><br />Почему вы так боитесь того что ранее работавший функционал сломается? Что такого страшного творят с кодом ваши программисты, а главное почему?<br /><br />> Зачем-то оно надо, правда ведь?<br /><br />Расскажите мне зачем оно надо. Я бы хотел послушать. Я работал, видимо, в не очень сложных проектах. В основном всякие автоматизации хостинга, визуализация OLAP, всякие reporting BI тулы и SDK, картографические проекты и серверные бэкэнды с кастомной низкоуровневой оптимизацией. В большинстве случаев в итоге мы сводили к тому, что вполне могли оборачивать новый релиз без потерь за 24 часа и менее (ну кроме случаев, когда переписывалась половина системы). В остальном тестирование упирается в решение скорее концептуальных проблем, тюнинг производительности и т.п. Это практически параллельная деятельность.<br /><br />У нас были проверки на построение семантических моделей над схемами баз данных. Вроде довольно просто и автоматизируемо. Так и было, пока мы не столкнулись с реальными схемами потенциальных пользователей. Столкновение с реальностью показало, что наши автоматические проверки показывают только, что "продукт не дымится". Все. Пришлось пересматривать модели, ставить эксперименты. Слава богу, что это случилось до релиза.<br /><br />Бонус: корректность заполнения полей на последнем моем продукте за все его годы жизни ломалась два раза. Оба раза при смене контролов для ввода данных. В итоге проверки разделили на проверки корректности работы инпута (не ввода туда конкретных данных, а именно самого инпута) и массовые проверки обработки вводимых данных (без всякого GUI). Ни один хомячок не пострадал, а цикл правки критичных для системы внутренностей здорово сократился.<br /><br />Автоматизация не облегчает жизнь сама по себе. Более того - она может ее здорово осложнить. Она не экономит время сама по себе, т.к. в ряде случаев правильный процесс экономит время, а не автоматизация. Избавление от лишних телодвижений в тестировании это тоже процесс.<br /><br />А на рынке труда востребована не автоматизация, а способность перегнать вот этот вот "тестплан вообще всего" в роботов с долгим продолжительным сопровождением в последствиии. Т.е. тупо фигачить тесты роботам в пустоту, потому что все так делают. И для этого много уметь не надо. Второй вопрос в том, что халява эта рано или поздно закончится (да в общем-то для совсем-совсем востребованности оно и так надо) и придется заниматься человеческой автоматизацией, а тут нужно понимание целей, проблематики и существующих решений. А это сложно.Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-65302691387933937302011-12-08T09:06:17.184+04:002011-12-08T09:06:17.184+04:00Почему избыточные то?
Просто у нас, например, нет ...Почему избыточные то?<br />Просто у нас, например, нет комплексного тестирования. А его вполне можно заавтоматизировать. Сгласитесь, регрессионное, что ручное, что автоматическое, занимает время.<br /><br />Зависит от размера системы, но это все равно какое-то время! И обычно на комплексное тестирование выделяют день-два. В маленьком проекте. Ну или в среднем, когда тестировщик не один.<br /><br />Зачем-то оно надо, правда ведь? Всегда полезно проверить какой-то старый код.<br /><br />Особенно если сложный, ну, например... Какой-нибудь ОГРН. Даже если без лишних тестов, все равно проверки всех пунктов на "корректный/некоррекный" займут время, а как приятно, когда это делает система, да еще и с разными значениями. <br /><br />А ты ручками делаешь это или долго или каждый раз вставляя некие тестовые данные, заготовленные с прошлого раза.<br /><br />Разумеется, автоматизация не отменяет ручного тестирования. Я так вообще исследователь :) <br /><br />И юнит-тесты, расписываемые программистами, не спасают систему от элементарных ошибок. Элементарных на уровне GUI, хотя, безусловно, помогают отсеять часть ошибок перед выкладкой.<br /><br />Ну и конечно, автоматизация в принципе не обязательна, нанимаешь 10 новичков и пущай себе ручками одно и тоже тестируют :) <br />Но она облегчает жизнь и помогает сосредоточиться именно на исследовании, на интеграции модулей, а не на проверке правильности заполнения полей.<br /><br />Так что может, оно и шаг в сторону. Но весьма полезный :) И кстати, много где требуемый на рынке труда)))Ольга Назина (Киселева)https://www.blogger.com/profile/03026399106706734657noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-67529657171409886042011-12-07T20:29:17.659+04:002011-12-07T20:29:17.659+04:00Автоматизация (регрессии) через GUI ниразу не деше...Автоматизация (регрессии) через GUI ниразу не дешевле и не эффективнее. Это миф. Во многом сложившийся потому, что люди почему-то думаю что избыточные тесты на уровне GUI, пусть и выполненные роботами, это дешевле и эффективнее чем нормальный процесс. Это не так.<br /><br />Автоматизация (в том числе и регрессии через GUI) это не средство замещения человека в проверках того или иного рода, а средство получения дополнительной, более качественной информации на основе которой будут приниматься решения. Решения будут приниматься человеком. А вот тут вы уже получаете совершенно другие риски и совершенно другую косвенную выгоду. Померить их нормально невозможно. Померить можно только выгоду от того что вы перестанете прогонять избыточные регрессионные тесты, но тут и автоматизация (через GUI) не обяззательна.<br /><br />В идеале автоматизация это набор быстрых детекторов изменений, вот и все. Не важно через GUI или через что вам там удобнее (скорее всего через все разом).<br /><br />С другой стороны автоматизация это средство для глубоких и полезных исследований. Но это уже MBT и прочие радости жизни.<br /><br />И да, я не только про "начальник". "Автоматизатор" это тоже параллельное развитие, т.к. фактически это просто программирование в своей весьма специфичной нише. То, что в контекстной школе принято называть словом toolsmith, например. Для тестировщика это фактически шаг в сторону.Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-40067162905029968342011-12-07T15:46:00.376+04:002011-12-07T15:46:00.376+04:00Хоть и не мне последнее высказывание.
Насчет перв...Хоть и не мне последнее высказывание.<br /><br />Насчет первых двух пунктов. Можно то можно, но когда система уже более-менее большая, ручное тестирование, регрессионное, верификация билда и тд гораздо приятнее автоматизировать.<br /><br />Это:<br />1. Дешевле. Потому что релизимя мы не в последний раз, а базовые модули... Ну меняются, конечно, но не все сразу, если архитектура есть, и она устойчивая - отрефакторить не сложно.<br /><br />2. Эффективнее. У меня уходит час на верификацию билда, релизы проходят в 9 вечера. Если я буду проверять ВСЕ... Я не буду проверять все ))))<br />Проверяем основное. А иногда падает то, что упустили. Не продумали в импакт анализе и тд. Ошибки, выявленные с помощью автоматизированной сборки, помогают нам выдавать Заказчику более качественный продукт, а ведь именно оно нам и надо!<br /><br />Насчет 3 пункта согласна :) Я даже писала об этом в самом первом посте, но там длинно. А так - если человеку нравится тестировать, зачем от него ждать желания непременно стать начальником? <br /><br />Хотя я вас, возможно, не так поняла и вы имели в виду всего лишь звено "автоматизатор" в этой цепи :)<br /><br />Автоматизация - это шаг вперед, наверх. Но не обязательно по карьерной лестнице (начальник). Просто в саморазвитии. И это хорошо!Ольга Назина (Киселева)https://www.blogger.com/profile/03026399106706734657noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-15876789171498689382011-12-07T14:45:40.492+04:002011-12-07T14:45:40.492+04:00@Alexei Barantsev
Свое мнение на полезность програ...@Alexei Barantsev<br />Свое мнение на полезность програмирования для тестировщиков я вроде ясно обозначил.<br />На всякий случай повторю:<br /><br />1. Тестировщику програмировать не обязательно. Можно, но не the must.<br />2. Автоматизация рутинных операция и gui/api тесты это разные вещи. Не надо мешать все в кучу.<br />3. Мне претит пищевая цепочка сложившаяся в нашей индустрии, когда все примерно так: "начинающий тестировщик -> тестировщик -> автоматизатор или начальник -> ну теперь уж точно начальник".Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-55492956299175954302011-12-07T14:44:22.280+04:002011-12-07T14:44:22.280+04:00Этот комментарий был удален автором.Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-59195903290813428992011-12-07T14:40:55.462+04:002011-12-07T14:40:55.462+04:00@Alexei Barantsev
Я скорее против мнимых благ IDE ...@Alexei Barantsev<br />Я скорее против мнимых благ IDE и Java/C#. Но мне кажется мы тут быстро не договоримся.<br /><br />Про код и рассуждения это не личные выводы, это констатация факта. Ничего плохого в этом факте не вижу - все учатся, все с чего-то начинают. <br /><br />Большая часть аргументов про паттерны проектирования и блага IDE/языков без динамической типизации мне не нравятся вне зависимости от того кто топикстартер. Причины я вроде уже озвучил, только вот вольное метание в обсуждении от уровня "новичков" до уровня написания серьезных тестов на пользу не идет. Это разные вещи. <br /><br />На этом я откланиваюсь.Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-47807174023199665882011-12-06T14:49:04.345+04:002011-12-06T14:49:04.345+04:00Я, вот, поддержу Сергея в том, что Java и C# - это...Я, вот, поддержу Сергея в том, что Java и C# - это плохие языки, чтобы учиться программированию вообще. IDE - это плохой инструмент для обучения программированию тоже. Насчет первых двух аргументов не добавлю: слишком много вещей не важных с алгоритмической точки зрения, но без них никуда не уедешь! Когда создавалась Java, OOP считался чуть ли не серебряной пулей. Когда поняли, что не все функции обязаны находиться в классах, было уже поздно, хорошо хоть с шарпом немного одумались, и сделали-таки нормальные анонимные функции (впрочем, в итоге они тоже становятся всем-известно-чем, чтобы вписаться в модель CLR). <br /><br />К шарпу, кстати, в этом ключе вопросов не меньше. Писать без классов он все равно не дает, а те самые лямбды - это уже своего рода джедайство, коего в языке пруд пруди (в отличие от Джавы), что, конечно, повышает его выразительность, утягивая вслед и Learning Curve. <br /><br />Прямо на моих глазах два тестировщика осваивают Джаву. Я бы не сказал, что все у них хорошо. То проблемы с доступом к полям, то еще что-нибудь.<br /><br />За Ruby, конечно, не скажу (мне почему-то кажется, появись Perl на 8 лет позже, он бы и назывался Ruby), но Python в этом плане гораздо лучше. Да, статическая типизация бы помогла (вы, Алексей, кстати, путаете строгую и статическую типизацию, которая в Питоне вполне строгая). Но и на нем свет клином не сошелся, в принципе. Зато на питоне можно взять и писать (и не учить OOP, а точку на объектах типа строк можно принять как данность или объяснив это проще, чем существованием объектной модели; и быть не далеким от истины). И REPL там есть. Очень полезная штука, причем не только для новичков. Насколько ценна возможность написать строку и сразу проверить, так ли она работает или не так (тут, кстати, можно проверить и правильно ли ты ее записал; но это есть и в IDE, которыми, тем не менее, лучше по началу не пользоваться). Сколько строк для такой проверки понадобится написать в Java?<br /><br />Теперь про зло в виде IDE. Любая абстракция всегда скрывает детали. Хорошо, когда эти детали не важны. Но для написания программ порядок, способ, правила разрешения имен, связывания модулей и их компиляции не могут быть не существенными. Если что-то пойдет не так и ты не сможешь собрать свою программу, что делать? Это опасное непонимание процесса, которое игнорировать по первости "просто нажал на кнопочку" довольно опасно. Не обязательно же в мелочах разбираться, но думать надо. С другой стороны мощная система подсказок, переходов к объявлениям и рефакторинга позволяют не заботится о вроде бы мелочах (МЕЛОЧАХ?) типа логической организации кода. Что для маленьких проектов и программулинок вообще несущественный плюс, а для больших существенный минус. Там без мощной IDE и не разобраться уже. И код часто проще переписать, чем исправить. Хорошо, что это можно быстро сделать, правда (автодополнение нам поможет)? А без ide приходится постоянно следить за простотой и логичностью конструкций, за лаконичностью кода. Результат: проект растет, но дебаг простой, расширение простое, навигация в ворохе исходников проста, как никогда. Без IDE, без "перейти к". Даже подстветки синтаксиса не надо: nano, cat, grep и find.<br /><br />И да, на OOP реально не сошелся клином свет. Учить его только потому, что на нем все пишут: вот так и случается паттерн головного мозга. Если так хочется жабовской экосистемы (потому что она, действительно, распространена и может действительно использоваться фирмой), можно без OOP взять, например, кожуру (Clojure). Для .NET и Mono есть IronPython. А если выбор экосистемы вообще так жестко не стоит, тогда какие проблемы-то?Игнат Толчановhttps://www.blogger.com/profile/08992339071421200304noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-66251851838853229602011-12-05T21:21:52.860+04:002011-12-05T21:21:52.860+04:00>> И несколько более серьезные вещи там, мяг...>> И несколько более серьезные вещи там, мягко говоря, рано. Видно по приведенны кускам кода и рассуждениям.<br /><br />А личные выпады я бы предложил вообще не применять, хорошо? Тем более основываясь на столь малом количестве информации. А то можно найти в книжке Страуструпа метод из трёх строчек, который почти ничего не делает, и на основании чтения этого кусочка кода обвинить товарища Бьярна в том, что он в программировании полный профан.<br /><br />Честно говоря, я вообще не понимаю, какая идея стоит за Вашими комментариями. Вы хотите поддержать Ольгу в её намерении научиться программировать? Или поддерживаете точку зрения Николая "неужели вы не понимаете, что тестировщик так и не научится программировать? да оно и не нужно никому"? Или ...?Anonymoushttps://www.blogger.com/profile/02705904835531710648noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-4169749333065742152011-12-05T21:11:14.968+04:002011-12-05T21:11:14.968+04:00Сергей, Вы преувеличиваете сложность "процесс...Сергей, Вы преувеличиваете сложность "процесса компиляции". Взять ту же Java + Eclipse -- сохраняем файл, что-то в бэкграунде происходит -- и можно запускать. Впрочем, научиться нажимать в какой-нибудь Visial Studio кнопку Build -- тоже не ахти как сложно.<br /><br />С другой стороны, ещё раз повторю, Вы недооцениваете того факта, что компилятор многие ошибки обнаруживает на этапе компиляции. Это гораздо удобнее, чем на этапе выполнения. Особенно, когда человек учится программировать и делает много ошибок. Строгая типизация здесь очень полезна. Даже в программах из 20 строчек.<br /><br />Кроме того, я не очень понял -- против чего нацелено недовольство -- против языков или против компиляторов? Ну не нравится компилировать Java -- берите BeanShell и будет вам интерпретируемый язык и консоль. В чём разница-то?Anonymoushttps://www.blogger.com/profile/02705904835531710648noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-10782224145651860352011-12-01T20:26:19.203+04:002011-12-01T20:26:19.203+04:001. В консоли потому что не надо ничего компилирова...1. В консоли потому что не надо ничего компилировать. Написал строку - получил результат. Написал еще - получил еще. Для простейших операций самое то. Про IDE отдельный холивар. Мне последний год vim более чем достаточным средством кажется.<br /><br />2. Первое и самое главное - не нужно сразу писать что-то длиннее 20 строк. Пусть для начала на кошках тренируются, а то результаты потом ужасающие (плавали, видели, плакали, рефакторили в смысле переписывали все с нуля). Второе - ООП совсем не обязательно для тестов и архитектуры. Но это уже еще один холивар про функциональщину.<br /><br />3. Книжки есть. Более того - паттерны проектирования в большинстве своем универсальны. Но прежде чем начать что-то серьезное кодить, лучше с такими вещами как PEP8 разобраться, например.<br /><br /><br />Понимаешь, то, что у топикстартера написано, вообще паттернами проектирования и рядом не пахнет. И несколько более серьезные вещи там, мягко говоря, рано. Видно по приведенны кускам кода и рассуждениям.Сергей Высоцкийhttps://www.blogger.com/profile/01289041631095569954noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-1074356247613124542011-12-01T11:56:50.037+04:002011-12-01T11:56:50.037+04:001. Серегей, зачем в консоли, когда есть замечатель...1. Серегей, зачем в консоли, когда есть замечательные среды разработки, с автопродолжением, контекстными подсказками и прочими удобностями? Не путайте освоение языка (+библиотек) и "надо-быстро-быстро-сделать-маленькую-штучку-прямо-сейчас-из-консоли!"<br /><br />2. Увы, надо разбираться с объектным джанком, будь то питон или руби, чтобы писать что-нибудь длиннее линейного сценария из 20 строчек. Как только начинается выстраиваться хоть какой-нибудь архитектурный рисунок, так сразу весь этот джанк появляется, а "скриптовость" заканчивается.<br /><br />3. Книжки для домохозяек это классно, но что потом? Какой следующий шаг? Где книжки по шаблонам проектирования с примерами на руби и питоне?<br /><br />Лично я не считаю, что тестировщики должны уметь писать только примитивные программы из 20 строчек. Основами архитектурного проектирования нужно владеть, и базовые шаблоны проектирования надо уметь использовать.Anonymoushttps://www.blogger.com/profile/02705904835531710648noreply@blogger.comtag:blogger.com,1999:blog-3194536352323585971.post-82112980391780749692011-12-01T01:40:18.085+04:002011-12-01T01:40:18.085+04:00Ruby не простой в изучении язык. На нем можно дост...Ruby не простой в изучении язык. На нем можно достаточно легко начать писать что-то работающее, когда знаешь какой-то другой ЯП. При этом это не будет ruby кодом, но со временем проникаешься.<br /><br />Но я тоже придерживаюсь мнения, что скриптовые (интерпретируемые) языки с динамической типизацией для тестирования подходят лучше.LeshaLhttps://www.blogger.com/profile/02505406919353794440noreply@blogger.com