tag:blogger.com,1999:blog-40272639326954139332024-03-14T04:53:37.635+03:00Airguru"Ни надежность, ни функциональность программы не могут быть абсолютными, и ее качество в конечном счете означает разумный баланс между этими двумя характеристиками..." Сем Канер и др.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.comBlogger31125tag:blogger.com,1999:blog-4027263932695413933.post-19971800596817820512011-11-29T13:51:00.004+04:002011-11-29T14:05:28.786+04:00Wanted: QA LeadКоллеги, наша компания (labs.mind.com) все еще (уже как полтора года) стремительно растет и развивается. <br /><br />Поэтому, <br /><br />Если вам понятно, что написано в этом блоге;<br />Если вы с этим согласны или считаете, что что-то можно сделать лучше;<br />Если вы обладаете опытом работы в тестировании и автоматизации сего процесса (обязательно) более 2 лет;<br />Если вы знаете как минимум 2 скриптовых языка (один из которых JScript) и 1 высокоуровневый;<br />Если у вас есть опыт проведения нагрузочного тестирования (не только сторонними средствами, но и самописными (+допиливание оных));<br />Если вы можете подробно рассказать о тестировании на русском и английском языках;<br />Если вы прочитали более 5 книг по тестированию;<br />Если вы еще не устали учиться и добывать знания;<br />Если в голове полно креатива);<br /><br />а также:<br />Если вам нравятся сверхинтересные, сложные проекты (например, imind.com, e.mind.com), работа в высокопрофессиональном коллективе, возможности безграничного обучения;<br />(sal. from 70kRUR);<br /><br />Пишите- будем общаться) ибо <br /><br />Открыта вакансия на позицию ведущего тестировщика (впрочем, вакансий открыто несколько).<br /><br />/Достойным поможем переехать, если будет такая необходимость.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com3tag:blogger.com,1999:blog-4027263932695413933.post-49759153316608216552010-09-15T17:47:00.003+04:002010-09-15T17:56:57.779+04:00Розыск еще одного тестировщикаКоллеги, наша компания стремительно растет и развивается. Поэтому, <br /><br />Если вам <span style="font-weight:bold;">понятно</span>, что написано в этом блоге;<br />Если вы с этим согласны или считаете, что что-то можно сделать лучше;<br />Если вы обладаете <span style="font-weight:bold;">опытом</span> работы <span style="font-weight:bold;">в тестировании</span> и <span style="font-weight:bold;">автоматизации</span> сего процесса (обязательно) более 2 лет;<br />Если вы <span style="font-weight:bold;">знаете</span> как минимум 2 скриптовых языка (один из которых JScript) и 1 высокоуровневый;<br />Если у вас есть <span style="font-weight:bold;">опыт </span>проведения <span style="font-weight:bold;">нагрузочного тестирования</span> (не только сторонними средствами, но и самописными (+допиливание оных));<br />Если вы можете подробно рассказать о тестировании на русском и английском языках;<br />Если вы прочитали более<span style="font-weight:bold;"> 5</span> книг по тестированию;<br />Если вы еще <span style="font-weight:bold;">не устали учиться</span> и добывать знания;<br />Если в голове полно <span style="font-weight:bold;">креатива</span>);<br /><br />а также:<br />Если вам нравятся сверхинтересные, сложные проекты, работа в высокопрофессиональном коллективе, и офис гугла);<br />(sal. from 70kRUR)<br /><br />Пишите- будем общаться) ибо <br /><br />Открыта вакансия на позицию тестировщика.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-88550705495269444072010-05-28T16:39:00.002+04:002010-05-28T16:42:14.825+04:00система управления требованиямиТем, кто в поисках такой системы предлагаю списочек:<br /><br />Requirements Management Software<br /><br />Accompa <br /> Accept 360<br />Active!Focus<br />AnalystPro<br />Caliber-RM <br />Clariys<br />CORE <br />Cradle<br />DOORS & DOORSrequireIT <br />Enterprise Architect<br />GatherSpace <br />GMARC<br />IRqA <br />Jama Contour<br />Leap SE <br />Lighthouse RM<br />Mac A&D and Win A&D <br />MKS Requirements<br />objectiF <br />Open Source RM<br />Optimal Trace <br />PACE<br />PixRef Pro <br />Polarion Reqs<br />Projectricity <br />Rally<br />RaQuest <br />Reconcile<br />Reqtify <br />Requirement Tracing System<br />Requisite Pro <br />RMTrak<br />RTM Workshop <br />SoftREQ<br />SpiraTest <br />Teamcenter<br />TestTrackRM <br />TopTeam Analyst<br />Tracer (free) <br />TRUEreq (free)<br />XTie-Requirements Tracer<br /><br />Взято отсюда:<br /><br />http://www.jiludwig.com/Requirements_Management_Tools.htmlAndreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com3tag:blogger.com,1999:blog-4027263932695413933.post-55851030742297375882010-04-15T15:28:00.003+04:002010-04-16T15:56:10.001+04:00Внимание: розыск тестировщикаЕсли вам <span style="font-weight:bold;">понятно</span>, что написано в этом блоге;<br />Если вы с этим согласны или считаете, что что-то можно сделать лучше;<br />Если вы обладаете <span style="font-weight:bold;">опытом</span> работы <span style="font-weight:bold;">в тестировании</span> и <span style="font-weight:bold;">автоматизации</span> сего процесса (обязательно) более 2 лет;<br />Если вы <span style="font-weight:bold;">знаете</span> как минимум 2 скриптовых языка (один из которых JScript) и 1 высокоуровневый;<br />Если у вас есть <span style="font-weight:bold;">опыт </span>проведения <span style="font-weight:bold;">нагрузочного тестирования</span> (не только сторонними средствами, но и самописными (+допиливание оных));<br />Если вы можете подробно рассказать о тестировании на русском и английском языках;<br />Если вы прочитали более<span style="font-weight:bold;"> 5</span> книг по тестированию;<br />Если вы еще <span style="font-weight:bold;">не устали учиться</span> и добывать знания;<br />Если в голове полно <span style="font-weight:bold;">креатива</span>);<br /><br />а также:<br />Если вам нравятся сверхинтересные, сложные проекты, работа в высокопрофессиональном коллективе, и офис гугла);<br />(sal. from 60kRUR)<br /><br />Пишите- будем общаться) ибо <br /><br />Открыта вакансия на позицию ведущего тестировщика.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com9tag:blogger.com,1999:blog-4027263932695413933.post-30868588616145185412010-03-24T22:18:00.001+03:002010-03-24T22:25:52.317+03:00идеальный тест?оцениваем:<br /><br />http://www.computerpowertest.com/Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-38853033775351506442010-03-12T14:28:00.002+03:002010-03-12T14:32:13.524+03:00440 Web Test ToolsОчень внушительная подборка инструментов (440 штук!) для автоматизированного тестирования.<br /><br />зы: Не все краткие описания совпадают с действительностью.<br /><br /><br />http://www.softwareqatest.com/qatweb1.htmlAndreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-16426577660769272092010-03-12T13:41:00.002+03:002010-03-12T13:47:16.933+03:00Опять про собеседованияОчень понравилась статья Владимира Антонова "Собеседование специалистов или интервью как игра". Читая, вспоминал, как сам набирался опыта в этом плане..Особенно интересно, когда побывал на нескольких описанных позициях, например, на трех или больше.<br /><br />К предыдущему моему посту очень кстати)<br /><br />Взято отсюда:<br />http://www.protesting.ru/qa/interview_game.htmlAndreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-28490301307290812352010-02-27T11:28:00.007+03:002010-03-12T11:36:37.111+03:00как собеседовать кандидата на вакансию тестировщика?"оЧень осторожно" <a href="http://habrahabr.ru/blogs/hr/85427/">примеры</a>:)<br />главное- выявить нужного\подходящего из всего потока и сделать ему предложение, от которого он не откажется. <br /><br />вот и задача сформулировалась.<br /><br />теперь- к условиям.<br /><br /> необходимые:<br />1. кандидат должен быть способен выполнять его обязанности.<br />2. выполнять пункт 1 за плату, которая укладывается в рамки бюджета на позицию\отдел.<br />3. выполнять пункт 1 за время, которое укладывается в отведенные для этого сроки.<br /><br /> дополнительные:<br />здесь рассмотрим 2 варианта, обусловленных культурой процесса разработки в компании (отмечу, что оба приведенных варианта являются экономически оправданными на текущий момент, в условиях нашей действительности): <br /><br />А- компания заинтересована в профессиональном росте своих сотрудников. Компания не заинтересована в "утечке мозгов", в текучке.<br />Б- компания выбрала путь содержания "конвейера", когда существует некий постоянно обновляемый коллектив низкопрофессиональных сотрудников.<br />(пункты НЕ сортированы по значимости или как-то еще)<br /><br />для типа А:<br /><br />1. обучаемость и желание учиться;<br />2. способность находить стандартные и нестандартные решения вопросов в заданных рамках (временных, информационных, компетенции, лояльности);<br />3. умение применять полученные знания;<br />4. умение работать как в команде, так и самостоятельно;<br />5. инициативность;<br />6. понимание процессов (смысла, целей и методов) тестирования и разработки вцелом.<br /><br />для типа Б:<br /><br />1. способность четко выполнять поставленные задачи и соответствовать правилам и шаблонам;<br />2. внимательность;<br />3. исполнительность;<br />4. понимание процесса (смысла, целей и методов) тестирования;<br /><br /><br />Итак, сформулированы условия, удовлетворение которым нам и потребуется проверить.<br /><br />В принципе, не так уж и важно, как именно будут производиться эти проверки. Хоть на <a href="http://seljava.blogspot.com/2010/02/blog-post_8314.html">омлетах</a> с <a href="http://bugtrack-online.blogspot.com/2010/02/blog-post_15.html">кружками</a>, <a href="http://www.it4business.ru/forum/topic13738.html">чашками</a>, <a href="http://it4business.ru/forum/topic16551.html?mode=threaded&pid=73619">прочим</a> и <a href="http://bugtrack-online.blogspot.com/2010/02/blog-post_16.html">шнурками</a> (это все ссылки), хоть на реальных приложениях на принесенном ноуте и т.п. Важно, чтобы все они были проверены. Важно не путать одну проверку с другой и не делать поспешных ошибочных выводов. Если кандидат успешно справился с приложением на ноуте- преждевременно делать вывод, что он также справится с тестированием сложной незнакомой программы, в условиях ограниченного времени, ограниченных знаний (о продукте, о принятых правилах описания дефекта, о принятом глоссарии, например). Будь он трижды распрекрасным тестировщиком стандартных прог, мне не нужно, чтобы он тупил в ситуации, когда не ясно что вообще делать, а принимал какие-то (очень желательно- верные) действия, искал, узнавал, спрашивал и т.д. Мы калькуляторы не пишем, как и большинство других компаний. Стандартный тест даст (максимум) стандартные результаты (действия). Вам часто приходится тестировать стандартные вещи? Тест поля ввода даст понять, что кандидат умеет тестировать поля ввода. Не более. Как узнать может ли он придумывать и создавать сложные комбинации действий при тестировании? Как узнать может ли он делать выводы на основе полученной информации о том, где найденный баг может проявиться еще? Или какими действиями "дополнить" некий трабл до полного "crash"? Или что откинуть из действий, чтобы выявить саму суть бага? <br />А теперь думаем, какие вопросы надо задать, чтобы выявить эти умения и навыки. Без наводящих.<br /><br />Теперь по пунктам.<br />Необходимые:<br />1. сначала (до собеседования) составляем <a href="http://psyfactor.org/personal/personal15-08.htm">проффесиограмму</a> (ссыль). А затем думаем, какие вопросы нужно задать, чтобы узнать, в состоянии ли кандидат выполнять круг его прямых обязанностей.<br />2. есть лимиты на позицию (хотя бы в головах). оцениваем кандидата, "торгуемся", смотрим на получившуюся цифру и сравниваем ее с лимитами. Если лимитов нет- можно загуглить. Проблема в том, что почти все кандидаты завышают свой уровень (<a href="http://www.slideshare.net/Cartmendum/traininglabs09-part-4-of-4">"персики и лимоны"</a> у Дорофеева (ссыль)). Вопрос 1- на сколько. Вопрос 2- на сколько завышенный уровень мы можем себе позволить.<br />3. прямые вопросы (сколько времени занимало то или иное ("простое и сложное") действие на прошлом месте работы), косвенные (попросить выполнить какую-то активность (составить набор тестов (юз кейсов), протестировать, решить задачу и т.д.).<br /><br />дополнительные:<br /><br />для типа А:<br />1. поставить задачу, сказать как искать решение.<br />2. поставить задачу, НЕ сказать как искать решение.<br />3. применить пункт 1 на практике.<br />4. прямые и косвенные вопросы (как было, как хотелось, что нравилось, что- нет).<br />5. сколько и каких вопросов задал в пункте 2?<br />6. :)<br /><br />для типа Б:<br />1. поставить задачу, посмотреть на результат выполнения. <br />2. добавить в пункт 1 хитрое условие.<br />3. опыт прошлого.<br />4. :)<br /><br />Очень думаю, что перечислил далеко не все. Со временем дополню. <br /><br />Не забываем вести беседу так, чтобы кандидат в ужасе не убегал с собеседования, перекрещиваясь пяткой (относится к части о предложении).:<br /> А предлагать надо только то, что сможешь выполнить. Никогда не нужно обещать того, чего не сможешь выполнить (<a href="http://motivateme.ru/book/">"не мешайте мне работать" Стас Давыдов</a> (ссыль)). Тем более возможно твоему будущему сотруднику.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://xage.ru/upload/marks/0808/questions/2765642306_fb64f6c3d7_o.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 450px; height: 308px;" src="http://xage.ru/upload/marks/0808/questions/2765642306_fb64f6c3d7_o.jpg" border="0" alt="" /></a>Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com3tag:blogger.com,1999:blog-4027263932695413933.post-210541350846801742010-02-11T11:22:00.008+03:002010-02-11T12:50:05.823+03:00Спецификация на ПО (шаблон)Для тех, кто еще не знает, зачем пишутся спецификации- http://russian.joelonsoftware.com/PainlessSpecs/1.html <br /><br />Для тех кому лень- вкратце это выглядит так:<br /><br />Наиболее важная функция спецификации – проектирование программы (design the program). Даже если вы работаете один, и пишете спецификацию исключительно для себя, процесс ее написания – описание того, как работает программа до мельчайших подробностей – заставит вас непосредственно проектировать программу.<br /><br />Спецификации сокращают информационные потоки. Когда вы пишете спецификацию, вы должны только один раз выяснить, как программа работает. Каждый член команды может потом просто почитать спецификацию и выяснить интересующие его моменты.<br /><br />Без детальной спецификации невозможно составить план. Отсутствие плана не проблема, если вы пишете кандидатскую диссертацию и рассчитываете за ближайшие 14 лет ее закончить, или если вы программист, работающий над следующей версией игры Duke Nukem (мы выпустим ее, когда все будет готово и сделано на высшем уровне). Но почти в любой отрасли реального бизнеса вы просто обязаны знать, как долго все будет продолжаться, потому что разработка продукта стоит денег. Вы даже джинсы себе не купите, не узнав, сколько они стоят, так как же ответственный бизнесмен может принять решение, создавать или не создавать продукт, без информации о том, сколько это займет времени, и, следовательно, сколько это будет стоить?<br /><br />Написание спецификации – прекрасный способ точно выразить все раздражающие вопросы разработки, большие и маленькие, которые захлестнут вас, если у вас нет спецификации.<br /><br />Спецификации – это мать всего!<br /><br /><br /><br />Теперь непосредственно о форме и содержании:<br />(за основу взят шаблон "A Software Design Specification Template" by Brad Appleton. найти можно здесь: http://www.cmcrossroads.com/bradapp/docs/sdd.html)<br /><br />Введение:<br />Завершенная спецификация на ПО должна отвечать следующим критериям:<br />Она должна быть в состоянии адекватно служить в качестве учебного материала для новых участников проекта, давая им достаточно информации и понимания о ходе реализации проекта, с тем чтобы они могли понимать, что говорится о дизайне на собраниях и не почувствовать себя так, как будто они "тонут", когда им впервые предложат создать или изменить исходный код.<br />Она должна служить "объективным доказательством" того, что дизайнеры и/или программисты выполняют свои обязательства по реализации функций, описанных в спецификации требований.<br />Она должна быть как можно более подробной, но в то же время не быть слишком обременительной для дизайнеров и/или разработчиков, то есть не становится слишком трудной для создания и поддержки.<br /><br />Схема шаблона:<br /><br />Введение;<br />Обзор системы;<br />Вопросы проектирования:<br />-Предположения и зависимости;<br />-Основные ограничения;<br />-Цели и руководства;<br />-Методы разработки;<br />Архитектурные стратегии:<br />Стратегия-1 название или описание;<br />Стратегия-2 Название или описание;<br />...<br />Архитектура системы:<br />Компонент-1 Название или описание;<br />Компонент-2 Название или описание;<br />...<br />Политики и правила:<br />policy/tactic-1 название или описание;<br />policy/tactic-2 название или описание;<br />...<br />Детальное описание системы:<br />Модуль-1 Название или описание;<br />Модуль-2 Название или описание;<br />...<br />Глоссарий;<br />Библиография.<br /><br /><br />Порядок разделов этого документа соответствует порядку, в котором должны рассматриваются вопросы проектирования, и в котором принимаются решения в ходе самого процесса проектирования. Конечно, понятно, что проектирование программного обеспечения часто (а зачастую и к счастью) не всегда происходит в таком порядке (или в любом линейном или даже просто в предсказуемом порядке). Однако полезно для понимания структуры системы, представить их, как если бы они были сделаны так.<br /><br />Рекомендуется сохранять все обсуждения принятия тех или иных решений (в том числе истории переписки, логи и т.д., так как они являются единственным достоверным источником информации о принятых решениях).<br /><br />Далее по разделам:<br /><br />Введение:<br /><br />Предоставление обзора всего документа:<br />-описание назначения дока;<br />-границы\область действия;<br />-целевая аудитория;<br />-определение системы, используя подходящие имена, версии и т.д.;<br />-ссылки на другие используемые документы;<br />-взаимосвязанные документы;<br />-предпосылки;<br />-документы, описывающие фреймворк;<br />-документы, которые будут писаться на основе этого документа;<br />-определение важных понятий, сокращений, аббревиатур;<br />-краткое содержание.<br /><br /><br />Обзор системы:<br /><br />Дать общее описание системы, включая ее функциональность и вопросы, связанные с системой в целом и ее структурой (возможно, в том числе обсуждение основных подходов к проектированию и организации). Вы можете разделить это описание на подразделы и тд.<br /><br />Вопросы проектирования:<br /><br /><span style="font-style:italic;">В этом разделе описываются многие из вопросов, которые должны быть заданы или решены, прежде чем пытаться разработать комплексное решение дизайна.</span><br /><br /> -предположения и зависимости:<br /><br /><span style="font-style:italic;">Похожие программное или аппаратное обеспечение;<br />Операционные системы;<br />Характеристики конечного пользователя;<br />Возможные и/или вероятные изменения в функциональности.</span><br /><br /> -основные ограничения:<br /><br /><span style="font-style:italic;">HW и SW окружение;<br />окружение конечного пользователя;<br />наличие ресурсов;<br />соответствие стандартам;<br />требования совместимости;<br />требования интерфейсов и протоколов;<br />требования БД и транспортов;<br />требования безопасности;<br />ограничения памяти и производительность;<br />быстродействие;<br />сеть;<br />требования тестирования, тестопригодность;<br />другие значения требований качества;<br />другие требования.</span><br /><br /> -Цели и руководства:<br /><span style="font-style:italic;"><br />описываются любые цели, правила, руководства, приоритеты, которые влияют на структуру системы. Такие цели могут быть такими:<br /><br />(Сохранить это максимально простым и понятным;<br />(акцент на скорости работы, вместо ограничения выделения памяти;<br />(работать, выглядеть, ощущать продукт, как готовый;<br /><br /><br />Для каждой такой цели пишутся причины ее указания тут и причины принятия (если необходимо- в отдельном подразделе).</span><br /><br /> -Методы разработки:<br /><br /><span style="font-style:italic;">Краткое описание методов и подходов для проектирования и разработки системы. Если один или несколько официальных/опубликованных методов были приняты или адаптированы- необходимо включить ссылку на более подробное описание таких методов. Если несколько методов, были серьезно пересмотрены, то каждый из таких методов следует отметить, наряду с кратким объяснением того, почему все или часть его используется или не используется.</span><br /><br /><br />Архитектурные стратегии:<br /><br />Указываются любые проектировочные решения и стратегии, которые влияют на общую организацию системы и на ее структуру высшего уровня . Эти решения должны дать представление о ключевых вопросах и механизмах, используемых в архитектуре системы. Описываются рассуждения для каждого решения (возможно, ссылаясь на ранее определенные цели и принципы). Описываются причины принятия тех или иных решений, их изменения или отказ от них. Такие решения могут касаться (но не ограничиваются ими) вещей, вроде следующих:<br /><br /><span style="font-style:italic;">использование частных (сторонних) продуктов и инструментов- язык программирования, БД, библиотеки и т.д.;<br />повторное использование существующих компонентов системы;<br />планы на расширение и доработки;<br />используемые образцы интерфейсов (модели ввода\вывода);<br />примеры взаимодействия HW, SW;<br />обнаружение ошибок и восстановление после сбоев;<br />использование памяти;<br />внешние БД и СУБД;<br />распределенные данные и контроль над всей сетью распределения;<br />основные подходы к контролю;<br />распараллеливание и синхронизация;<br />механизмы взаимодействия;<br />управление другими ресурсами.</span><br /><br />Каждое значительное решение, вероятно, следует обсуждать в своем собственном подразделе либо (если оно достаточно сложное) в отдельном документе проектирования (с соответствующей ссылкой отсюда, конечно). Убедитесь, что при описании проектного решения вы также обсуждаете любые другие значительные альтернативы, и ваши причины для отказа от них указаны (а также ваши причины для принятия альтернативных решений, которые вы окончательно утвердили к принятию)<br /><br />Архитектура системы:<br /><br />Этот раздел должен предоставить общий (высокоуровневый) обзор того, как весь функционал системы был разделен, а затем назначен в подсистемы или компоненты. Не нужно вдаваться в подробности об отдельных компонентах (есть раздел для последующего подробного описания всех компонент). Основной целью является получение общего понимания того, каким образом и почему система разбита на отдельные части, и как отдельные части работают вместе, чтобы обеспечить требуемую функциональность.<br />На самом верхнем уровне описывается основной функционал. Что программное обеспечение должно выполнять и различные роли, которые система (или некая часть системы) должна играть. Описывается, каким образом эта система была разбита на ее компоненты/подсистемы (с указанием каждого компонента (подсистемы) верхнего уровня и распределения функций, возложенных на него). Описывается, как на более высоком уровне компоненты взаимодействуют друг с другом в целях достижения необходимых результатов. Не забудьте предоставить обоснования для выбора данного разбиения системы (возможно обсуждение других предлагаемых разбиений и описания, почему они были отклонены). Не стесняйтесь использовать шаблоны проектирования либо в описании части архитектуры (в формате шаблона ), либо в виде отдельных элементов архитектуры, которые их используют.<br />Если есть какие-либо схемы, модели, диаграммы, документированные сценарии или юз-кейсы поведения системы и/или структуры, они могут быть включены сюда (если вы не чувствуете, что они достаточно сложны, чтобы НЕ находиться в подробном разделе "Детальное описание системы"). Диаграммы, схемы описывающие конкретный компонент или подсистему должны быть включены в подраздел, описывающий этот компонент или подсистему.<br />Примечание: Этот раздел (и его подразделы) на самом деле относится только к новым разрабатываемым (или которые еще предстоит разработать) частям системы. Если есть части системы, которые уже существуют к началу разработки новых, то вам нужно описать только те уже существующие части, от которых новые части системы будут зависеть, и только в достаточной детализации, достаточной для описания взаимосвязей и взаимодействий между старыми и новыми частями. Прежние части, которые были изменены или расширены должны быть описаны лишь в той степени, которая необходима читателю, чтобы получить достаточное понимание характера изменений, которые были сделаны.<br /><br /><br />Архитектура подсистем:<br /><br />Если есть какой-то компонент, который заслуживает более подробного обсуждения, чем это было представлено в разделе "Архитектура системы", предусматривается, что более подробное описание будет в соответствующем подразделе раздела "Архитектура системы" (или даже может быть в более подходящем для описания компонента в своем собственном документе). Если необходимо, то опишите, как компонент был разделен на подкомпоненты, а также взаимосвязи и взаимодействия между этими подкомпонентами (аналогично тому, что было сделано для верхнего уровня компонентов в разделе "Архитектура системы").<br />Если какой-либо подкомпонент считается также заслуживающим дальнейшего обсуждения,- опишите его в отдельном подразделе этого раздела (таким же образом). Добавляйте столько уровней/подразделов, сколько необходимо для того, чтобы читателю получить более высокий уровень понимания всей системы или подсистемы (но не забудьте оставить подробности для раздела "Описание системы").<br />Если этот компонент является очень большим и/или сложным, вы можете рассмотреть вопрос о документировании его структуры в виде отдельного документа и просто, в том числе, ссылки на него в этом разделе.<br /><br /><br />Политики и правила:<br /><br />Описываются любые политики, правила, тактические решения, которые не несут за собой архитектурных изменений. Т.е. они не будут существенно влиять на общую организацию системы и ее структуру высшего уровня, но которые тем не менее, влияют на детали интерфейса и/или осуществление различных аспектов системы. Такие решения могут касаться (но не ограничиваются ими) вещей, вроде этих:<br /><br /><span style="font-style:italic;">выбор специфических продуктов- компилятор, интерпретатор, БД, библиотеки и т.д;<br />инженерные компромиссы;<br />стандарты и правила кодирования;<br />протоколы подсистем, модулей, процедур;<br />выбор алгоритмов, паттернов;<br />планы по обеспечению отслеживаемости реализуемых требований;<br />планы тестирования;<br />планы поддержки системы;<br />нтерфейсы для конечных пользователей, программного обеспечения, оборудования и коммуникации;<br />иерархическая организация исходников по файлах, директориям, компонентам;<br />компиляция, сборка и т.д.</span><br /><br />Каждое конкретное правило или набор правил должны быть вероятно обсуждены в конкретном разделе или (при случае большого или комплексного набора правил) в отдельном документе (с соответствующей ссылкой из этого документа, конечно). Убедитесь, что пока вы описываете решение по архитектуре, дизайну, вы также не забываете рассматривать и описывать альтернативные варианты и причины для отказа от них.<br /><br /><br />Детальное описание системы:<br /><br />Большинство компонентов, описанных в разделе "Архитектура системы" потребует более детального обсуждения и описания. Другие компоненты (нижних уровней) и подкомпоненты возможно, необходимо будет также описать . Каждый подраздел этого раздела будет ссылаться или содержать подробное описание программных компонентов системы. В ходе обсуждения должны быть охвачены следующие атрибуты компонентов программного обеспечения:<br /><br />классификация: вид компонента, такого как подсистема, модуль, класс, пакет, функция, файл и т.д.;<br />определение: специфическое назначение и значение компонента в системе. Может понадобиться ссылка на спецификацию требований;<br />функции и поведение компонента: Что должен выполнять этот компонент? Какие роли он играет? Какие виды сервисов он предоставляет для клиентов\пользователей? Для некоторых компонентов здесь может быть необходима ссылка на требования;<br />Ограничения: Любые уместные ограничения, лимиты для этого компонента. Здесь должны быть указаны ограничения по времени, объему данных, состояниям компонента, может включать в себя правила для взаимодействия с этим компонентом (охватывающие предварительные условия, постусловия, инварианты, другие ограничения на входе или выходе, форматы (типы) данных и доступ к данным, синхронизация, исключения и т.д.);<br />Состав: описание использования и важности субкомпонентов, которые являются частью этого компонента;<br />Использование\взаимодействие: описание взаимодействия с другими компонентами. Какие другие компоненты используются этим компонентом? какие используют данный компонент (здесь необходимо включить описание влияния на другие части и компоненты, которое может иметь данный компонент). Объектно-ориентированный дизайн должен содержать описание любых известных или предполагаемых подклассов, суперклассов и метаклассов;<br />Ресурсы: описание всех управляемых, находящихся под влиянием этого компонента, а также необходимых ресурсов. Ресурсы являются внешними элементами при проектировании, например, память, процессоры, принтеры, БД или библиотеки. Здесь должно быть включено обсуждение всех возможных условий и возможных блокирующих проблем, а также пути их решения;<br />Обработка: описание того, как компоненты действуют, выполняя функционал, который они должны выполнять. Это должно включать в себя описание всех алгоритмов, изменения состояний; соответствующие временные или пространственные сложности; параллельность, методы создания, инициализации, а также очистку; обработку исключений;<br />Интерфейсы\экспорт: набор сервисов (ресурсы, данные, типы, ограничения, процедуры и исключения), которые предоставляются этим компонентом. Четкое определение и объявление каждого такого элемента должно быть актуальным, с комментариями и аннотациями, описывающими значения величин, параметров и т.д. для каждого сервиса;<br /><br />Значительная часть информации, которая появляется в этом разделе не обязательно должна содержаться отдельно от исходного кода. В самом деле, большую часть информации можно почерпнуть из самих исходников (особенно, если они адекватно комментированы). Данный раздел не должен копировать или воспроизводить информацию, которую можно легко получить из чтения исходного кода (было бы нежелательно дублировать усилия, также будет очень трудно быть в курсе послених изменений). Рекомендуется, чтобы большая часть этой информации содержалась в исходниках (с соответствующими комментариями по каждому компоненту, подсистеме, модулю, и подпрограмме). Таким образом, ожидается, что этот раздел будет в значительной степени состоять из ссылок (выдержки из аннотированных схем) и исходного кода.<br /><br />Глоссарий:<br /><br />Все участники создания системы должны говорить на одном языке (правильно понимать друг друга). см. пост "заведи себе глоссарий".Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com1tag:blogger.com,1999:blog-4027263932695413933.post-45811259472550636032010-02-10T11:27:00.001+03:002010-02-10T11:31:12.531+03:00Управление конфигурациямиВсе разложили по полочкам авторы Новичков Александр, Лапыгин Дмитрий:<br /><br />http://anovichkov.msk.ru/?p=598<br /><br /><br />А также "Конфигурационное управление<br />(Software Configuration Management по SWEBOK)":<br /><br />http://swebok.sorlik.ru/6_software_configuration_management.htmlAndreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-67848484685345569242010-02-04T15:11:00.004+03:002010-02-05T10:25:52.776+03:00свободное время тестировщиковсвободное время тестировщиков<br /> <br />Болтон предлагает использовать его так:<br />1. неописанные тесты (небольшие);<br />2. рискованные значения (негативные тесты, граничные условия);<br />3. сделать ошибку и вернуться на шаг или больше назад. пользователи совершают ошибки. обработка ошибок и восстановление являются наиболее уязвимой частью программы;<br />4. посветить время просмотру справочной информации, относящейся к проекту;<br />5. вести блог, вики (профессиональные);<br />6. продакшн баги и предложения переводим в тестовые идеи и непосредственно ТС;<br />7. написание простых программ, которые позволят сэкономить в будущем время, повышение опыта программирования (вот оно- слияние автоматизации и ручного тестирования);<br />8. помочь коллегам:)<br />9. осмотреть свое тестовое окружение, определить новые риски, записать новые тестовые идеи, сделать предложения..<br />10. самообучение -> применение новых знаний к проекту, оформление отчета в виде вики.<br /><br />ЗЫ:<br />Рекс (Rex Black, www.rbcs-us.com) упомянул мой пробный перевод в ньюслеттере: <br />" Critical Testing Processes Introduction - in Russian!<br /> <br />We receive frequent requests from all over the globe to translate our articles, publications and Rex Black's books into other languages. Most recently Andrey Punin requested that he translate the introduction to Rex Black's acclaimed book, Critical testing Processes, into Russian. <br /> <br />Andrey works as a test lead in a large software company in Moscow, Russia. His experience covers test automation, test team planning and management, development of test strategy, test department creation, coaching, and transfer of test activities from one country to another (within one large software company). He has written several articles on software testing. He also enjoys translating software testing articles from English to Russian.<br /> <br />To see the translation, visit our Basic Library page."<br />Скоро закончу перевод очередной статьи.<br />Также на подходе много новых статей и заметок.<br /><br />\Просто не было времени. Совсем.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-42248048293713814652009-12-03T17:46:00.002+03:002009-12-03T17:47:53.435+03:00Кто тестировал год назад<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgG-QzP_833gR5yDN_8wGIA1F8N_Bfg2vETa1wY2_P8HLh6zAFjQ2gaTcrSH4R-V9M3HCAzDDn_RaMT6TRWsJGI64l1Hm1I16dk3YLQQQj8k-G-RKGra2FPbCKcEnyik6MFOm9SCM50oHeZ/s1600-h/stat2.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 343px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgG-QzP_833gR5yDN_8wGIA1F8N_Bfg2vETa1wY2_P8HLh6zAFjQ2gaTcrSH4R-V9M3HCAzDDn_RaMT6TRWsJGI64l1Hm1I16dk3YLQQQj8k-G-RKGra2FPbCKcEnyik6MFOm9SCM50oHeZ/s400/stat2.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5411021511824850194" /></a><br /><br />Занятные результаты.<br />Взято опять с http://habrahabr.ru/blogs/testing/45899/Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-90598797390875964782009-12-03T17:25:00.003+03:002009-12-03T17:28:27.845+03:00Где хранят ручные ТС<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjdEZyNfBd9E9ooKsP0qX1UNPLewbVUsdlzrD9l_hxFyWyBg3LieqrNPcOYLYb80HRY_NU5C0UujhNxZqjQ13KIOuzfr3q6E9vMEiu9MPC6xqMQonMDLecNjNS9isNyGDWcka3xyjqLirm-/s1600-h/stat.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 343px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjdEZyNfBd9E9ooKsP0qX1UNPLewbVUsdlzrD9l_hxFyWyBg3LieqrNPcOYLYb80HRY_NU5C0UujhNxZqjQ13KIOuzfr3q6E9vMEiu9MPC6xqMQonMDLecNjNS9isNyGDWcka3xyjqLirm-/s400/stat.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5411016254333330226" /></a><br /><br /><br /><br />Такие вот любопытные результаты.<br />Взято с хабра: http://habrahabr.ru/tag/test%20management/Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-3657086340143500562009-11-16T04:11:00.005+03:002009-11-16T15:29:04.091+03:00Переводы статей по тестированиюС любезного согласия Рекса Блэка (Rex Black, www.rbcs-us.com) буду публиковать переводы его статей по тестированию. Очень много полезной и важной информации.<br /><br />Первая статья, как вступление:<br /><br /> Критичные процессы в тестировании программного обеспечения (ПО)<br /><br /><br />Рэкс Блэк: Президент и главный консультант компании<br /> RBCS, Inc., Bulverde, TX<br />Ключевые слова (теги): Тестирование ПО, критичный процесс тестирования,<br /> управление тестированием, проекты разработки ПО,<br /> проекты сопровождения и поддержки ПО, <br /> автоматизация тестирования, ручное тестирование.<br />Аудитория: Руководители тестировщиков, ведущие тестировщики, менеджеры проектов,<br /> тестировщики, руководители разработчиков, менеджеры конфигураций.<br />Перевод с английского: Андрей Пунин (anairguru@gmail.com).<br />Оригинал: http://www.rbcs-us.com/software-testing-resources/library/basic-library<br /><br />Введение<br /><br />Как профессионалу в области тестирования с почти двадцатилетним опытом в области компьютерных технологий, мне приятно видеть новую статью, посвященную нашей области, в журнале “Journal of Software Testing Professionals”, и я имею честь внести свой вклад, как редактор. Первой задачей в этой роли мне было предложено написать самому , а также сотрудничать с другими специалистами в области тестирования, чтобы получить цикл статей, отвечающих на вопрос: “Что мы подразумеваем под критичными процессами в тестировании, которыми профессионалы в этой области должны владеть и управлять, чтобы добиться успеха?”. В каждой из этих статей мы будем подробно рассматривать один такой критичный процесс, предлагать практические советы: что уже работает и предостерегать от того, что может создать проблемы.<br /><br /><br />Содержание цикла<br /><br />Давайте начнем с определения: что такое этот цикл статей, и чем он не является?,- рассмотрим понятие “критичные процессы тестирования”. Процесс- это набор задач и активностей (действий для решения этих задач), некоторые из которых могут происходить одновременно, а некоторые- последовательно, друг за другом. Задачи и активности связаны желаемыми результатами, но в то же время не обязательно связаны с необходимыми техниками и требуемыми знаниями и навыками. Например, процесс автоматизации тестирования включает оценку объема работ, оценку и выбор инструментов и автоматизацию самих тест кейсов (написание скриптов). Одна их предстоящих статей будет посвящена этому процессу. Конкретные активности, посвященные автоматизации, думаю, оставим для других статей в этом журнале.<br /><br />Как я уже упоминал выше, критичный процесс- это процесс, которым вы, как профессионал в области тестирования, должны владеть для достижения успеха. Процесс становится критичным когда:<br />Вы часто повторяете этот процесс. Определенная, формализованная обработка повторяющихся процессов приводит к последовательному и эффективному выполнению ваших повседневных обязанностей. Например, процесс записи дефекта в баг трекинговую систему происходит постоянно, во время выполнения тестирования.<br />В процесс вовлечены коллеги или кто-либо из руководства организации. Успешная работа над хорошо видимым коллегам или руководству процессом, создает репутацию компетентного, надежного сотрудника, которому можно доверить ответственное дело. На примере процесса автоматизации тестирования мы должны предоставить оценку объема работ, которая убедит руководство потратить тысячи доллларов на инструменты автоматизации тестирования, вместо выделения сотен человеко-часов на эти же объемы работ при ручном тестировании.<br />Последствия невыполнения процесса неприемлимы. Успешный профессионал в области тестирования является экспертом в управлении рисками качества. Например, для определения потенциальных неудач проекта, кто-то должен анализировать риски качества, которые могут оказывать критическое влияние на реакцию заказчика, и корректировать надлежащим образом процессы тестирования. <br /><br />В заключении, чтобы получить этот цикл практичным и содержательным, я выделю процессы, которые большинство профессионалов, определит как часть их текущей работы. Специализированные темы, разумеется, найдут свое место в журнале, но мы будем сохранять эти темы и статьи в центре общих интересов.<br />Я также буду использовать этот критерий при определении, какие из критичных процессов относятся к области тестирования ПО и поэтому находятся в рамках содержания этого цикла. Прежде чем дискутировать об определениях “процесса тестирования ПО”, давайте согласимся, что некоторые критичные процессы, которые “противостоят” многим из наших коллег, занятых тестированием, обязаны быть, в некотором смысле, критичными для процесса тестирования. Тем не менее давайте исключим процессы, общие для всех профессионалов, участвующих в разработке ПО. Под этим определением я буду включать статьи об измерении покрытия кода тестами и об управлении передачей релизов в тестирование, но я буду исключать описание поддержания хороших взаимоотношений с вашим менеджером или равномерного применения корпоративных персональных политик. Хорошая мысль- вероятно критичный процесс для тест менеджера не является критичным процессом для всего процесса тестирования ПО.<br /><br /><br />Типы и зависимости критичных процессов<br /><br />Я классифицирую процессы тестирования ПО как внутренние (в которые вовлечены люди только из команды тестирования) и совместные (в которые вовлечена еще одна или более команд). Я использую слово “совместные” вместо ”внешние” потому, что команды в эффективных компаниях принимают чужую работу, как позитивное “руки прочь”. Они не подбрасывают незавершенные или некачественные результаты работы через “организационные стены”. Совместные процессы могут заключать в себе принятие результатов работы от другой команды, предоставить результаты своей работы другой команде или и то и другое. Совместные процессы могут повлечь за собой последовательность работ, соединяющую множество команд. <br /><br />Например (см. Рисунок 1), на котором изображено упрощенное количество процессов (стрелок) и команд (окружностей), вовлеченных в процесс разработки ПО. На этой иллюстрации выполняемые тесты- внутренний процесс, так же как и запись их результатов. Предоставление отчетов об ошибках- совместный процесс, при котором осуществляется доставка данных команде разработки от команды тестирования посредством выполнения процесса тестирования (выполнения тестов). Предоставление результатов о ходе тестирования (статусе процесса)- совместный процесс, в ходе которого тест менеджер сообщает команде менеджмента о ходе тестирования и оцененное с помощью чартов и метрик, понятных для команды менеджмента, качество продукта на текущий момент. В конце, выделим многостадийный совместный процесс, предоставления ПО команде тестирования, который я разбил ниже на несколько совместных подпроцессов, показанных круглыми скобками (стрелками) (имеется ввиду нижняя ветвь- Прим. перевод).<br />Так как организация тестирования представляет собой организацию, где сходится множество результатов и где достигнута независимость оценки качества, я предполагаю, что совместные процессы наиболее критичны с точки зрения организации.<br /><br />Также необходимо отметить, что множества независимых процессов, влияют друг на друга. Например, качество результатов процесса сообщения об ошибках влияет на качество результатов всего процесса тестирования, предоставляемых для менеджмента. Качество таких отчетов, в том смысле, что они добавляют свою погрешность в организации и формируют восприятие тестирования, как хорошего вложения средств, влияет на способность тест менеджера в будущем обосновывать запрошенные для выполнения работ ресурсы. Эти ресурсы- необходимые условия для работ по обеспечению качества при выполнения тестирования, включая отчеты об ошибках. На данном рисунке процесс включает все пять команд и показывает, как результаты тестирования определенного релиза могут влиять на внутреннее содержание последующих релизов. Возникает большое количество таких отчетов-петель, и мы посмотрим, как ими управлять.<br /><br />Рисунок 1.<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJEWqTN02Ar3Qe9bOLX5sOR3-VkxlM3s2c-IpyUeVGTHsP_MA4xRx6hRrig2qPKmAidwLsAabAta9zT4RlKMUGdioRplW-5TABnYVYk5CKLsqFHKtVBQwxAQkVPplUpva_r0u0DgTt06bS/s1600/Figure+1.jpeg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjJEWqTN02Ar3Qe9bOLX5sOR3-VkxlM3s2c-IpyUeVGTHsP_MA4xRx6hRrig2qPKmAidwLsAabAta9zT4RlKMUGdioRplW-5TABnYVYk5CKLsqFHKtVBQwxAQkVPplUpva_r0u0DgTt06bS/s400/Figure+1.jpeg" border="0" alt=""id="BLOGGER_PHOTO_ID_5404677022782566050" /></a><br /><br />Выбор критического процесса<br /><br />Разрешите мне предположить несколько критических процессов, в качестве анонса следующих статей, которые будут содержать несколько следущих ежеквартальных изданий журнала.<br /><br />Планирование и оценка объемов работ по тестированию. Планирование объема работ- это не то же самое, что и написание тест кейсов. Тестирование включает много логистических и организационных факторов, о которых тест менеджер должен подумать до того, как тест кейсы будут написаны. Планирование также включает сбор фактов от многих участников и оценку поддержки коллегами и руководством вашего плана. Мы посмотрим на различные процессы и стандарты, которые существуют для планирования тестирования и которые помогут подобрать правильные для вашей организации.<br />Риски оценок и риски управления качеством. Тестирование- это прежде всего задача управления рисками, но иногда мы не понимаем критичных рисков качества, пока не начнем тестировать. В будущей статье мы поговорим о путях выстраивания наших систем тестирования совместно с заказчиками, пользователями, и другими заинтересованными сторонами, чтобы быть уверенными, что мы тратим наши ресурсы на правильное тестирование.<br />Тестирование релизов сопровождения ПО. В то время, когда тестирование разработки получает больше всего обратной связи, процесс тестирования релизов сопровождения позоционируется как процесс с набором труднореализуемых, но быстрых изменений. Срочный патч для критического бага требует больше различных методов, подходов тестирования, чем регулярный релиз по расписанию. Поэтому гибкие процессы обязательны. Мы представим наборы методов, включая дискуссии о сильных и слабых сторонах каждого их методов.<br />Измерение и увеличение тестового покрытия. Как мы можем оценить контрольный показатель по достижении которого, можно будет судить о достаточном покрытии кода тестами? Мы обычно измеряем покрытие в строках кода, при помощи спецификаций, требований, но существуют другие показатели. Статья будет содержать опрос сообщества профессионалов в тестировании об их техниках.<br />Распределение объема тестирования. С появлением аутсорсинга, офф-шор вендоров и многофункциональных ИТ практик, как частей разработки ПО (больших и маленьких), какая-либо организация имеет возможности увеличивать тестовые возможности своих партнеров и свои собственные. Также тестовые лаборатории, контракторы и консультанты предоставляют ресурсы для заполнения недостающих ваших собственных ресурсов. Статья будет содержать материалы о том, как координировать различные группы тестировщиков, вовлеченных в процесс и определенных для достижения результатов каждым из них, а также коммуникации и обмен информацией между ними.<br />Динамическое распределение приоритетов в тестировании. Большинство тестировщиков соглашаются, что они не могут выполнить все их тесты за отведенное время. Иногда слишком мало времени отведено на разработку тестов, приводящее к необходимости прокрытия многочисленных тестовых условий малым количеством тест кейсов. Давайте посмотрим на пути разработки эффективных тест кейсов и приоритезируем эти пути для достижения высокоуровневого риск менеджмента независимо от сроков.<br />Распределение ролей в команде тестировщиков, этапы их привлечения в тот или иной процесс в мастштабах всей организации. Процесс тестирования не должен напоминать собой “детский футбол”: когда множество людей бегает за мячем на большом поле и пытаются ударить по мячу. Благодаря использованию этапов (стадий) тестирования каждая команда занимает правильную позицию в тестировании продукта. Достигнув уверенности, что команда остается на правильных этапах (стадиях) тестирования (и только тестирования), заботливый тест менеджер сохранит свою команду эффективной. Статья будет содержать обсуждения фокусирования на нужных объемах работ тестирования, включая сложные межведомственные отношения и менеджерские рассуждения о том, как тест менеджер должен организовать остальных для выполнения определенных видов тестирования.<br />Сбор требований и спецификаций. Вы когда-нибудь замечали, что тестируйте приложение при существенном или полном отсутствии информации о том, как приложение должно себя вести при различных условиях? Метод “научного тыка”, расспросы коллег, сравнение вашего приложения с конкурентными и прием во внимание пожеланий заказчика- это все части единого процесса решения таких проблем. Мы посмотрим и на другие пути решения этих проблем.<br />Развитие и поддержка тестовой системы. Статический набор тестов страдает от того, что доктор Борис Бейзер называет “парадоксом пестицида”: этот набор может стать менее эффективным, так как разработчики учаться избегать ошибок, которые находятся тестами (и, разумеется, исправляют существующие ошибки – Прим перевод.). Мы будем изучать процессы, которые постоянно улучшают наборы тестов, добаляют новые тесты, устраняют устаревшие тесты и апдейтят существующие тесты в соответствии с изменяемыми требованиями и условиями.<br />Построение тестового репозитория. Тестовые системы состоят из тестовых условий, тест кейсов, тестовых инструментов, наборов тестов и других объектов. В неоднородных условиях эти объекты распростроняются на различные Ос`и, языки программирования и даже на различные команды тестирования. Вы можете построить или купить систему, которая бы позволила вам управлять этими разрозненными частями? Давайте посмотрим на техники построения и использования таких самописных инструментов и на коммерческий софт для управления тестированием.<br />Управление релизами и конфигурациями в управлении тестированием. Тестируемый софт не должен просто появляться магическим образом в тестовом окружении, так же как и тестовые среды не должны магическим образом конфигурировать себя вокруг доставленного кода. Плавное течение софта от разработчиков к команде тестирования в лабораторию тестирования, с четким контролем результатов установок, требует тотального менеджмента и эффективных коммуникаций, часто в бытро меняющихся условиях. Будущая статья рассмотрит ключевые моменты в этих областях вместе с примерами менеджмента релизов и конфигураций, сделанных корректно и наоборот- недостаточно верно.<br /><br />Как я упоминал выше, вы можете не иметь ответственности за все эти процессы, но эти процессы имеют прямое влияние на успех вашей организации. Эти кросс-функциональные процессы имеют такое же влияние на менеджмент, как техническая подкованность и поэтому я рассматриваю их с особым интересом. Также у меня есть специально отобранные неприметные и невзрачные процессы для примеров. Потому что скучный - не значит не имеющий значения. Вы можете не получить апплодисментов от вашего менеджера, что релизы по плану поступают в тестовые лаборатории, но отсутствие управления таким процессом должно заострить внимание на направильном подходе к процессу.<br /><br /><br />Обращение к участникам:<br /><br />Авторы этой серии статей, включая и меня, будут базировать свои эссе на реальных случаях, на опыте реальных проектов, а также на опросах сообщества профессионалов в области тестирования. Эта серия статей будет использовать коллективный опыт группы людей, работавших над сотнями проектов. Каждый проект учит чему-то профессионала в управлении критичными процессами. Более того, у некоторых из них имеются анекдотические случаи, а также множество данных, чтобы поделиться ими. Благодаря “руководящему” подходу каждая статья будет предоставлять набор действий, который вы можете применить, чтобы улучшить ваши процессы тестирования.<br /><br />Как и у ваших коллег- профессионалов в тестировании, у вас также может быть ваш собственный набор методов и идей. Как читатель этого журнала вы можете судить о том, какой же процесс является критичным. Следуя руководствам и правилам журнала вы можете публиковать свои аннотации к статьям. Если вы “боретесь” с критичными процессами и хотите учиться у своих коллег- дайте мне знать. Я за всестороннее общение с читателями. Мой e-mail написан ниже.<br /><br />Эта серия статей о том, как мы, как профессионалы в тестировании, можем быть успешными в наших наиболее важных ролях. Я призываю каждого к участию в дискуссиях, особенно если вы хотели бы поделиться мыслями, решениями и предупреждениями о критичных процессах.<br /><br />Об авторе:<br /><br />Рэкс Блэк (Rex_Black@RexBlackConsulting.com) – президент и главный консультант компании “Rex Black Consulting Services Inc.” (http://www.RexBlackConsulting.com) – международной консультационной компании в областях тестирования и обеспечения качества. Он и его компания предоставляет помощь их клиентам в применении, передаче знаний, а также наборе персонала для работы над процессами тестирования и обеспечения качества. Его книга “Управление процессами тестирования” была публикована в июне 1999 года издательством “Microsoft Press”.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-84149119764203293752009-11-03T09:43:00.000+03:002009-11-03T09:44:28.969+03:00Статья про Контекстное тестированиеАлексей Лянгузов грамотно все описал http://www.software-testing.ru/library/testing/general-testing/847-context-driven-testing<br /><br />Рекомендуется к запоминанию.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-22281098177721356022009-10-26T10:01:00.000+03:002009-10-26T10:05:24.132+03:00Exploratory Testing DynamicsJames Bach опубликовал новый документ, описывающий Exploratory Testing. Очень интересный док. Чего только стоит: "Imagine a problem, then find it." <br />Рекомендую к прочтению.<br /><br />http://www.satisfice.com/blog/wp-content/uploads/2009/10/et-dynamics22.pdfAndreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-60404668059475919962009-10-16T11:20:00.000+04:002009-10-19T17:17:30.986+04:00Постановка задачи тестирования<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVoc7Bbo7aUAYAmJxKyCMxwBRZW004XZe9ICz-VjbyVm2nv76X8hSGn3UCd5jYxDYF-rT71Wm_4YjP42hgPw7wInLlibpwlvAiRpb42bdjLuwJ7olT3uCATDQiVgqWHd2gwc9QY3Ni922T/s1600-h/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD1.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 312px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVoc7Bbo7aUAYAmJxKyCMxwBRZW004XZe9ICz-VjbyVm2nv76X8hSGn3UCd5jYxDYF-rT71Wm_4YjP42hgPw7wInLlibpwlvAiRpb42bdjLuwJ7olT3uCATDQiVgqWHd2gwc9QY3Ni922T/s400/%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD1.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5394299585016789570" /></a><br />В очередной раз поставили задачу максимально некорректно. Типа: "У нас обновление такое-то. Потестируй там что-нибудь..".<br />Нервы мои не выдержали, и я разразился очередным документом "Постановка задачи тестирования". Документ этот содержит список простых вопросов, ответы на которые необходимо получить перед началом тестирования. К сожалению, многие не понимают, что только корректная постановка задачи приводит к желаемому результату :(<br />Вполне допускаю, что список не совсем полный, но по мере необходимости буду дополнять и корректировать. Замечу, что эти вопросы перекликаются с вопросами, размещенными в предыдущем посте, но цели у них разные.<br /><br /> Постановка задачи тестирования<br />1. Что именно нужно тестировать? (дистрибутив, ссылки на веб клиенты).<br /><br />2. Вид тестирования (Функциональные (+уровни тестирования); Нефункциональные; Связанные с изменениями).<br /><br />3. Как тестировать? (что конкретно должно быть протестировано, что должно быть проверено обязательно, что дополнительно, что "если останется время").<br /><br />4. Где документация? (спецификация, требования).<br /><br />5. Когда и как долго тестировать? (сроки, время начала, если сразу нельзя начать)?<br /><br />6. Где тестировать? (адреса, ссылки, машины, ОСи, окружение)?<br /><br />7. Чем тестировать? (инструменты, файлы)?<br /><br />8. Где необходимые инструменты, артефакты? (файлы, базы, логины, пароли, учетные записи, сертификаты и т.д.).<br /><br />9. К кому обращаться за дополнительной информацией?<br /><br />11. Что делать с результатами?<br /><br />12. Необходим ли отчет? (если да- см. заявку на отчет).<br /><br />13. Критерии успешного (неуспешного) тестирования. (если необходимо дать оценку, заключение).<br /><br />10. Дополнительные инструкции.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com16tag:blogger.com,1999:blog-4027263932695413933.post-16417463611470831952009-10-09T12:05:00.000+04:002009-10-09T14:08:11.837+04:00Заявка на получение отчета о тестировании.Случай из жизни: руководитель группы разработчиков требует от отдела тестирования отчет о тестировании очередного небольшого проекта. Вроде бы стандартная ситуация, но:<br />1. руководитель группы разработчиков не знает что туда включить, а что нет;<br />2. непосредственно руководителю этот отчет не нужен (этот отчет хотят показать заказчику, чтобы снять с себя ответственность за неработающие вещи, к разработке которых наши разработчики не имеют отношения).<br /> <br />То есть требуют "то, сами не знают что".<br />Ну да- бывают ситуации, когда руководители (делают вид, что) не в курсе, что "если хочешь получить от коллег или подчиненных результат,- убедись что: все знают что сделать, как сделать, у них есть желание и средства для этого". <br />Опустим философию. Итак- есть проблема: чего-то требуют, чего именно не объясняют, на наводящие вопросы не отвечают\отвечают уклончиво. (причины этого тоже опустим.)<br />Как решать?<br /><br />Основная задача- информировать меня о том, что мне нужно сделать. На уровне руководства решаем это внедрением утвержденного регламента запроса на отчет. Другими словами- формализуем процесс. Таким образом исключая ситуации взаимонепонимания. Тебе нужен нормальный результат вовремя?- поставь мне задачу корректно.<br /><br />Воспользовавшись ресурсами it4business.ru, статьей в блоге "255 ступеней" (http://blog.shumoos.com/archives/190) оформил вот такой список вопросов, ответы на которые нужно включить в постановку мне задачи о написании отчета о тестировании.<br /><br />Заявка на получение отчета о тестировании.<br />Так как отчет о тестировании может быть сформирован множеством способов, зависящих от того, кому отчет? зачем? что на его основании будут делать?- при следующей необходимости написания отчета предлагаю вместе с постановкой такой задачи отвечать на вопросы:<br /> кому отчет?<br /> зачем? <br /> что на его основании будут делать?<br /> что нужно показать?<br /> указать, что работает или что не работает?<br /> другие комментарии.<br /> А также следует ли отвечать на вопросы вида:<br />1) Это можно продавать/устанавливать или нужно доработать/выкинуть?<br />2) Какова степень уверенности?<br />3) Как называется то, о чем идет речь?<br /><br />Обычно ответы на эти вопросы и хотят увидеть лица, принимающие решения.<br />Постановка задачи в виде: «напиши отчет в таком виде, чтобы его заказчику можно было отправить..», «напиши какую-нить таблицу», «сделай красиво» и подобные будут требовать дополнительных потерь времени участниками процесса.<br /><br />Что именно тестировать?<br />Как тестировать (что должно быть проверено обязательно, что дополнительно)?<br />Когда тестировать (сроки, время начала, если сразу нельзя начать)?<br />Где тестировать (адреса, ссылки)?<br />Чем тестировать (инструменты, файлы)?<br />Где необходимые приложения (файлы, базы, логины\пароли, учетки, сертификаты и т.д.)<br />Инструкции.<br />Другое.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-5089210400392476572009-10-06T15:31:00.000+04:002009-10-06T16:52:24.974+04:00Корректность фиксов баговДолжны ли разработчики проверять корректность своих фиксов?<br />Проблема обсуждалась неоднократно на форуме проекта it4business.ru , в блогах и т.д. Попробуем разобраться в ситуации. <br /><br />Априори предполагаем наличие здравого смысла в организации процесса и ясность смысла проверок всем ясна. Итак, если проверки необходимы, то их кто-то должен делать- либо сами разработчики, либо тестировщики. Рассмотрим 2 варианта: 1- тестировщиков на проекте не достаточно; 2- тестировщиков достаточно для того, чтобы смотреть еще и за результатами фиксов, несмотря на то, что времени на тестирование всегда не хватает. Второй утопический случай можно смело отбросить) и поставить вопрос так: должны ли разработчики сами проверять не только корректность конкретного фикса, но и некоторое минимальное окружение вокруг этого фикса (бага)? То есть ограничиваться ли автору фикса проверкой только лишь того конкретного бага\проявления бага, который указан в баг репорте? Или все-таки включить мозг, попробовать другие действия, окружение и т.д. <br /><br />Понятно, что квалифицированный, профессиональный разработчик должен это делать, но часто приходится слышать такие вещи как "острая нехватка времени", "не приоритетная задача", "потом". <br />В случае, когда тестировщиков на проекте более-менее достаточно для того, чтобы проверять каждый фикс более подробно, выход из ситуации можно обеспечить количеством. Чем больше количество тестировщиков,- тем больше времени (в среднем) можно уделить на проверку конкретного фикса бага. <br /><br />Но что делать, если тестировщикам итак катастрофически не хватает времени? Вариант- расширить проверку фиксов разработчиками. (Допустим, что нет возможности нанять еще тестировщиков, что часто случается в последнее время). Ежу понятно, что этим мы жертвуем временем на разработку (кодирование). Но в целом, при подсчете общего затраченного времени (и того, которое я, как тестировщик, затрачу на поиск всех нюансов (проявлений) каждого бага, и на переоткрытие бага в баг трекинговой системе, и на объяснения с разработчиком и многое другое) картина будет выглядеть не столь ужасно, если не будет происходить тех действий, выполнение которых можно было бы предусмотреть и избежать. Я здесь не имею ввиду кривые баг репорты, нелокализованные дефекты и другие "косяки" тестировщиков. Имеется в виду только ограниченность проверки разработчиком. Если цель- иметь пусть "меньший", но проверенный, рабочий функционал, а не горы глючного кода, вполне можно организовать и обязательную проверку разработчиками своих собственных трудов. Я для этого написал небольшой список требований к такой проверке, который (не без помощи начальства (а лучше- активного участия)) внедряли в рабочий процесс.<br /><br /> Что получилось:<br /><br />Вобщем я решил, что такой регламент должен быть коротким, чтобы разработчикам было не лень его читать и применять. Также чтобы он описывал только основные моменты.<br />Смысл его введения:<br /> 1. Разработчики дожны проверять, что то, что они сделали (написали\пофиксили), работает вообще.<br /> 2. Разработчики дожны проверять, что то, что они сделали, работает корректно.<br /> 3. Разработчики дожны проверять (хотя бы в минимальной степени), что то, что они сделали, не ломает существующий, корректно работающий функционал.<br /> Можно переложить почти все эти проверки на тестировщиков при условии, что как максимум на 4 разработчиков будет 1 тестировщик. В нашем случае это без вариантов.<br />По опыту тестирования (конкретного софта) могу сказать, что очень много времени у меня уходило: на поиск существующих в системе баг трекинга баг репортов + их возвращение, комментирование; на запись похожих. При организации проверки фиксов разработчиками этого бы не понадобилось. А потраченное время я бы потратил на более серьезную проверку. <br /> <br />Проверка фикса (не только):<br />1. Время верификации каждого фикса не более 10-20 мин.<br />2. В первую очередь производится попытка воспроизведения бага (по описанным шагам).<br />3. Во вторую- анализ областей, в которых вероятно возникновение этого бага.(Например, если был обнаружен баг с фильтром, работающим при вызове какого-то меню, то имеет смысл проверить все схожие типы меню, работающих по такому же принципу.).<br />4. Проверка этих областей.<br />5. Анализ возможности вызова повторения бага другими методами (отличающимися от описанного в баг репорте (Например, если был обнаружен баг при удалении записи, имеет смысл проверить удаление группы записей и т.п.)).<br />6. Проверка этих методов.<br /> Минимальное свободное тестирование (специфично для определенного софта):<br />7. Проверка работы с некорректными данными (например, сохранение, поиск по ним).<br />8. Повторяющиеся действия (например, попытка удаления уже удаленного объекта, двойной импорт).<br />9. Проверка вывода обязательных сообщений (например, при сохранении с незаполненными<br />обязательными полями).<br />10. Если, например, теструется установка дистрибутива или импорт данных, имеет смысл<br />использовать виртуальные машины для одновременной проверки разного функционала или<br />параллельной проверки при различных условиях (пример- при тестировании импорта\экспорта удобнее и быстрее на одной машине произвести импорт, затем экспорт, а на другой- импорт этих экспортированных данных; с последующей одновременной проверкой данных).<br /><br />Все это опять же- FYI.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com2tag:blogger.com,1999:blog-4027263932695413933.post-46290516408190751912009-10-02T15:11:00.000+04:002009-10-02T15:15:58.127+04:00Относительная плотность баговОкунемся в теорию.<br />Рассмотрим такое теоретическое понятие как относительная плотность багов. количество багов на некоторую единицу, например, на единицу времени (неделя, итерация), на единицу разработки (фича, модуль), на рабочую единицу (тестировщик). Более всего интересно распределение количества по времени. Заметил, что с течением времени это количество не постоянно. Проанализировав, получил, что: значение плотности багов должно обычно изменяться с теченем времени, потому что:<br /> <br /> 1 низкая плотность в начале работы (обусловлено тем, что имеем новый продукт (софт\фича), вероятно, новые инструменты, новые люди); <br /><br /> 2 выше в середине работы (процесс налажен, всё известно, все знают зачем, что и как делать, у всех есть желание и возможность сделать свою работу);<br /><br /> 3 ниже к концу (известен предмет тестировани: проблема- примелькался продукт, к нему привыкли тестировщики; баги фиксятся+регрессионное тестирование дает свои плоды (позволяет разработчикам не повторять своих ошибок -это спорное утверждение, но именно с такой ситуацией я однажды столкнулся). <br /><br />Обозначились проблемы. Попробуем сделать выводы и найти решения проблем.<br />выводы:<br />1. четко регламентировать и описать процесс работы. (Что даст нам ускоренное знакомство с софтом, инструментами, людьми путем четкого распределения обязанностей (кто что делает и почему), источников информации (кто как делает, зачем делает и какими средствами). <br /><br />2. соблюдать инструкции и правила. (без этого предыдущий пункт можно вычеркнуть).<br /><br />3. как можно раньше ввести людей в курс дела, обучить. (Здесь имеется ввиду больше знакомство тестировщиков на ранних стадиях с требованиеями, с первыми версиями спека и т.д. А также знакомство новичков.).<br /><br />4. заранее продумывать пути совершенствования процесса, допустимые эксперименты. (Не лишним будет попробовать усовершенствовать тот или иной процесс (в пределах разумного) в рамках тестирования. Однако, такие эксперименты не всегда можно ставить- перед релизом, думаю, они чреваты:)) <br /><br />5. ревью тестов. (Изменяем\дополняем проверками, методами, которые раньше не проводились. Тут можно подумать, что первичный вариант тестов был не полным или неграмотным. Имеется ввиду- изменить проверки на аналогичные.). <br /><br />6. ротация людей по областям (не обязательно всех), взаимозаменяемость.<br /><br />7. смена типа, метода, подхода ручного тестирования (Прежде всего в области ad hoc, exploratory testing).<br /><br />8. контроль предпринятых мер и мониторинг результатов. (Незачем продолжать неэффективные способы).<br /><br />9. отслеживать % повторно открытых дефектов. (что позволит судить о таких вещах, влияющих на скорость разработки, как корректность баг репортов, корректность фиксов (ну должны же разработчики хоть немного смотреть на то, что они делают. В мое практике были случаи, когда баги фиксились методом лишь бы как-нибудь. Лечилось разговором с руководством и демонстрацией теряемого времени на возврат багов, заведение аналогичных, да и просто переводом с одного человека на другого)).<br /><br />Отдельно стоит заострить внимание на пунктах 6 и 7. Возможности их осуществления должны быть заложены при планировании работы всей группы тестрования над тем или иным проектом. Если вы, например, решаете зафиксировать деятельность отдельных тестировщиков в проекте, то будет затруднительно менять направление деятельности каждого. <br /><br />Рассмотрим сферического руководителя группы тетсирования в вакууме. В начале работы над некоторым проектом перед ним (и группой) стоят задачи: планирование тестов, дизайн тестов, разработка автотестов, выполнение тестов, предоставление результатов и оценка выполнения тестов. Вполне очевидно, что первые три задачи следует решить раньше других. Если учесть, что временные ограничения никто не отменял и делать это не собирается, то, чтобы добиться эффективной работы группы, необходимо на каждом этапе распределять работы так, чтобы максимально возможное количество сотрудников работало над теми задачами, которые необходимо решить в первую очередь. Например, на начальном этапе ставим задачу максимальному возможному большинству тестировщиков (здесь все-таки есть разумные ограничения- опыт в этой деятельности, другие задачи)- написание тест кейсов. Можно даже потерять немного времени на параллельное обучение тестировщиков, не имеющих опыта написания тест кейсов. Потери, конечно, должны быть разумными. А выигрыш в будущем за счет каждого нового обученного обеспечен (если он никуда не уйдет, но это уже совсем другая проблема). Далее. Когда большинство тест кейсов написано и готово к использованию- имеет смысл переключить часть сотрудников на непосредственно тестрование, а также на написание автотестов, если таковые предполагаются. Смысл в том, что появляется более приоритетная задача. Так как поддерживать тест кейсы в актуальном состоянии можно и не всем первоначальным составом. Как определить момент переключения на другую задачу? Делаем просто- переключаем постепенно. То есть сначала некое минимальное количество, а затем смотрим на успеваемость. И потом при необходимости добавляем людей на следующую задачу. Обращаем внимание, что в данном случае все участники рано или поздно сменят вид тестовой деятельности (по крайней мере между написанием и выполнением тестов). Как мне кажется, жесткая фиксация вида деятельности тестировщика имеет смысл лишь в том случае, когда проекты поставлены на поток, когда в любой момент времени нужно писать тест кейсы, вполнять их и так далее. В случае же, когда приоритет каждой задачи меняется с течением времени, выгодно иметь группу проффесионалов, которые смогут участвовать и в написании тестов, и в выполнении, и в работе по автоматизации... Таким образом мы сможем построить максимально эффективный процесс в каждый момент времени, имея возможность оптимально выстраивать\распределять работу над актуальными задачами, предотвращать задержки каких-то направлений из-за болезней, уходов сотрудников, а также имея возможность исправить несерьезные ошибки планирования перераспределяя ресурсы. Еще один выигрышный момент- когда низкая плотность багов обусловлена такой проблемой- примелькался продукт, к нему привыкли тестировщики,- при смене деятельности (не радикальной, хотя и такое может быть реализовано) получаем "незамыленные", свежие глаза и руки :) на каждом из направлений. Смена области приложения чередуется со сменой вида деятельности. Например, 6 тестировщиков, 2 модуля приложения, 3 задачи- написание ТС, их выполнение, написание автотестов. решаем проблему методом "каждый на каждой позиции". Тут нужно не забыть, что каждому понадобится различное время на знакомство, переключение на новый тип деятельности, различное время на выход на "максимальную скорость работы", и различное время на "замылевание", привыкание. При небольших по срокам проектах такая смена деятельности не оправдана. А также стоит учесть предпочтения самих тестировщиков. <br />А чтобы исключить взаимонепонимание, различные версии, интерпретации- необходимо воспользоваться первыми двумя пунктами выводов. <br /><br />Это не фиксированная модель. Можно что-то добавить, что-то убрать, в каких-то моментах добавить ротации сотрудников, в других наоборот- иметь более постоянный состав. Общий смысл- варианты решения обозначенных выше проблем. Не исключено порождение новых, но тут уже нужно взвешивать все плюсы и минусы и решать что же выгоднее в каждом конкретном случае.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-40834681876704133702009-10-01T14:04:00.000+04:002009-10-01T14:18:18.307+04:00Круговорот документацииПримерно полгода назад получил задание создать (воплотить в картинке) примерную схему оборота (использования) документации при разработке. Дело было еще до внедрения TFS. Но могу сказать, что после ее внедрения радикальных изменений не стал бы вносить в эту схему. Вот что получилось: <a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjL_w_SiM7ZdJgC5JbNiLLgcSak3Lu9AuMb2hKyVNl1th1urBzHbBQC14ScX-CV00WtTMKqEOHNfT0a-IlVLh9b4pmMdSwxvprHMWadMWMYjCiwxKmFQZR-oydvDacSQoPUSmXOrXsNiTd8/s1600-h/Documents_Exchange.jpg"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjL_w_SiM7ZdJgC5JbNiLLgcSak3Lu9AuMb2hKyVNl1th1urBzHbBQC14ScX-CV00WtTMKqEOHNfT0a-IlVLh9b4pmMdSwxvprHMWadMWMYjCiwxKmFQZR-oydvDacSQoPUSmXOrXsNiTd8/s400/Documents_Exchange.jpg" border="0" alt=""id="BLOGGER_PHOTO_ID_5387572564722073394" /></a>Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-37264457748009583292009-09-30T11:02:00.000+04:002009-09-30T12:17:37.106+04:00Заведите себе глоссарий (необходимость говорить на одном языке)Есть такая поговорка: "С кем поведешься, от того и наберешься". Это к рассмотрению ситуации, когда в отдел, например, тестирования приходит новый сотрудник. Он начинает общаться с коллегами и в процессе работы начинает говорить, писать (описывая ситуации, возникающие во время тестирования) так, как принято среди тестировщиков. Это нормально. То же самое происходит и в отделе, например, разработки документации. В пределах одного отдела все друг друга понимают практически без проблем (опустим ситуации, когда новый сотрудник совсем новый:)). Но вот когда коммуникации затрагивают несколько отделов такого понимания может и не быть. Ничего удивительного. Просто одни привыкли называть так, а другие- иначе. И оба варианта используются сотрудниками различных отделов различных организаций, то есть никто ничего нового не выдумывал. Хорошо, если ситуаций, где можно найти такие варианты различий, не много. (ну, допустим, характер софта такой). А если только в пределах одного направления разработки таких вариантов масса? Да к тому же существует разбивка как минимум на 3 отдела (документации, разработки, тестирования), а часто больше чем на 3. Наложим на все это распределенную на несколько стран разработку. Соответственно добавляются варианты, которые предлагаются иностранным языком. Но ведь английский русских разработчиков и английский разработчиков, например, из индии- 2 большие разницы. В итоге получаем столько определений одних и тех же вещей, с которыми не так-то просто и разобраться, не говоря уже о том, что временных задержек на это не должно быть вообще. Не трудно представить, сколько лишнего времени уходит на то, чтобы разобраться с баг репортом, понять суть бага. Чтобы избегать таких ситуаций, необходимо вывести некий глоссарий и в соответствии с ним называть вещи своими "уникальными" именами. За основу можно взять общепринятые понятия, которые наиболее часто встречаются уже (в переписке, в системе баг репорта и тд), на данный момент. Если разработка распределенная- то на английском языке. Как правило, наборы готовых требований к разрабатываемому софту уже содержат большинство понятий и определений. Этим стоит воспользоваться и принять за основу. <br />К чему это все? Коммуникации должны быть эффективными. С точки зрения тестирования это своевременный, точный, однозначный отчет\репорт о положении дел. Если это баг репорт- то он должен быть абсолютно понятен всем участникам разработки. Не должно быть отсылки бага обратно автору за подробностями. Пусть вновь пришедшие сотрудники сделают несколько репортов под присмотром более опытных. Пусть в открытом доступе хранится некий глоссарий, который можно использовать, редактировать. Это сэкономит кучу времени в будущем.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-15213174849306081752009-09-29T14:58:00.000+04:002009-09-30T14:23:51.838+04:00Расстановка приоритетов тест кейсовПроцесс тестирования предполагает своевременное донесение до необходимого количества заинтересованных лиц текущего состояния разрабатываемого софта. Я думаю, что всем понятно, что заказчик меньше всего ждет программу с идеальным интерфейсом, бантиками и т.д., но не выполняющую своих прямых обязанностей. Так же как и руководители разработки ожидают, что внедрение нового\ изменение существующего функционала не вредит, не портит основной функционал, ядро системы. Поэтому при составлении тест плана необходимо четко расставлять приоритеты тестирования тех или иных областей тестируемого приложения ввиду ограниченного срока разработки ПО и, соответственно, его тестрования. <br />В зависимости от вида тестирования (модульное, системное, интеграционное) приоритеты могут изменяться, но суть- есть вещи, которые должны быть протестированы в первую очередь, и есть вещи, тестирование которых может (и должно) быть отложено, остается той же.<br /> Сначала необходимо определить критичные области приложения (такие как, например, ядро системы, основной функционал, ради которого и ведется вся разработка). Эти области должны быть протестированы в первую очередь насколько это представляется возможным. Затем произвести разбивку по важным, средним и маловажным областям. При этом нужно пользоваться набором требований к ПО, которые чаще всего отражают критичные и важные области. Проще всего это сделать, уже имея дерево сгруппированных тест кейсов (расстановка приоритетов упоминалась в "правилах написания тест кейсов"). Достаточно будет пройтись по нему и расставить уровни критичноти "части" приложения, тестируемой\проверяемой тем или иным тест кейсом. Для большей точности это можно сделать с руководителем разработчиков. Который попутно сможет также рассказать о таких моментах, как "в следующий билд должен войти такой-то и такой-то функционал, поэтому это нужно включить в первоочередные проверки." Здесь можно дополнительно проставить такой параметр, как "близость релиза" чтоли. Ведь общая задача- поставить в срок то, что нужно, и заданного качества. Поэтому будет ошибочно тестировать области приложения одинакового уровня критичности, но вперед ту, которая будет релизиться позже. <br />Таким образом выстраиваем список тест кейсов, в котором будет указано когда (в какой последовательности) будет тестироваться тот или иной функционал. Соответственно, зная "скорость", можно определиться со временем.Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-31197188641415309542009-09-28T12:25:00.000+04:002009-09-30T14:21:49.380+04:00Правила работы с багами (баг репортами).В этом посте хочу поделиться с некоторыми устоявшимися у нас правилами и требованиями, которые необходимо соблюдать при постинге багов в багтрекнговые системы, при верификации фиксов и т.д. Не говорю, что они подойдут всем и во всем, но столкнувшись с проблемами, я решил превентировать их в будущем введением именно такого регламента.<br />Вообще каждая багтрекинговая система содержит в себе достаточно всяких требований, условий и так далее. Но иногда, в чем я убедился, этого не совсем достаточно, особенно для новичков в тестировании.<br /><br />Работа с дефектами:<br /><br />1. Вся работа с дефектами должна быть в соответствии с требованиями TFS (Напомню, что это наш основной инструмент). 1. Каждый дефект репорт в багтрекинговой системе: 1) имеет уникальный номер ID; заголовок (краткий, но максимально информативный для поиска и ориентации по нему); важность; срочность; ссылки на связанные дефекты, ТС, требования (обязательно для дефектов требований, спека), документацию (при необходимости); описание (что, где и когда именно не работает(работает неправильно));набор шагов для воспроизведения (необходимо указывать максимально короткую последовательность из возможных, то есть проводить доподлинное выявление дефекта, его локализацию), если существуют другие способы появления этого же дефекта- необходимо их указать (например, в комментариях); к какому приложению и\или его области дефект относится, в каком билде найдет, в какой билд вошел фикс; статус (в каком состоянии он находится, кто в данный момент времени над ним работает, кто автор, кто ответственные);комментарии, историю изменений. 2) описывает уникальное состояние приложения (на данный момент времени). 3) должен содержать максимальное количество (уникальной) информации о дефекте (xml, скрины, графические файлы и тд).<br />Остановлюсь на заголовке подробнее. Правильный заголовок должен отражать суть дефекта, быть таким, чтобы по нему можно было найти дефект поиском, в то же время- кратким и емким. Если это исключение, значит пишем, что "исключение при...", а не "появляется сообщение с исключением..". Второй вариант допустим при дефекте вывода не того сообщения, которое должно быть, например.<br /><br />2. При проверке фикса, помимо самого дефекта должно проверяться минимальное окружение (метод эд хок). Этим пунктом хотелось бы предотвратить ситуации, когда дефект пофиксен, но существует аналогичный\похожий дефект (или даже не один), которые легко находятся. Но не перебором граничных, "интересных" значений, например, а включением мозга. При котором строятся попытки, варианты того, в каких случаях можно еще получить схожее поведение программы и добиться получения дефекта. <br /><br />3. Недопустимо повторение дефектов в системе багтрекинга. Перед постингом необходимо убедиться в отсутствии такового же дефекта в системе, используя поиск. При необходимости- открыть заново с соответствующим комментарием.<br /><br />4. Каждый дефект репорт должен содержать описание только одного дефекта. при отклонениях должен быть создан другой репорт (за исключением некоторых случаев, которые будут оговариваться отдельно). Здесь имеется ввиду то, что нельзя запихивать несколько дефектов в один репорт. Не путать с одним дефектом и несколькими путями (возможностями) его проявления.<br /><br />5. В сложных ситуациях когда дефект "мигрирует" или "изменяется" (либо из одной области приложения в другую, либо изменяется поведение и тд) нужно закрыть старый дефект (с комментарием) и открыть новый. Иногда встречаются такие ситуации, когда шаги для воспроизведения дефекта становятся мало похожи на первоначальное описание.<br /><br />6. Верификацию фикса проводит автор дефекта. Ad hok ("вокруг этого дефекта")- можно тестировать не обязательно автору. Довольно противоречивый пункт. Однако есть мнение, что никто кроме автора не знает сам дефект лучше, какие-то подробности, нюансы (хотя они должны бить прокомментированы). <br /><br />7. При нахождении дефекта необходимо проверить все возможные способы его получения и смежные области. То есть необходимо подумать и проверить- где этот дефект или его влияние) могут быть найдены еще.<br /><br />8. При описании дефекта следует иметь ввиду, что при проверке фикса следует проверять все возможные (логически реализуемые) варианты проявления дефекта (в зависимости от ОС, окружения и тд.). Но не следует перегружать описание дефекта перечислением этих вариантов. Достаточно указать на достаточно(!) различные варианты.<br /><br />9. Количество шагов для воспроизведения должно быть минимальным, но достаточным (дефект должен быть максимально локализован). <br /><br />10. Необходимо проводить регулярные bug review, bug status review.<br /><br />11. Описание дефектов необходимо дополнять достаточным количеством скриншотов.<br /><br />12. Как правило каждый дефект имеет свое влияние на выполнение\невыполнение ТС\TS и др. Поэтому должен содержать ссылки на зависимые элементы.<br /><br />13. Что нужно проверять при проверке фикса\новой фичи: 1. проверять, что то, что сделали (написали\пофиксили) разработчики, работает вообще. 2. проверять, что то, что сделали (написали\пофиксили) разработчики, работает корректно. 3. проверять, что то, что сделали (написали\пофиксили) разработчики, не ломает существующий, корректно работающий функционал.<br /><br />14. Проверка фикса (и не только): 1. В первую очередь производится попытка воспроизведения бага (по описанным шагам). 2. Во вторую- анализ областей, в которых вероятно возникновение этого бага.(Например, если был обнаружен баг с фильтром, работающим при вызове какого-то меню, то имеет смысл проверить все схожие типы меню, работающих по такому же принципу.). 3. Проверка этих областей. 4. Анализ возможности вызова повторения бага другими методами (отличающимися от описанного в баг репорте (Например, если был обнаружен баг при удалении записи, имеет смысл проверить удаление группы записей и т.п.)). 5. Проверка этих методов. Минимальное свободное тестирование (сугубо специфично): 6. Проверка работы с некорректными данными (например, сохранение, поиск по ним). 7. Повторяющиеся действия (например, попытка удаления уже удаленного объекта, двойной импорт). 8. Проверка вывода обязательных сообщений (например, при сохранении с незаполненными обязательными полями). 9. Если, например, тестируется установка дистрибутива или импорт данных, имеет смысл использовать виртуальные машины для одновременной проверки разного функционала или параллельной проверки при различных условиях (пример- при тестировании импорта\экспорта удобнее и бытрее на одной машине произвести импорт, затем экспорт, а на другой- импорт этих экспортированных данных; с последующей одновременной проверкой данных).<br /><br />А так же читаем про управление дефектами на http://software-testing.ru/library/testing/bug-tracking?layout=defaultAndreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0tag:blogger.com,1999:blog-4027263932695413933.post-87442813962919147752009-09-25T09:13:00.000+04:002009-09-30T14:20:19.179+04:00Правила написания скриптов автотестов (TestComplete)В дополнение к предыдущему посту, и для совместного (параллельного) использования этих постов.<br />Обращаю сразу внимание, что правила в этом посте специфичны для конкретного проекта, конкретной организации и конкретных инструментов автоматизации и тестирования вообще. Поэтому основные мысли уловить можно, но перед использованием в других проектах\компаниях эти правила следует заточить под свою спецтфику. У нас инструмент автотестрования- TestComplete 6.52. Багтрекинг - TFS. ОС- Vista, WinSserv2003, WinSserv2008. Виртуализация- VMWare. MS VisualStudio2008.<br />Итак сами правила:<br /><br />1. Правила создания тест кейсов. Без комментариев :)<br /><br />2. Инструкция к тесткомплиту. Без комментариев :) Хорошо, что есть на русском и на английских языках.<br /><br />3. Структура: нумерация и название ТС, идентичны ручным ТС. Иначе не поймешь, что проверяет тот или иной скрипт.<br /><br />4. Порядок выполнения может быть изменен. Так как часто создаются опреджеленные наборы скриптов, а не прогоняются все сразу.<br /><br />5. Структура: первый проект (ТС) содержит скрипт (назовем его "Reference"), содержащий функции и методы, испотльзуемые в других ТС. Тут следует прокомментировать: оптимальным вариантом представлялось такая организация- тест кейс=проект (project) тесткомплита, набор тест кейсов=(project suite) съют. сам скрипт (script)= набор функций (function).<br />Каждый ТС (проект) содержит несколько скриптов: Первый- ссылка на скрипт "Reference" первого проекта. <br /><br />6. Структура: первый проект (ТС) содержит скрипт ("Reference"), содержащий функции и методы, используемые в других ТС.<br /><br />7. Структура: остальные ТС (все кроме первого) содержат основные скрипты ТСа ("Main" и "Local _Reference"), и "ссылку" на скрипт ("Reference") скрипт (выглядит эта ссылка просто как скрипт). Таким образом у нас имеется 3 скриптовых элемента в каждом проекте: 1)<span style="font-weight:bold;">одно</span> хранилище ("Reference") функций и методов, используемых в различных скриптах, находящееся (физически) в первом проекте и вызываемое из других проектов (ссылки); 2)"Main" скрипт в каждом проекте, в котором находятся наборы функций, необходимых для выполнения тест кейса; и 3)"Local _Reference" скрипт, в котором находятся "локальные" функции, которые сделаны для того, чтобы не загромождать "Main" скрипт, облегчать процесс "понимания" скрипта, облегчать модификацию и т.д. Поясню зачем это нужно: при выполнении тестирования часто приходится повторять одни и те же действия по многу раз. Ясно, что иметь одинаковое описание этих действий (функцию или ее часть) во множестве скриптов совершенно неэффективно, тем более подумайте о процессе модификации такой функции при необходимости. Поэтому эта функция выносится в отдельное место (скрипт "Reference", или вообще в отдельную библиотеку, но пока не будем усложнять) и вызывается при необходимости. Таким образом, когда нужно будет исправить скрипт в этом месте работы, мы правим только одну вызываемую функцию и все. Далее: основной скрипт проекта ("Main") содержит основные функции проверки- например, 3 штуки: открыть форму, внести изменения, сохранить. Логично предположить, что 1 и 3 действия будут проделываться многократно при тестировании (хотя я заносил в скрипт "Reference" функции уже при однократном повторении). Поэтому выносим их. 2 действие выносить смысла нет, так как, допустим!, вносим какие-то уникальные изменения, для данной конкретной проверки.<br />Однако расписывать эту функцию прямо в мейн скрипте не стоит- потом сложно будет разбираться в этом нагромождении (как правило функции содержат в себе множество вызовов других функций). Поэтому выносим ее в скрипт "Local _Reference". <br /><br />8. Структура: При написании функций и методов необходимо четко обозначать конечные действия: необходимо оценивать специфику работы приложения в контексте того или иного скрипта (функции). Например, при редактировании свойств на одной из вкладок свойств какого-либо класса, возможны 2 различных направления продолжения действий: либо сохранить\отменить, либо перейти на другую вкладку и редактировать свойства там. В таком случае эффективнее, с точки зрения процесса, будет писать функцию редактирования свойств, которая будет лишь "редактировать" свойства, но не сохранять\отменять или переходить на другие вкладки, оставляя возможность выбора дальнейших действий и, соответственно, возможность использования этой функции в максимальном количестве скриптов. <br /><br />9. Структура: все функции и методы должны иметь уникальные имена. В скрипте функций ("Reference")- "говорящее название" (например, function DeleteChildClass()). в основном скрипте ("Main")- неполный номер ТС после названия функции. (например, function DeleteChildClass11231(), где А0011231- номер ТС). Это нужно для того, чтобы не путать фукнкции из "Local _Reference" и "Reference" скриптов. А это возможно, потому что один скрипт может содержать в себе одинаковые проверки, но с, допустим, различными данными: в одном случае это будет стандартная проверка (вызов из "Reference"), в другом- специфическая (вызов из "Local _Reference"). Действия почти одни и те же, имена функций похожи, но обязаны различаться. <br /><br />10. В функции первым комментом должно идти описание того, что эта функция делает. (например, "// Создание "testclass""). Чтобы не ломать голову читая сам скрипт.<br /><br />11. В "Main" скрипте также должно быть описание того, что этот ТС делает ("// создание класса ").<br /><br />12. Все скрипты, обращающиеся к другим скриптам должны иметь ссылки на них в начале скрипта. Особенность инструмента. Собственно, без этого ссылки работать не будут.<br /><br />13. Все функции должны иметь структуру "try-catch". Весь набор скриптов не должен останавливаться при выпадании исключения приложения.<br /><br />14. Скрипт должен быть написан в соответствии с ручным ТС. То есть с выделением и обозначением шагов (групп шагов), предустановок и постустановок. (допускается copy\paste <span style="font-style:italic;">описания шага</span> из ручного ТС).<br /><br />15. Отправляемые в лог сообщения и ошибки должны быть понятны всем участникам разработки. Не забываем, что результаты прогонов автотестов будут смотреть все желающие.<br /><br />16. Функции в скрипте должны быть разграничены: "\\***". Просто для облегчения восприятия. Отлично работает "сворачивание".<br /><br />17. Скрипт должен безопасно работать с приложением (метод "terminate()" недопустим в обычных тестах). <br /><br />18. Верификация "внешнего" вида (GUI) должна быть сведена к минимуму. Тестирование основано на описании состояний системы.<br /><br />19. Чем большее количество свойств системы верифицируется- тем лучше<br /><br />20. Необходимо учитывать связанность выполнения съюта тесткомплитом. тем не менее должна быть возможность собирания отдельных съютов для тестирования тех или иных задач.<br /><br />21. Обращение к процессам и их объектам должно осуществляться через переменные ("w1 = p1.QAdminForm; w2 = w1.treeViewClass;").<br /><br />22. Скрипты и функции должны писаться с учетом того, что каждый из них может быть (и будет ) использован в другом скрипте или функции. Поэтому необходимо предусматривать варианты их апргрейда с выявлением зависимых ТС и их составляющих (методами занесения ошибок в лог, верификацией (в том числе дополнительной)). так же необходимо предусматривать обратную связь при внесении изменений. тесткомплит поддерживает ссылки на функции и ТС. таким образом при модификации и внесении изменений необходимо вносить их в целое дерево внутренней структуры. Начинать необходимо с внесения обязательных изменений (с решением и модификации или создании новых функций), двигаться строго в направлении от "ствола" дерева к его "ветвям". каждый случай должен обсуждаться отдельно. Идеальный вариант- определенный известный набор скриптов обращается к модифицированной функции, при этом не падают остальные скрипты и ТС. таким образом получаем минимальные затраты на модификацию. все функции в скрипте "Reference" должны быть актуальными в любой момент времени и соответствовать описанию работы приложения.<br /><br />23. После выполнения каждого скрипта должны быть выполнены соответствующие действия по возврату к исходному сосоянию (за исключением оговоренных случаев).<br /><br />24. Все имена объектов и значения свойств, используемых в методах и функциях- из Object Brouser Тestcomplete методом copy\paste. Так как не все символы видимы в Object Brouser. (такие как пробел). Хотя тут нужно пинать разработчиков.<br /><br />25. Координатный клик допустим только в исключительных случаях.<br /><br />26. Структура скрипта должна быть удобна для понимания и выделения отдельных методов и вызовов функций.<br /><br />27. BuiltIn.Delay() допустим только в исключительных случаях. Пользуемся методами Wait...<br /><br />28. В названии объекта (к которому обрщаемся) должно быть указано максимальное количество постоянных неизменяемых символов. Есть вероятность появления похожих по названию объектов.<br /><br />29. Не допускается пропуск верификации отдельных функций, если они многократно проверены предыдущими скриптами в съюте. так как из этих скриптов могут быть собраны в будущем другие съюты.<br /><br />30. При удалении, модификации объектов метаданных, должна быть проведена дополнительная верификация работы с "нужным" объектом, где должны отразиться эти изменения (сугубо специфично).<br /><br />31. При блокировке выполнения скрипта, в лог должна отправляться ошибка с указанием номера бага.<br /><br />32. Недопустимо многократное повторение одних и тех же шагов. Необходимо использовать стандартные операторы, функции, методы, циклы языка JScript.<br /><br />33. Все новые скрипты должны добавляться в VSS (потом TFS). в конце дня- check in.<br /><br />34. Приоритеты: сначала поддержка скриптов в актуальном состоянии, потом - создание новых скриптов.<br /><br />35. При модификации скрипта, уже работавшего ранее, связанной с изменением в приложении, должно быть не более трех сохранений до получения рабочего скрипта. (количество прогонов после каждого сохранения не ограничено). если после 3го изменения и сохранения скрипт не работает-необходимо проинформировать руководителя тестировщиков (автоматизаторов).<br /><br />36. При "ссылочном" методе поиска функции, в которую необходимо внести изменения- необходимо убедиться в ее неактуальности; в том, что именно в нее должны быть внесени изменения.<br /><br />37. copy\paste кода скрипта недопустим! скорость создания скриптов обеспечивается использованием уже написанных функций, а не копированием кода.<br /><br />38. Допускается клонирование проектов, с незамедлительным внесением изменений в названия проекта, скриптов, функций, объектов и код скриптов. Рабочий скрипт (если таковой присутствует необходимо очищать от старого скопированного кода). Добавление новых проектов или элементов проектов к TFS- только после внесения описанных выше изменений.<br /><br />39. Все дополнительные приложения, вызываемые из скрипта, должны быть приведены к общему виду (например, во весь экран, масштаб 100%), а затем сравнены с эталоном.<br /><br />40. Все скрипты должны использовать только БД, созданную для автоматизированного тестирования. каждый вечер она автоматически бэкапится.<br /><br />41. Лучше чаще использовать возможности Object Brouser (свойства и методы), чем Recorder.<br /><br />42. Необходимо учитывать расположение исполняемых файлов, для запуска приложения. оптимальный вариант- использование установщика приложения и запуск из директории установки.<br /><br />43. Скрипт должен отправлять в лог такие сообщения\ошибки, чтобы были понятны причина возникновения исключения и его "местоположение" (во время выполнения). То есть, если, например, сравниваются свойства какого-либо объекта, и какое-то свойство имеет значение, не соответствующее ожидаемому, то сначала в лог должна отправиться ошибка с указанием на различие, а потом уже автоматическая ошибка, что ТС fails.<br /><br />44. Структура скрипта должна предусматривать возможность запуска и выполнения скрипта под различными ОС (XP, Vista, Serv 03, 08) (первоначально- Vista и XP); То есть методы и функции должны быть написаны с учетов всех соответствующих различий в ОСах- необходимо максимально стремиться к унификации функций относительно различных ОС, в тех случаях, где это невозможно- должны быть написаны различные функции под все необходимые ОС, и взависимости от вида ОС, должны выбираться те или иные функции, методы, переменные и т.д.<br /><br />45. В скрипте должно содержаться максимально допустимое количество проверок свойств приложения. (У каждого объекта существует несколько свойств, пригодных для верификации, обычно существует большое количество таких объектов в любой момент времени). <br /><br />46. В случаях, когда невозможно избежать применения схожих (повторяющихся) действий при работе с приложением, необходимо применять различные концептуальные подходы к описанию и, соответственно, к выполнению этих действий. Для более полного охвата тестируемого функционала и методов работы с ним.<br /><br />47. При выборе объектов, например, в дереве (tree) должен использоваться метод Select(), а не Click() там, где это возможно.<br /><br />48. Необходимо учитывать, что на разных ОСях, на виртуалках и при удаленном доступе могут быть задержки выполнения скрипта. Поэтому необходимо использовать "Wait*" методы при написании скрипта там, где это возможно.<br /><br />Как-то так. Хотя подозреваю, что большинство пунктов необходимо комментировать дополнительно, объясняя суть, необходимость использования. Подождем уточненной статистики..Andreyhttp://www.blogger.com/profile/03952573334229512016noreply@blogger.com0