irko,

 

 как успехи?

 

 более всего интересует, насколько получится у вас совмещать в одном лице автоматизатора и ручного тестировщика.

 

Докладываю по статусу) Попробовала написать тесты на две страницы, медленно, но кое-что получилось. После майских вернулись - а у нас завал, нужно было и мокапы для прототипа проревьюить, и тестовые спеки для заказчика написать, и принять участие в создании требований, и верстку проверить, и потом еще тестирование первых версий началось. Стало не до автоматизации:) Даже с РП не хватило времени обсудить автоматизацию))) Сейчас вот какое-то свободное время появилось. Решила взглянуть на то, что сделала. И поняла, что за эти полтора месяца полностью переделали те страницы и они ушли в мусорку  чего я в принципе и ожидала.)

Всем добрый вечер!

Недавно в компании был открыт новый проект по разработке некого веб-приложения ("суперумного" интернет-магазина). Первые два этапа планируется выполнить в течение двух лет. Пока делается прототип, выполнено буквально две его сырые странички с фиксированными элементами управления на них. Этап архитектуры еще не завершен.

Соответственно меня поставили тестировщиком на этот проект.

На днях РП озадачил меня тем, что необходимо начать автоматизацию, т.к. проект длительный.

Я просто в шоке, т.к. прежде занималась только ручным тестированием (но очень даже неплохо, предыдущие проекты отличались минимальным количеством багов, найденных заказчиком). А так я даже языков программирования не знаю. За исключением Cи, с которых работала 4 года назад и ничего уже не помню.

В связи с необходимостью автоматизации, куча вопросов:

Как вы считаете, реально ли ручному тестировщику стать автоматизатором и сколько на это времени необходимо? 

На какие инструменты стоит обратить внимание начинающему?

Стоит ли браться за такую задачу ручному тестировщику? 

Также а стоит ли начинать автоматизацию на столь ранних этапах? у меня вот в голове живет стереотип, что автоматизированные тесты нужны прежде всего для регрессии и к ним приходят, когда проект уже достаточно зрел.

Короче, дела мои плохи.  У нас в конторе всего один практикующийся автоматизатор и вряд ли его захотят подключить к моему обучению или к проекту( 

Добрый день всем!

В компании планируется запуск нового проекта. Соответственно нужно определиться с инструментами тестирования. Как вариант рассматриваю Microsoft Test Manager 2012. Знаю, что некоторые проекты у нас используются данный инструмент. Подскажите, пожалуйста, насчет его плюсов и минусов?

В частности интересует вопрос по возможности хранения тест-кейсов, возможности поддержания их всегда актуальными.

На предыдущем проекте все тест-кейсы хранились в Word-е в тестовой спецификации, их было много (более тысячи листов), но это было удобно (они были систематизованнные и актуальные, т.к. проекту было много лет, примерно 20 модулей и требования менялись в течение этого времени значительно, тз  и чтз было много; это было большим плюсом, что есть такой документ, содержащий актуальную информацию). Но все-таки охота попробовать более "прогрессный" способ ведения тест-кейсов. Будет ли такая возможность поддержки актуальных тест-кейсов в Test Manager? Насколько это удобно?

Общалась с одной из тестировщиц, она сказала, что у нее есть проблемы с данным вопросов в test manager, поэтому не пойму, это действительно проблема инструмента или проблема того, что было "запущено" обновление кейсов у конкретного тестера.

Также послушала бы о других плюсах и минусах.

Возможности попробовать на себе работу в TM нет сейчас.

Мне доверили написать план тестирования. И одним из его разделов идет СТРАТЕГИЯ ТЕСТИРОВАНИЯ!!!

Мучаюсь уже несколько дней. Ничего не получается. Получился пока такой вариант. Чувствую, что неправильно делаю. Укажите, пожалуйста, недостатки. Нужна очень критика. На все вопросы ответу.  

[Стратегия тестирования описывает процедуры, согласно которым должно проходить тестирование всех модулей системы. Опишите критерии приема версии на тестирование, типы версий, типы тестирования.

Адаптируйте текст для вашего проекта.]

Целью тестирования является проверка соответствия системы функциональным и техническим требованиям в рамках требований функциональности.

Процесс тестирования состоит из 2-х последовательных этапов:

• Тестирование на стороне Исполнителя (внутреннее тестирование)
• Тестирование на стороне Заказчика[SI1]  (приемочное тестирование)[SI2] 

Для проверки корректности реализации системы осуществляется тестирование версий.

Каждая версия ПО проходит полный цикл тестирования.

Цикл тестирования приложения включает в себя все типы тестирования (см. главу Тестируемая часть).  Тестирование производительности осуществляется ближе к концу этапа проекта (см. Календарный план).

Для внутренней версии выполняются следующие ступени тестирования:

• Предварительное тестирование;
• Тестирование новой функциональности;
• Проверка исправленных дефектов;
• Регрессионное тестирование.

Описания типов и ступеней тестирования приведены в Приложениях 9.2, 9.3.

В первую очередь инженерами по тестированию осуществляется проверка (ревью) существующих требований на проект, в том числе Спецификации Требований [3]. В случае необходимости производятся уточнения по изменениям требований.

После проверки вносятся соответствующие изменения в Методику Тестирования [2]. После внесения изменений осуществляется ревью документа всеми инженерами по тестированию.

Изменения в Методике Тестирования должны быть утверждены старшим инженером по тестированию.

Версия ПО приходит на тестирование в соответствии с процедурой «Поставка тестового билда» (см. План Управления Конфигурацией [1]).

На тестовом окружении проводится ручное тестирование системы путем выполнения тестовых сценарий и тест-кейсов, описанных в Методике Тестирования (см. Методика тестирования).

На втором этапе проекта возможно применение авто-тестов для регрессионного тестирования (в случае необходимости). Возможный инструмент тестирования – Selenium.[SI3] 

После проверки вносятся соответствующие изменения в Методику тестирования. Осуществляется ревью изменений всеми инженерами по тестированию.

В системе баг-трекинга оформляются отчеты о дефектах (см. п. Отчет о дефекте).

Все обнаруженные при тестировании дефекты обрабатываются в соответствии с процедурой управления дефектами/запросами на изменение (см. Руководство по управлению инцидентами [7]).

Все задания (feature) обрабатываются в соответствии с процедурой процедуру управления заданиями (см. см. Руководство по управлению инцидентами [6])[SI4] 

Результаты тестирования заносятся в Отчёт о тестировании [4] старшим инженером по тестированию.

Срок проведения тестирования версии определяется в 15 рабочих дней. [SI5] Тестирование проводится параллельно с разработкой следующей версии, в которой резервируется время на исправление выявленных дефектов.

По результатам тестирования в соответствии с главой «Критерии приемки версии» Руководителем Проекта принимается решение о возможности поставки данной версии. Если решение позитивно, то производится поставка в соответствии с процедурой «Поставка» (см. План Управления Конфигурацией).

Данное тестирование начинается сразу по завершении процедуры «Поставка» на приемочном окружении на стороне Заказчика[SI6] .

 

 

Для чего этот план вам нужен? Кому кроме вас он нужен? И вы уверены, что кто-то, кроме вас/команды тестировщиков будет его читать/использовать более одного раза? Для чего вам в плане этот пункт - точно без него нельзя обойтись?

Можете попробовать под себя подогнать вариант Сергея Мартыненко:

 

1    Стратегия тестирования

Текущий подход к контролю качества подразумевает следующие вехи проекта:
Подсистема готова к демонстрации заказчику
Подсистема готова к промышленной эксплуатации

Такое разбиение предполагает как можно более раннею поставку работающего прототипа заказчику с целью получения обратной связи.
Приоритеты комплексных показателей качества в классификации ГОСТ 9126 в зависимости от вех проекта, приведены в таблице ниже:

[Здесь ваша таблица]

Для проверки готовности прототипа служат приемо-сдаточные испытания. Критерий готовности - акт сдачи прототипа подписанный приемо-сдаточной комиссией. Приемо-сдаточные испытания описываются в отдельном документе. Либо как раздел шесть частного технического задания, согласно ГОСТ 34.602-89, либо в отдельном документе содержащем программу и методику испытаний.

Для проверки готовности к промышленной эксплуатации используется полный набор запланированных тестов. Готовность определяется руководителем проекта, на основании представленных ему руководителем тестирования отчетов о полноте тестового покрытия и списка значимых расхождений, оформленных в виде дефектов в трекинговой системе. Тестовые спецификации описываются в отдельном документе.

 

http://blog.shumoos.com/archives/267

Неприменимо для  вас, т.к. другой тип деятельности (замена  информ системы), но структуру и речевые обороты можете использовать.

 

Что касается, собственно, выбора стратегии - пока это не ваш уровень. Начинайте учиться. Посмотрите (прослушайте) запись моего выступления с SQA-15.

 

 а можно запись выступления? ссылку?

 

Для чего этот план вам нужен? Кому кроме вас он нужен? И вы уверены, что кто-то, кроме вас/команды тестировщиков будет его читать/использовать более одного раза? Для чего вам в плане этот пункт - точно без него нельзя обойтись?

Можете попробовать под себя подогнать вариант Сергея Мартыненко:

 

1    Стратегия тестирования

Текущий подход к контролю качества подразумевает следующие вехи проекта:
Подсистема готова к демонстрации заказчику
Подсистема готова к промышленной эксплуатации

Такое разбиение предполагает как можно более раннею поставку работающего прототипа заказчику с целью получения обратной связи.
Приоритеты комплексных показателей качества в классификации ГОСТ 9126 в зависимости от вех проекта, приведены в таблице ниже:

[Здесь ваша таблица]

Для проверки готовности прототипа служат приемо-сдаточные испытания. Критерий готовности - акт сдачи прототипа подписанный приемо-сдаточной комиссией. Приемо-сдаточные испытания описываются в отдельном документе. Либо как раздел шесть частного технического задания, согласно ГОСТ 34.602-89, либо в отдельном документе содержащем программу и методику испытаний.

Для проверки готовности к промышленной эксплуатации используется полный набор запланированных тестов. Готовность определяется руководителем проекта, на основании представленных ему руководителем тестирования отчетов о полноте тестового покрытия и списка значимых расхождений, оформленных в виде дефектов в трекинговой системе. Тестовые спецификации описываются в отдельном документе.

 

 пока пытаюсь адаптировать под себя имеющийся на работе шаблон компании. но как-то он не очень хорошо вписывается в этой части(

 

Для чего этот план вам нужен? Кому кроме вас он нужен? И вы уверены, что кто-то, кроме вас/команды тестировщиков будет его читать/использовать более одного раза? Для чего вам в плане этот пункт - точно без него нельзя обойтись?

Можете попробовать под себя подогнать вариант Сергея Мартыненко:

 

1    Стратегия тестирования

Текущий подход к контролю качества подразумевает следующие вехи проекта:
Подсистема готова к демонстрации заказчику
Подсистема готова к промышленной эксплуатации

Такое разбиение предполагает как можно более раннею поставку работающего прототипа заказчику с целью получения обратной связи.
Приоритеты комплексных показателей качества в классификации ГОСТ 9126 в зависимости от вех проекта, приведены в таблице ниже:

[Здесь ваша таблица]

Для проверки готовности прототипа служат приемо-сдаточные испытания. Критерий готовности - акт сдачи прототипа подписанный приемо-сдаточной комиссией. Приемо-сдаточные испытания описываются в отдельном документе. Либо как раздел шесть частного технического задания, согласно ГОСТ 34.602-89, либо в отдельном документе содержащем программу и методику испытаний.

Для проверки готовности к промышленной эксплуатации используется полный набор запланированных тестов. Готовность определяется руководителем проекта, на основании представленных ему руководителем тестирования отчетов о полноте тестового покрытия и списка значимых расхождений, оформленных в виде дефектов в трекинговой системе. Тестовые спецификации описываются в отдельном документе.

 

 да, без пункта Стратегия тестирования нельзя обойтись. План нужен заказчику. И в принципе нам должен быть полезен (те же виды тестирования, которые будут, какая тестовая среда, описание рабочего места, какие документы, где хранятся...). Будут другие пункты Тестируемая часть, Нетестируемая часть, Тестовая среда, Документация (ее описание), Критерии начала и окончания тестирования и т.д. С остальными пунктами более менее понятно. Но вот со стратегией проблемы. В принципе виды тестирования тоже знаю, какие нужны, они в приложении будут идти. В стратегии ссылку сделала.. Описания типов и ступеней тестирования приведены в Приложениях 9.2, 9.3.

тут можно прочитать дельные вещи по стратегии:

http://33testers.blo...testing-01.html
http://33testers.blo...testing-01.html

http://33testers.blo.../2015/02/3.html

 

вообще-то исходный план - по мне скорее регламент, чем стратегия.

Спасибо большое за ссылки! 

 

Я могу посоветовать книгу Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд Лайза Криспин Джанет Грегори. Очень подробно описывается тестирование в Agile. Сама сейчас в процессе прочтения! Можно, например, читать отсюда: http://padaread.com/...book=16896&pg=1

 

 

Хотя сама еще не работала в Agile, только читаю книгу и знакома с отзывами коллег, поняла, что одним из условий применения данной методологии является применение автоматизированных тестов. Поэтому одним ручным тестированием не обойтись.. (если не так, поправьте меня, пожалуйста, сама пока знакомлюсь :) самой интересен этот момент).

Мы разошлись во мнениях. Интересно будет поспорить. На мой взгляд, эта книга - халтура. Деньги можно заработать, но время потраченное на чтение этого "опуса" - нет.

 

И, да, дайте определение "Agile". А то я слышал столько забавных определений, что даже не знаю, что вы имеете в виду.

 

да, книга большая и много тавтологий) но на мой личный взгляд, это  нормально, т.к. большинство книг по тестированию отличается слишком большим объемом и так и хочется их побыстрее пролистать, по-моему, это общая проблема.  Мне лично книга позволила систематизировать ту информацию, которую я получила от коллег. В течение книги встречаются наглядные схемы и  просто выдержки с базовыми принципами, при желании можно пролистать книгу и ограничиться ими. В день читаю по несколько листов - много времени не отнимает. А эта тема мне интересна.

Если Вам нужно определение Agile, непонятно, зачем Вы требуете его от меня. Думаю, Вы сами в состоянии его найти. Ни с кем спорить не собираюсь. Я сама в процессе изучения, интересен чужой опыт.

Я могу посоветовать книгу Гибкое тестирование: практическое руководство для тестировщиков ПО и гибких команд Лайза Криспин Джанет Грегори. Очень подробно описывается тестирование в Agile. Сама сейчас в процессе прочтения! Можно, например, читать отсюда: http://padaread.com/...book=16896&pg=1

Хотя сама еще не работала в Agile, только читаю книгу и знакома с отзывами коллег, поняла, что одним из условий применения данной методологии является применение автоматизированных тестов. Поэтому одним ручным тестированием не обойтись.. (если не так, поправьте меня, пожалуйста, сама пока знакомлюсь :) самой интересен этот момент).

 

В agile может быть какое угодно тестирование - хоть автоматизированное, хоть нет, и даже вообще отсутствовать, если программисты настолько круты, что сразу пишут идеальный код :)

Ну лично я вообще не понимаю о каком автоматизированном тестировании в Scrum можно говорить. Я конечно ни разу не работал в скраме и вообще аджайле, но приведу пример того, как я это понял и почему в скраме не может быть автоматизации. Обязательно поправьте меня, если я не прав.
 
И так, представим скрам команду, в которой есть разработчики и тестировщики. У нас имеется спринт №1, длительность которого 10 рабочих дней (две недели). Первый день мы убиваем на обсуждение, планирование, рисунки на доске и т.д. Затем следующие два-три дня разработчики кодят, а тестировщики пишут тест-сценарии и тест-кейсы по известным требованиям и обсуждениям (заметьте, никакой автоматизации не может быть, так как тестировщики даже не знают как будет выглядеть новый билд, где и как будет называться\находиться каждая кнопка и т.д). Следующие 3 дня тестировщики получают сырые билды и тестят по частям то, что получают от разработчиков и где-то на 7-8 день получают полностью реализованный функционал, который полноценно прогоняют по всем имеющимся тест-сценариям, фиксят баги и так далее. Вот и прошел наш спринт и начался следующий, новый спринт, в котором всё повторяется и все работают в поте лица.
 
Так где и когда тут можно что-то автоматизировать и использовать автоматизацию? Ведь спринты постоянны и в том вся суть скрама, что у нас всегда имеется работа, так как команда каждые две недели выдает новый билд с новой функциональностью.
 
В общем, объясните мне - то ли я чего-то не понимаю, так как всегда слышу, что "автоматизация и аджайл всегда идут бок-о-бок" или же я прав и автоматизации в аджайле (в нашем случае Скраме) нет и автомэйшн в скраме - это утопия, как и город солнца Томмазо Кампанелла.

 

 
Как я поняла по книге, один из принципов - управляемая тестами разработка и управляемое тестами проектирование. То есть сначала пишутся тесты, а потом код. И их написанием занимаются разработчики. Далее эти тесты постоянно поддерживаются. Такой подход "типа" позволяет предупреждать появление  ошибок (то есть не создавать их). Лучше потратить больше времени на автоматизацию вначале, чем потом, когда необходимое покрытие будет все увеличиваться и увеличиваться.

Знакомая девушка, которая работала над проектом по Agile, также говорила, что у них были автоматизированные тесты, написанные разработчиками.

Но вообще там очень-очень много принципов (и ежедневные митинги, где каждый участник отчитывается о том, что он сделал, и проактивность каждого участника разработки, принцип "любой член команды может участвовать в решении любой задачи", специфичность вовлечения заказчика в процесс разработки, 4 квадранта гибкого тестирования....). В книге подчеркнуто, что некоторых людям бывает очень сложно перестроиться. В общем очень любопытно

скинула вам хороший шаблончик в личку)