На всякий случай, стандарт устарел.

Смотрите википедию.

Добрый день

Вы имеете в виду Lee Copeland. A Practitioner's Guide to Software Test Design?

Посоветуйте, для новичка, после Савина и Куликов х2, что  лучше начать Patton R. - Software Testing или Lee Copeland. A Practitioner's Guide to Software Test Design? 

Спасибо

 

Это разные книги, обе могут быть полезны.

Пэттон - больше о процессах и документации (как Савин, только в другом разрезе и более деловым тоном).

Коупленд - больше о техниках.

что это вот именно те шаги которые надо произвести чтобы сделать "правильное тестирование", что вот именно надо "сначала планируем, потом создаём кейсы, потом запускаем их"

Ну, каждый видит то, что хочет.

В первом же абзаце раздела 1.4, посвященного тестовому процессу (в Foundation!):

"The proper, specific software test process in any given situation depends on many factors. Which test activities are involved in this test process, how these activities are implemented, and when these activities occur may be discussed in an organization’s test strategy."

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

ISTQB вообще не учит, с чего начинать тестирование. Они описывают набор разных практик. Нужно к этому относиться как к багажу знаний и унификации некоторых понятий.

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

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

Почитайте силлабусы для Advanced.

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

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

Есть другая проблема: при подготовке к ISTQB может возникнуть искажение целей. Они дают набор методик, и у человека появляется цель знать все эти методики, чтобы пройти экзамен. А потом кажется, что всё это непременно в той же пропорции надо применять на работе.

надо вводить баги со всеми стектрейсами, плюс устанавливать компонент - и соответственно новые сотрудники должны будут перед заведением нового бага поискать в базе старый баг, который они теперь смогут найти

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

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

 

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

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

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

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

вроде всё прокликали, что могло пойти не так?

 

в результате оказывается что используя РЕСТ АПИ любой пользователь может удалять чужие сообщения! так как контроль доступа на бэк-энде сломался либо его забыли имплементировать вообще, и только на фронте кнопка появлялась или исчезала, а бэкэнд оказывается всегда исполняет команды

 

Это говорит только о неполноте регрессии. У нас на проекте, где лид был строго убежден в неэффективности автоматизации, все точки доступа всё равно проверяли руками через Fiddler.

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

Это даже не вписывается в классификацию атрибутов качества продукта. Можно за уши притянуть к тестированию развертывания или конфигурации.

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

Во-первых, насчет Restrictive constraints. Противоречия в последнем варианте снова есть. Я больше не буду ни на что указывать, лучше найдите сами.

Во-вторых, результаты экспериментов. Вот максимальная модель, которая у меня заработала (некоторые обозначения поменял для своего удобства). Контейнеры выкинул, т.к. в них и была проблема. Всё же, для системы первичны значения AccessRT/PT/AT, а контейнеры - это просто их комбинация.

Solution:       Solution, None
AccessSolution: F, R, CRUD, CRU, CRD, None
AccessRT:       F, R, CRUDE, CRUD, CRU, CR, RUDE, RUE, RUD, None
AccessPT:       F, R, CRUDE, CRUD, CRU, CR, RUDE, RUE, RUD, None
AccessAT:       F, R, CRUDE, CRUD, CRU, CR, RUDE, RUE, RUD, None
TypeRT:         L, F, O, LFO, None
TypePT:         L, O, LO, None
TypeAT:         L, F, O, LFO, None
AccessTypeRT:   RUD, RU, R, None
AccessTypePT:   RUD, RU, R, None
AccessTypeAT:   RUD, RU, R, None

IF [Solution] = "None"
 THEN [AccessSolution] = "None"
 ELSE [AccessSolution] <> "None";

IF [AccessRT] = "None"
 THEN [TypeRT]  = "None" AND [AccessTypeRT]  = "None"
 ELSE [TypeRT] <> "None" AND [AccessTypeRT] <> "None";

IF [AccessPT] = "None"
 THEN [TypePT]  = "None" AND [AccessTypePT]  = "None"
 ELSE [TypePT] <> "None" AND [AccessTypePT] <> "None";

IF [AccessAT] = "None"
 THEN [TypeAT]  = "None" AND [AccessTypeAT]  = "None"
 ELSE [TypeAT] <> "None" AND [AccessTypeAT] <> "None";

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

Итого, есть 2 идеи:

1. На каждый тип контейнера вручную делать свою модель, и в ней лишние поля просто удалять. Пока получится 5 файликов, не страшно.
2. Тестов всё равно очень много - сотни. Это явно неподходящая техника для создания ручных тестов. А если автоматизируем, то можно вообще выкинуть pairwise и тестировать всё подряд. Здесь 2 "но": это можно сделать, если тесты быстрые (всё же, сплошным перебором их будет на порядок больше), и если технически возможно написать оракул для проверки любой комбинации.

Проверьте, если я ошибаюсь.

IF [Container] = "RTPT" THEN [TypeRT] = "listRT" OR [TypeRT] = "formRT" OR [TypeRT] = "operationRT";
IF [Container] = "RTPT" THEN [TypePT] = "listPT" OR [TypePT] = "operationPT";

Это означает, что валидно [Container] = "RTPT", [TypeRT] = "listRT", [TypePT] = "listPT".

Далее по модели:

IF [TypeRT] = "listRT" THEN [AccessTypeRT] = "RUD" OR [AccessTypeRT] = "RU" OR [AccessTypeRT] = "UD" OR [AccessTypeRT] = "R";
IF [TypeRT] = "listRT" THEN [AccessTypePT] = "0";

и:

IF [TypePT] = "listPT" THEN [AccessTypePT] = "RUD" OR [AccessTypePT] = "RU" OR [AccessTypePT] = "UD" OR [AccessTypePT] = "R";
IF [TypePT] = "listPT" THEN [AccessTypeRT] = "0";

Похоже на противоречие.

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

Поправочка. Конечно, можно сказать, что пара [TypeRT] = "listRT" и [TypePT] = "listPT" будет невозможна по исходным данным.

Но не уверен, что PICT может выводить такое из зависимых условий. Может быть, ему надо указывать такие ограничения более явно.

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

Но последний вариант уже несовместим с первым.

И в последнем вообще запутались, например, "IF [Container] = "RTPTAT" THEN [TypeRT] = ..." определено 2 раза по-разному, да и не только это.

Если не ограничивать модель, то он пытается построить пары "все со всеми".

Условие:

IF [Solution] = "Solution" THEN [TypeRT] = "0" OR [TypePT] = "0" OR [TypeAT] = "0";

фактически означает, что не может быть Solution и RTPTAT. Соответственно, нельзя построить пары RTPTAT со всеми значениями AccessSolution.

Про RTPT так сразу не видно, но наверняка, тоже что-то не стыкуется.

А вообще, все ли комбинации имеют смысл? Может быть, надо ограничить подбор комбинаций только между определенными колонками?

1. а. Вы не отказываетесь от тест-кейсов. В стандартном подходе автоматизация - это те же тест-кейсы, только в виде скрипта.
   б. С гуглотаблицами может быть проблема. Это не общепринятый формат, придется клепать свои адаптеры или договариваться с заказчиком, чтоб принял ваш формат.
2. Наверное, вот именно. Даже на моем текущем сильно забюрократизированном проекте считается, что автоматические кейсы могут служить документацией сами для себя.
3. Непонятно. Вы собрались делать 100% автоматизацию? Так обычно не делают, хотя зависит от специфики продукта.

Есть известные подходы, и это:

• BDD (или keyword-driven, с использованием тех же инструментов)
• Allure
• Robot Framework

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

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

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

Если честно, пытался вспомнить, когда и где я его начинал изучать, но не вспомнил. Явно не по документации - она слишком мутная для начального этапа.

Ищите в сети уроки и статьи по ключевым словам "maven surefire junit" - их там много.

 

но всё равно он не запускается(((

И снова, этого делать не нужно. Тесты, собранные с помощью мавена, запускать предполагается с помощью мавена, а не из джарника. По вашей же ссылке всё написано.

Что такое "при сборке"? Таргет какой вызываете? (по логу не видно).

Idea, может быть, просто compile делает, а надо package.

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

Для этого должна быть определенная культура обеспечения качества в компании.

Вокруг меня, как правило, разработчики считают, что на тесты нужно тратить минимум времени. Пишут для формального покрытия кода, и пишут в стиле "2+2=4" вместо проверки хотя бы граничных значений.

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

Недостаточно элегантно, но просто делали каждый раз один кейс, в нём ссылка на вики, а в вики чеклист.

 

Недостаточно элегантно, но просто делали каждый раз один кейс, в нём ссылка на вики, а в вики чеклист.

то есть есть список кейсов, проваливаешься в один, а там только ссылка и больше ничего?

 

Главное же идея, а как именно оформить - смотрите сами.

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

Всем доброго времени суток! Не первый раз слышу от многих (более опытных) коллег в сети, что нужно строить архитектуру автотестов так же как и архитектуру основного ПО, в том смысле, что (внезапно) автотесты - это точно такое же ПО (только более узкоспециализированное) и оно подвержено точно таким же проблемам и особенностям как и обычное ПО. Есть наиболее распространенные паттерны проектирования, такие как, например, PageObject'ы, DataProvider'ы, etc. Как это всё более-менее грамотно объединить/построить, чтобы через N лет не выбросить автотесты совсем или потом не хвататься за голову при внесении незначительных изменений в один тест?

Рассмотрим альтернативу выбрасыванию

Если ПО развивается, тесты придется развивать параллельно с ним. Тесты, работаюшие через N лет - это фантастика.

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

А если по теме вопроса - "Как это всё более-менее грамотно построить", то этого не рассказать на форуме.

Читайте книги, например Р. Мартин "Чистый код" и "Чистая архитектура", и черпайте из них то, что кажется уместным для тестирования.

Здравствуйте!

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

В итоге, после собеседования 2-3 часа я просто прихожу в себя, никак не могу сосредоточиться на работе. Практически, день насмарку.

Может быть, вы или ваши коллеги с таким сталкивались? Как справляетесь?

(Алкоголь не предлагать, мне же еще работать надо )

Но ведь время видимой загрузки элементов состоит из загрузки по сети, отработки скриптов и рендеринга в самом браузере.

Вы рискуете написать тесты, на которые потратите кучу сил, и которые не будут давать нужной информации: что именно фиксить?

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

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

Значит искать надо в сторону нагрузочного тестирования. Понятно. Это территория Jmeter?) Можете что-то подсказать по этому поводу?

Да, это в некотором роде стандарт. Возможно, поймете, что в JMeter что-то вам не хватает.

 

наверное можно так:

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

 

вы потом эту аналитику проанализируйте, постройте там графики разные

 

 

Очень интересный ход мыслей. А какая есть литература/мануалы на эту тему?

 

Из недавно виденного на эту тему:

1 (как в Mail.ru мониторят свой фронтенд для почты)

2 (не самый удачный для прослушивания доклад, но некоторые идеи для аналитики почерпнуть можно)

Не работал, но автоматизируя чужую разработку, стабильных тестов никогда не напишете. Сами работники Яндекса писали, что тестируют через сранение скриншотов, но они-то могут проконтролировать, когда у них представление карт поменяется, или подкладывать тестовые данные. А вы будете работать с "живыми" картинками, где объекты будут появляться и исчезать непредсказуемо при обновлении публичных карт.

У Яндекс.Карт есть описание API, которым пользуются ваши разработчики. Там на выбор маркера навешивается некоторый обработчик события. Поэтому разумно сначала написать тест, где этот обработчик будет вызываться самим тестом в JavascriptExecutor. Конечно, с точки зрения бизнеса еще необходимо проверить вручную, что это всё работает с точки зрения пользователя. Но эту ручную проверку можно делать разово при приёмке и перед релизом.