На поточном проекте, ребята из меньюел команды хранят тест кейсы в екселе (гугл докс)… И это не совсем тест кейсы, а скорее “чеклисты”, в определнной мере набросок основных идей и путей при тестировании. То есть у нас организовано что-то наподобие “Исследовательскового тестирования”. И синхронизация с автотестами на очень примитивном и неточном уровне - обозначая в чеклистах тест кейсы как automated:)
На предыдущем проекте сначала мы использовали TestLink, но как только развернули автоматизацию, отказались от хранения тест кейсов в каком либо другом месте. В основном потому что тест-фреймворк позволял писать тесты с помощью DSL в очень читабельном виде, как будто это и есть сами описания тест кейсов.
Те же тесты которые были не автоматизированы - а их было очень мало - хранились в виде майндмапов на конфлюенсе.
В целом мне кажеться что описание любой сущности должно жить в одном месте для удобства поддержки. И если тест кейс автоматизирован, то больше хранить его незачем нигде в другом каком либо виде. Другой вопрос в том что нужо еще автоматизировать его так, чтобы он полностью покрывал мануальный тест кейс, и служил в коде саме себе документацией. Если же полностью покрыть не удается, значит можно просто “вырезать” из менюел тест кейса “автоматизированную часть”.
Интересно, что у вас был за фреймворк и какими навыками обладали члены команды. Потому что хранение читабельных тестов в java коде все равно не решает проблему быстрого доступа к тестам и их прохождение, если нужно. Или у вас был супер непрерывный процесс и 100% зеленных тестов, что вы даже руками их не перепроганяли.
Процес был довольно непрерывным. Все время мы старались держать тесты зелеными. Если падал какой то тест - последний билд мастер (это такая роль была которая передавалась тому кто следующий завалит билд) иследовал - почему, фиксил сразу проблему либо заводил таску/баг и “перенастравал” тест таким образом что-бы если баг будет пофикшен - тест полюбому упал - что было бы сигналом отвественному за фикс бага - не забывть и “починить” тесты. Таким образом тесты действительно всегда были “зелеными” и статус о проблемах всегда жил в одном месте - в Жире - список поточных багов.
В любом случае тесты можно было просто запустить самому с любой машины, так как запускались они одной консольной командой передавая ей тест скрипт(ы).
Этот скрипт представлял собой ямл файл со сконфигурированными тест кейсами.
Фреймворк (написан на С#) был доведен до ума, за 4-5 месяцев, в основном 2 девелопероми (что забирало у них примерно до половины рабочего времени). Тестировщик был ответсвенен за требования к фреймворку, дизайн DSL, а также писал компонент который парсил ямл скрипт. Ну и в последствии мог вносить изменения в сам фреймворк. Ну и конечно с помощью DSL писал автоматизированные тесты.
Теперь о том что тестировалось - тестировалься SOAP сервис умной конвертации (только часть трека, со склеиванием с другим треком, со звуком, без, ну и в таком духе) видео из одних форматов в другие…
Другие функциональные и интеграционные тесты (отвечали в основном за взаимодействие с другими компонентами/сервисами) были написаны на сишарпе тригерились после каждого билда. Любой в команде был достаточно квалифицирован для того чтобы самому запустить тесты и поправить если надо в любое время.
Тестов которые автоматизированы не были, типа: проиграть видео после конвертации, послушать звук:) - было не много… Они уже жили в каком то месте ином от системы менеджента версий.
Потому что хранение читабельных тестов в java коде все равно не решает
проблему быстрого доступа к тестам и их прохождение, если нужно.
Кстати почему? Если тест хорошо написан, просто и понятно, живет в правильном неймспейсе/пакете… Почему тогда сложно его найти? Если cчитать що все в команде дружат с ІDE… Если кто то не дружит, тогда да, будет проблематично…
Дело не в том, понимают ли все IDE, или нет. Дело в стремлении всё автоматизировать, что в корне противоречит основным принципам тестирования, впрочем, как и здравому смыслу. Как правило, самые серьезные баги находит как раз человек, т.к. скрипты никогда не смогут заменить мозг. Автоматизация должна служить полезным дополнением к ручному тестированию, но уж никак не заменять его.
Касательно вариантов хранения кейсов в скриптах - в корне не согласен. Реальность такова, что не имея “бумажного” шаблона кейсов, вы вольны подстраивать ваш скрипт, как вам того захочется, с одной лишь целью - увидеть зеленый огонек, аля - “привет, менеджер!.. смотри, я написал такие хорошие скрипты, у меня все пасс!.. 100% quality!”. А как вы расставляете приоритеты вашим кейсам? К примеру, общий экзекьюшен тайм - двое суток (у нас все ведь автоматизировано, тестов много, ручных почти нет). Вам говорят, что надо релизнуться через сутки. Что будете делать? Как выберете тесты для экзекьюшена? Есть ли у вас приоритезированные чеклисты? Трейсебили матрица? Как определяете покрытие функционала? Сможете ли посчитать плотность багов относительно функциональных областей? Определить наиболее критические и перераспределить приоритеты для следующей итерации? И сделать все это естественно по скриптам, написанным на красивом DSL…
Как когда-то сказал один менеджер: бумага творит чудеса. Когда вас высшее руководство спросит, насколько качественно ваше ПО и можно ли его выпускать в свет, 100% зелененьких огоньков не ответят на этот вопрос. Нужен evidence посерьезней. Особенно в случае проектов, где одна ошибка может стоить кому-то жизни или миллионов у.е.
Наверное потому что реально 100% работающих проектов по такому принципу я еще не встречал. Все равно какая-то часть была где-то описана. Вот и интересно, как процесс работал у вас
Бумага тоже не даст тебе полноценного ответа на этот вопрос, но согласен с утверждением, что при тотальной автоматизации очень легко потерять правильный ориентир тестирования. С автоматизацией этого тоже можно достичь, пример тому executable specifications или specifications by examples, но тут важно выполнять частые проверки и ревью не только с технической точки зрения, а со стороны стратегической, что разрабатываем, когда и в какой последовательности.
[quote=“ArtOfLife, post:5, topic:3372”]
Дело не в том, понимают ли все IDE, или нет. Дело в стремлении всё автоматизировать, что в корне противоречит основным принципам тестирования, впрочем, как и здравому смыслу. [/quote]
Мне кажется стремление что то автоматизировать - это правильное стремление. Это стремление жить лучше, проще, качественнее и эффективней. В любом случае Вы скорее всего имели ввиду чрезмерное применение автоматизации там где это не принесет плодов. Никто и не говорил что нужно забывать про здравый смысл.
Как правило, самые серьезные баги находит как раз человек, т.к.
скрипты никогда не смогут заменить мозг. Автоматизация должна служить
полезным дополнением к ручному тестированию, но уж никак не заменять
его.
Что вы имеете ввиду говоря о “ручном тестировании” которое нельзя заменить? Если говорить о “ручном прогоне тучи тест кейсов перед релизом” (у нас этого не успевает команда с 5ти человек за неделю упорного труда) - с какой это стати не заменить их автоматическими?
Если же говорить о вольном полете мысли во время исследовательского тестирования, нахождении серьйозных и нестандартных багов - почему найдя такие тест кейсы сразу их не автоматизировать? Автоматизация даже позволит прогнать такой тест который вы вручную и не прогонете так сразу…
Да нет никакого ручного тестирования. Все это сказки в оправдание тестировщикам которым лень учиться новому. Есть тестирование вообще - как умение видеть больше чем просто требование, умение не пропускать ни одной детали, и после выбирать важные и первоприоритетные, в результате обеспечивая нужное покрытие и оценивая его отчитываться о статусе качества заказчику.
А все остальное это либо “ручной рутинный прогон всего ранее творчески сотворенного” либо же “автоматизация рутины с учетом ресурсов, приоритетов и рисков”. И в любом случае автоматизация не противоречит тестированию как таковому. А так называемое “ручное тестирование” никакого отношения к сути тестирования не имеет.
Что то здесь на форуме, часто любят реальность вспоминать. Вы как хотите, но я с такой реальностью не работаю. Если кто то где то подстраивает свои тесты как елку наряжает пускай этим и занимается. Я тут не при чем. И все мной описанное к этому отношения не имеет.
Вы знаете мне сложно думать об общем екзекьюшене автоматизированых в двое суток. Мне проще думать о недели за которую 5 человек “хотя бы что то” успевают сделать вручную.
Что я буду делать после того как мне такое скажут? Уволюсь или выйду на сцену и попрошу чтобы меня закидали помидорами. Потому что такое может случиться только в двух случаях: Я совсем отупел и ничего не сделал чтобы предупредить такое безобразие на проекте; или же у заказчика шиза стрельнула и валить надо побыстрее.
Зачем я должен ставить себя в ситуацию, которой я никогда не допускал на своих проектах и допускать не собираюсь? Я все таки QA инженер и качество обеспечиваю наперед, а не разгребаю уже после.
Все о чем вы говорите - о приоритетах - все это достигается группируя автотесты в группы, и выставляя им свои приоритеты. Что вообще за трейсебилити матрица? Я ее только в книжках видел. Есть беклог который отображает требования. Если Стори закрыта - это значит функционал реализован и протестирован, тесты жывут либо где им место (и спланированы для регресию) если они проганяются вручную либо автоматизированы и бегают в СИ. И что вообще за проблемы с плотностями, областями, и другими репортами. Жира конечно не панацея, но не делает эти процесы невозможными и страшними. И я не вижу как это связано с автоматизированными тестами.
Мне кажется Ваши вопросы обоснованы тем, что Вы действительно в своем опыте могли сталкиваться с таким… Но также мне кажется, что все эти проблемы рождаются при неправильном построении процессов с самого начала. Если поискать можно найти множество удачных стартапов где тестировщиков как таких и нет вообще. А все потому что в нормальной еджайл команде - все QA инженеры, потому что все сначала думают а потом делают, умеют сами за собой следить, сами себя организовывать, и сами тестировать свой код. И сначала думают о тестировании и его реализуют а потом кодят. Да у них не будет полного покрытия, и что то да они пропустят. Но это что то - будет скорее всего то - что увидят юзеры и не почуствуют особого дискомфорта, а с радостью помогут сделать любимый продукт лучше. И основной функционал будет более качественным по сравнению со многими проектами мастодонтами с целыми отделами ручного тестирования но девелоперами которые не пишут тестов под свой код.
Еще раз повторюсь, я не пропагандирую здесь “зажигание зеленых огоньков”. Я вообще считаю что автоматизаторы которые просто автоматизируют какие то тест кейсы (а часто действительно свои собственные огоньки зажигают) это вообще не тестировщики - и существовать не должны - потому что за них такую работу сделают намного эффективней девелоперы. И вообще часто на проектах дешевле, нанять меньше тестировщиков, и больше девелоперов, поставить правильные процессы, тестировщиков назначить генерить идеи, планировать тестирование, автоматизированное в том числе, и вручную проганять то что не будет автоматизировано. А девелоперы пускай пишут тест фреймворки (и конечно же юнит и аксептенс тесты). Они это сделают намного быстрее и качественнее чем большинство автоматизаторов. А от тестировщиков (все равно со знанием автоматизации) нужно будет только выставить им требования, что им нужно от такого то фреймворка, и как они должны будут его использовать.
Немножко о том как я пишу автотесты…
Есть два режима:) - более менее полное покрытие и базовое. Если есть время, и удалось запустить этот процес с самого начала - как обычный тестировщик (возможно сначала накидываю план в виде майнд мапа) берусь за функционал - иследую его и генерю тест кейсы - разница лиш в том, что вместо того чтобы их записывать в какой то тест линк - я сразу автоматизирую их. И в силу того что у меня под руками вычислительная машина - мне не нужен целый день (а потом еще по такому дню перед каждым релизом) чтобы прогнать тест на множестве параметров или проверить основные возможные комбинации определнных изменений. В результате мое покрытие больше и качественнее, и нет речи ни о каких огоньках… Потому что “тестирование” (пускай даже его ручным назвать) никто не убирал. И конечно никто не говорит что на этом будет конец, при каждом серьезном изменении функционала я буду каждый раз проходить эту фазу именно “тестирования” а не автоматизации (которая действительно будет только инструментом - но зато каким инструментом) снова.
В другом же случае… Если уж меня закинули на проект где “все плохо”, или сложно что то автоматизировать, я действительно буду только “дополнять” то что уже есть)
А также есть еще моменты когда автоматизировать быстро и просто не получиться… Ну что ж) Не все сразу)
Вообщем… Как всегда… Нагородил здесь кучу дров) Думаю мне стоит извиниться за свой временами грубоватый тон… Нужно как то за собой следить))) Извиняюсь:)
Но з другой стороны, я очень рад что мой тон может спровоцировать разумные ответы. Мне же со своего болота не видно как по другому бывает, да и болото свое совсем не болотом кажется, потому как тоже глаза не выверну)
Поэтому все действительно зависит от продукта… На каком то проекте автоматизация раскроет крылья вовсю, на каких то будет техничкой подрабатывать… Такие дела)
Все так… все так… И у нас та часть которая не была автоматизирована - была описана… Просто мы старались как можно меньше иметь документации, но при этом чтобы она была качественной и понятной. Я старался везде где можно использовать майнд мапы вместо “текстовых” тест кейсов… Ну и все что уже где то живет - например автотесты в системе менджмента версий, требования - как стори в жире, баги - не дублировать в других местах…
В принципе мне нравиться подход “Исследовательского тестирования” Который сейчас “в тренде” Вот только мне муляет глаз то что с него делают что то сверх инновационное)
По сути везде где как всегда времени и ресурсов не хватает - так и тестируют. Разница лишь в том что действительно оно стает таким как “описывают в умных статях” - когда тестировщики (да и вся команда) действительно компетентные и ‘passionate’ инженеры:) Которые и не читали то никогда этих статей…
Эх… Все в образовании дело… Нужно правильно учить молодое поколение) И программистов и тестировщиков) Приучать их думать о качестве сразу а не потом, когда уже и суп с котом…
Да, кстати, в последнее время довольно часто перенимаю проекты из-за бугра и встречаю ровно такой случай, что некоторые проекты (количество уже довольно не малое) используют только разработчиков и тестировщиков нет вообще. Нет - это не означает, что у них нет тестирования, просто всю работу выполняют разработчики. И да они делают более качественный код и более быстро, но за то, пропускают дефекты и не покрывают часто, что нужно. Вот как раз этот момент покрывается нормальным поставленным процессом, частыми ревью, а также подключением именно живых пользователей к тестированию, что бы сравнить что действительно хочет заказчик.
Конечно не во всех случаях такое можно такое увидеть, но такой факт существует и чем больше я беру именно стартап проектов тем больше я вижу именно эту картину.
Да ладно все отлично. Вот в таких рассуждениях и рождаются новые мысли и стремление, что-то поменять или улучшить, потому что есть другая ИНАЯ точка зрения.
Когда определенный девайс впрыснет пациенту смертельную дозу лекарства, тогда сложно будет обвинить скрипты (да впрочем и автора) в том, что они не заметили отклонение от нормы, выходящее за рамки сценария, или в случае так называемых шагов влево / вправо. Когда банк потеряет миллионы долларов из-за неверного округления в момент, выходящий за пределы видимости скрипта - аналогично. Да примеров можно привести сколь угодно много. Но вы опять делаете акцент на слове заменить. И если вы считаете, что сможете автотестами покрыть абсолютно все сценарии, не говоря уже о ручной перепроверке наиболее критических областей, то говорить дальше не о чем.
С той же, что и в ответе выше. Сократить время на регрессию / рутину - вариант. Заменить - нонсенс.
Да ну? Тема для холивара однако. Если вы считаете, что тестирование заключается лишь в умении не пропускать / приоритезировать детали с целью обеспечения / оценки покрытия… И этого вполне достаточно для оценки уровня качества? Серьезно что-ли?
Ручного тестирования нет? А как же вы будете автоматизировать процесс тестирования требований / usability? Сколько вам потребуется дорогостоящих человеко-ресурсов / времени на автоматизацию нефункциональных требований? Складывается впечатление, что дискуссию ведет чистый девелопер.
Видимо, у нас разное представление о понятии качества. Каким образом его можно обеспечить наперед? Вы можете снизить риск появления дефектов в определенных модулях, но однозначно утверждать, что в следующем билде качество будет n%, вы никак не можете.
Жизнь есть вне скрама. Доказано проектами с жесткой формализацией и высоким уровнем рисков.
Приводить в пример стартапы без QA тут вообще не уместно, как мне кажется. Это все равно, что сравнивать IT-шника Васю из гастронома с тимами Майкрософта / Гугла / Оракла.
Сугубо девелоперское мышление, опять аджайл, перфекционизм, все все умеют, вера в идеальный код, бесполезность мануальщиков и т.п. Я вас разочарую, но вся ваша теория разобьется в пух и прах, когда вы попадете в крупную компанию на большой / серьезный проект.
С какой стати девелоперы должны ставить процессы? Или о каких процессах речь? По поводу фреймворков - согласен. Но какой смысл держать лишних девелоперов для написания скриптов по готовому фрейму, если проще научить этому тестировщиков? Ведь у вас, как вы утверждаете, DSL, не отличающийся от вручную написанных кейсов.
Что есть - начало в данном случае? Если у вас уже есть готовый функционал (который можно исследовать и автоматизировать), то чем вы занимаетесь до момента завершения его девелопмента? Как выглядит процесс?
Сохраняя скорее всего в том же майндмапе. Все зависит от уровней на котором продукт уже в какой то мере написан. А еще конечно есть такие вещи как “пленинг”, что как по мне уже немножко выбивается с этой темы, поэтому упоминаю вскользь…
Девелоперы не ставят процесы, если они хорошие компетентные инженеры - они просто работают по них. Это и означает “самоорганизованую команду”.
Ответ:
как они должны будут его использовать.
Разве с этого не понятно, что “использовать фреймворк” и есть - использовать по назначению = писать тесты с попомощью этой библиотеки, например с помощью DSL?
Здесь? это где? Я уже где то упоминал… Если ваша реальность - гастроном. Пожалуйста. Ту реальность к которой я стремлюсь, ставлю в пример другим, и достигаю со временем все ближе и ближе - это не гастроном. Я не вижу с какой это стати хорошие примеры стали не уместными.
Я вообще редко когда подписываюсь под “однозначностью”, тестировщик же все таки) Обеспечить качество - это прямой перевод термина Quality Assurance который должен быть известен в наших кругах. Уже это дает мне право его использовать в предложении и не обьяснять что это значит. Обеспечить качество можно разными путями. Покажу на примере, раз контекст о котором я говорил в цитате не понятет.
Вот это
Баг. И уж повертья я более чем “однозначно” обеспечу его близкую к нулю вероятность появления в моем проекте.
Когда определенный девайс впрыснет пациенту смертельную дозу
лекарства, тогда сложно будет обвинить скрипты (да впрочем и автора) в
том, что они не заметили отклонение от нормы
И так… Давайте попробуем просто перечитать мой пост более внимательно…
С чем вы собственно не согласны? Не ужели вы не видите, что я пускай и использовал иногда слова типа “заменить” (кстати в некоторых примерах это было более чем уместно, так как рутинный прогон длиной в неделю при неуспеваемости - не даст тех творческих находок - что неспешное вдумчивое иследовательськое тистирование измененного функциоанала когда уже есть на что положиться - автотесты. И слово заменить же не однозначное. Ведь может означать “заменить” рутинную неуспеваемось автотестами и получить время для хорошего иследовательского тестирования), я все равно ставлю в фундамент всего - именно тестирование… а не автоматизацию. И даже признаю то, что не везде последний инструмент применим вообще.
То ли вы не внимательны, то ли уж очень вольный у меня стиль изложения своих мыслей. Впрочем, давайте оставим судить об этом читателям. Как по мне, то основные идеи наших постов не противоречат другу. И с обоих люди могут вынести массу полезного. И думаю всегда найдуться и те кто будет не согласен с тем что он увидит в текстах (ведь каждый видит что то свое) и те кто увидит и то зачем я делал те акценты которые делал, что под этим понимал, и те причины которые хотели донести вы дискутируя со мной и как бы “сражаясь” с тем что увидели в текстах у меня
Ох… Мне кажется сдесь вы забыли дописать еще пару моментов которые сделали бы мою жизнь потежелей, одних размеров как по мне недостаточно. Я и работал и работаю на не мальнких проектах, и уж поверьте - довольно крупных компаний. Пока что я справлялся со своими “теориями” Сейчас же…
Но “тестирование” в контексте своих задач я все равно пока что провожу по своему:) Хотя и работаю в режиме “дополнения”. Пройдет время, надеюсь будет возможность поделиться результатами
ЗЫ
Ох, я наверное совсем “девелопер”… Почему то мне кажеться что все что связано с вычислениямы уж точно машина решит лучше человека. В любом случае машину кодит человек. И кодит - значит не в тупую переводит инструкции текста в инструкции программы, а думает, потом думает еще, потом еще сколько нужно, потом пише юнит тесты (если это девелопмент фич а не автотестов), потом кодит, а потом думает еще, пока смотрит на то как исполняются тесты, и все сначала… Если же “кодит” как то по другому (~= ■■■■■кодит) то - в шею:) Шучу) Ну вобщем нужно воспитывать) И снова… Как и все в жизни - не все поддается установленным шаблонам поведения) И капитан очевидность упоминает о здравом смысле…
Из темы чего? Я задал вполне конкретный вопрос о процессе и вашей роли в нем. Сейчас я вижу, что она пока заключается лишь в наброске майндмэпов, эксплоратори тестинге по готовому функционалу и генерации скриптов. А помимо плэненига существует еще масса активностей.
А это тут причем? Вы пишите о том, что нужно нанять больше девелоперов и меньше тестировщиков. Ну напишут ваши девы фрейм, а дальше что? Какой смысл их держать для скриптописания? А вот меньшее кол-во ресурсов тестировщиков как раз таки породит проблему неимения времени и на автоматизацию, и на ручное тестирование. Но содержать то QA дешевле, нежели девов.
Про гастроном вы погорячились. Попробую не обращать на это внимания. Стратапы по уровню сложности проектов не могут стоять и близко к крупным компаниям с серьезными проектами. Посему уместность такого примера не сочетается с обговариваемыми масштабами.
Абстрактный баг или какой-то конкретный / уже зафиксированный?
Как раз проблема таки кроется в словах. Если человек достаточно уверенно использует слово “заменить”, это затмевает все дальнейшие разговоры о глобальном, т.к. воспринимается в форме противоречия. А как QA-инженеру, не вам ли не знать, что противоречий в нашем деле быть не должно?!
Ну так почему бы вам тогда все эти мысли не оформить в качестве статьи и не выложить в паблик?!
Это уже ближе к той реальности, о которой я вел речь. О каких бы идеальных вещах вы не мечтали, в реальности вам практически никогда не предоставят возможности делать так, как вы считаете правильным. А стартап - это не тот уровень. И даже, если когда-то вы на него выйдете (дай Бог) со своим собственным стартапом, пройдет ни один год, а ваши идеи могут оказаться уже устаревшими.
Речь шла о тех вещах, которые скрипт не сможет увидеть в силу своей “прямолинейности” (было даже выделено bold’ом). А идея заключалась в дополнительной перепроверке критических областей ручками и невозможности все автоматизировать. Очевидно же.
Silk Test - продукт для автоматизации тестирования, хорош для функциональных тестов. Можно записывать как простые визуальные тесты (Visual test) можно писать .Net скрипты. Что одно, что другое достаточно понятно, есть много обучающих материалов на английском
Продукты конечно платные, но можно скачать 45-дневный триал, разобраться, потыкать.
Можно писать вопросы на сайте http://c1.ru и мне лично, постараюсь ответить.
Для грамотного автоматизатора есть продукт Silk4J и еще Silk4NET для Eclipse и VS соответственно.
Цена порядка $2000 за одного пользователя Но это только для разработчика теста. Для Запуска плана тестов на исполнение достаточно одной лицензии SilkCentral, который будет запускать тесты на исполнение на необходимом количестве рабочих станций.
Лицензия на SilkCentral в такой же ценовой категории.
Да, цена снижается, это приятно. Плюс появился Централ.
На моем предыдущем проекте, использовался 5-й, 7-й и 10-й Силк одновременно. Тогда можно было купить Силк для разработчика за $5000 и Runtime за $3000 или $2000, точно не помню, в котором можно было только запускать тесты, но не писать.
Силк Централ, позволяет запускать тесты на неограниченном количестве машин?
Да, конечно, ограничений нет. Ставим Silk test на агентские машины, настраиваем Execution server Silk Central на каждой из них и вперед! проблем никаких. Если есть еще вопросы - спрашивайте, с радостью проконсультирую.
testomat.io управление авто тестами
Если тест хорошо написан, просто и понятно, живет в правильном неймспейсе/пакете… Почему тогда сложно его найти? Если cчитать що все в команде дружат с ІDE… 
с тем что увидели в текстах у меня 
