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

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

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

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

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

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

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

у нас за полгода минус 110 человек) осталось 265)

Как-то в проекте использовали Sharepoint. Было очень удобно. И баги, задачи, и всевозможная документация хранились на одном портале.

а pdf-ки не загружаете?:)

на моем предыдущем проекте у нас тоже была такая функция загрузки сканир. подлинников. Мы проверяли возможность добавить документы типов doc/docx, xls, txt, pdf, всякие картинки и т.д (все наиболее популярные форматы).

В реальности после поточного сканирования добавлялись pdf, если пользователи ручками добавляли, то docx, pdf, картинки, xls.  

а у вас прям только-только картинки должны быть?

и в данном случае это же стандартное окошко веб-браузера?

Первые вещи, которые бросились в глаза и не понравились:
1. На главной странице выводятся адреса. Обычно адреса указывают в разделе Контакты. Да и еще и расположение этих адресов на главной странице не usability: расположены посередине текста. Я открываю главную страницу в Chrome - видна половина адресов, для дальнейшего просмотра нужно прокручивать страницу. Мелочь, а не приятно.
 

Далее в разделе Контакты адреса дублируются чуть ли не в трех местах одновременно: сверху над телефоном, в нижней части страницы и по самому тексту).

2. Просмотр картинок на сайте. При кликании на них одни не открываются, вторые - увеличиваются в масштабе (причем в самом разном) для просмотра, а третьи - открываются, но не в увеличенном масштабе. Нету единообразия.
 
3. Есть баги. Например, если хочу добавить комментарий анонимно, то открываются поля для ввода имени и электронной почты. По-моему, их нужно сделать обязательными. 
Далее из оставленного комментария можно просмотреть и отредактировать, оказывается, свой профиль... Открываю ссылку для просмотра своего профиля,  который я,  оказывается, создала, а там узнаю, что оставила целых 78 комментариев (в реальности в целях тестирования был только один коммент... Просматриваю комментарии в "своем" профиле, а там выводятся тексты даже удаленных комментов.

4. Стоило бы проверить тексты на орфографию и пунктуацию. 

Добрый день! Подскажите, пожалуйста, почему может быть следующая ошибка:

By.linkText заменить на cssSelector  - ".catalog-details b"

конечно, если такой элемент на странице один.

 спасибо большое! получилось!

А кто-нибудь из вас был ментором или наоборот имел настоящего ментора?

 

Какие впечатление? (с обоих сторон)

Сам думаю, что наверное было классно, если бы у меня был раньше, да и сейчас, пожалуй - ментор, но как я понимаю, в русскоязычной среде - это редкое явление (в немецкоязычной - тоже).

 

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

 

На моей работе такого человека называют наставником и есть практика прикреплять наставника к новичку, например, на три месяца. В этом случае составляется документ - План и отчет по обучению. По окончании трех месяцев наставник, подопечный, сотрудник HR и, возможно, еще руководитель практики собираются и подводят итоги.

Для программистов (как правило, джуниоров) работа наставника выражается в выдаче документации для изучении, проверке освоенных знаний по документации, выдаче тестовых заданий новенькому, их проверке, объяснении заданий и решений (первые несколько месяцев идет обычно обучение)  и далее помощи по проекту.

У меня (я тестировщик) также был наставник, он же мой тест лид по проекту. Первые полтора дня я изучала огромную книгу с описанием платформы, на которой разрабатывался мой проект  (изучение подразумевало более длительный срок, но я достаточно быстро схватывала). Далее приступила с изучению имеющейся тестовой спецификации и приложения, прохождению сценариев по имеющейся ТС. Мой наставник познакомил меня с используемыми инструментами, объяснил, как заводить баги, и т.д..  Я каждый день готовила список вопросов, и он терпеливо отвечал на них. И далее по накатанной: изучение технических заданий, ревью ТЗ, написание тест-кейсов... Как-то так!:)  Такой в общем-то незамысловый процесс, но имел хорошие результаты. На второй-третий день у меня, тестировщика без опыта, уже начали создаваться достаточно ценные баги.

 

Ну, для начала, изучить продукт вам все же придется :)

 

 

Спасибо за быстрый ответ! 

 

Конечно я изучаю продукт, но у него просто огромный и достаточно сложный функционал, поэтому у меня уйдет достаточно много времени на это. Уже прошло три недели, а я знаю продукт только поверхностно. Чтобы изучить продукт, в идеале мне нужны готовые пошаговые тест-кейсы с ожидаемым результатом. Ничего подобного и близко нет: все заведенные баги и чек-листы расчитаны на "старичков", которым шаги не нужны. Меня записали на курсы, которые обычно проводят для клиентов. Решили, что мне тоже будет полезно. 

Как такогово changelog у них нет, но абсолютно все изменения они заносят в TFS, то есть можно этот change log собрать на любой момент времени. Но там так много изменений, что я одна начинаю чувствовать себя маленькой букашкой

 

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

Процесс тестирования состоит из 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, либо в отдельном документе содержащем программу и методику испытаний.

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

 

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

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

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

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

 

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

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

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

У Вас есть ТЗ? Советую детально пройтись по всем пунктам технического задания с применением всевозможных техник тест-дизайна. Во-первых, таким образом, изучите все имеющиеся функциональности Системы, во-вторых, сможете в то же время провести тестирование всей Системы. Чем более разнообразные и приближенные к жизни пользователей сценарии и тест-кейсы будут, тем больше вероятность найти баги и проблемы. В первую очередь советовала бы проверять позитивные и наиболее критичные сценарии, далее - негативные и менее критичные. И не забывать делать регрессию перед релизом.

Я думаю, из разработчика в хорошего тестировщика вполне можно переквалифицироваться. У меня самой знакомый - бывший разработчик, хороший тестировщик-автоматизатор. Почему бы нет. У каждого могут быть свои причины, почему пришли в тестирование.

Решила selenium пока попробать. И вот пару часов уже потратила на следующее.

Есть код элемента <span class="ui-button-text ui-c">Найти</span>

Пробую 

1 способ WebElement element = driver.findElement(By.linkText("Найти"));

2 способ WebElement element = driver.findElement(By.className("ui-button-text ui-c"));

И каждый раз ошибка наподобие

org.openqa.selenium.NoSuchElementException: Unable to locate element: {"method":"link text","selector":"Найти"}.

Что-то я туплю. А как правильно написать?

 

irko,

 

 как успехи?

 

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

 

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

1) А попробуйте-ка составить план.

Во-первых, нужно время на обучение. Причем, судя по написанному, надо не только знакимиться с инструментами тестирования, но и подтянуть теорию и практику программирования. Как минимум, одну серьезную книжку по ЯП надо прочитать и поупражняться. Это будет явно не С, а один из распространенных сегодня в автоматизации языков (Java, JS, Python, C#, Ruby, PHP, Groovy, ...). Можно за основу взять то, на чем пишут девелоперы, чтобы они могли проконсультировать.

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

Срок обучения нельзя назвать четко, у всех разная скорость усвоения информации. Но рассчитывайте, что на вхождение в тему и создание первого набора тестов может уйти месяца 2-3.

 

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

По опыту, если на автоматизацию выделяется меньше 50% времени, она либо не дает никакого результата, либо автотестами покрываются отдельные избранные кусочки из серии "трудно/долго/нудно делать вручную". Ну, или можно сделать сокращенную регрессию, но это уже на более поздних этапах.

 

Можно прямо расписать план по времени и прикинуть реалистичность.

 

2) Насчет зрелости проекта и регрессии. Бывает так, что создаются компоненты, которые потом мало изменяются. В этом случае чем раньше начать автоматизацию регрессии, тем больше эффекта можно от этого получить.

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

 

3) Теперь о неизбежном. Раз РП настаивает, начать заниматься имеет смысл, даже если архитектура проекта пока не устоялась. Надо сделать небольшой "пилотный" проект, при этом изменчивость проекта пока не играет никакой роли. Важно выработать подход и получить опыт. Тогда и РП увидит, на что он сможет рассчитывать, и Вы сможете точнее оценивать нужные сроки.

Спасибо большое! Постараюсь следовать Вашим советам.

Проект планируется быть достаточно сложным. Selenium IDE, скорее всего, будет и правда не хватать.

Насчет времени в будущем - этот период с простоем уже заканчивается. И боюсь, что зароюсь в необходимости проводить и ручное тестирование, и разбираться с авто. Плюс еще прилично времени уходит на тест-дизайн (ведение Методики Тестирования), ее тоже нужно поддерживать и на ревью проектной документации (в ней часто бывают ошибки, которые лучше выявить на более ранних этапах).

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

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

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

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

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

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

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

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

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

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

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

Вам больше по душе сидеть на П...??? Не переживайте, у вас хороший РП.

1. понимает, что автоматизация делается не за 1 день

2. дает вам реальный шанс вырасти профессионально

3. дает вам реальный шанс вырасти материально

4. дает вам реальный шанс продвинутся по карьерной лестнице

 

Приступайте к автоматизации или упустите свой шанс.

1. Поговорите с вашим действующим автоматизатором, что он скажет. Не стесняйтесь задавать вопросов.

2. Возьмите Java + Selenium 2, если он ничего не посоветует. Ничего супресложного, главное макаронный код не лепить, чтобы потом все не переделывать.

3. Выделяйте 2 часа времени в день на автоматизацию, тем более это у вас офиц. направление

4. Не будете успевать в ручном, не переживайте. Возьмете ещё одного тестировщика.

 

Автоматизация для тестировщика всегда хорошо.

 

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

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

А подскажите еще, пожалуйста, в wiki написано по Selenuim-у по поддерживаемых браузерам.

Вычитала:

OperaDriver requires Opera 12.x and older versions

Older - имеются в виду последние версии? 

 

А подскажите еще, пожалуйста, в wiki написано по Selenuim-у по поддерживаемых браузерам.

Вычитала:

OperaDriver requires Opera 12.x and older versions

Older - имеются в виду последние версии? 

 

Да

Но не заморачивайтесь пока на кроссбраузерном автотестинге. Это далеко не всегда нужно

 

Спасибо!

Я бы делать автоматизацию на сыром проекте не рискнул - дорогое занятие.

Как решили что нужна автоматизация? Кто-нибудь посчитывал трудозатраты на ней? А хорошо бы.

Решили исходя из того, что у меня сейчас есть свободное время (в течение некоторого срока) + проект будет длиться минимум 2 года, т.е. большое количество функциональностей будет на выходе.

Я как сегодня делала расчеты, сколько может понадобиться времени, и возможные проблемы. Как будет время у РП, будет обсуждать этот вопрос.