02:29​ Как разобраться с black box

04:08 В чём смысл тестирования

05:13 Что такое «интеграционное» и всякое другое тестирование

​07:02 Тестирование — сервис, который «приносит вопросы на ответы»

07:50 Должен ли тестировщик давать рекомендации о том, как делать ПО?

09:47 Что такое «требования»

10:14 Что такое «анализировать»

Прошедшей осенью поговорил со студентами кишинёвского политеха про тестирование ПО.

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

Я же не зачитываю доклады по-бумажке, я их «думаю» в момент разговора. В такие моменты во мне кагбэ работают две дорожки воспроизведения, где на одну постоянно в фоне записывается мысля, которую нужно оформить, а с другой эту мыслю постоянно выводят в эфир. Это такой тип мышления, у него даже есть какое-то научное название. Можно предварительно и тщательно продумать и упорядочить всё содержимое доклада, но когда дан старт, вся предварительная подготовка идёт к чёрту, в момент доклада я полностью погружён в мысли и не знаю точно, что именно скажу дальше. Слова готовит и выдаёт моё подсознание, а я слушаю то, что озвучиваю и на ходу это всё как-то куда-то корректирую. Реально, в такие моменты моё сознание существует сразу на два потока.

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

Ресурсы мозга завыли кулерами (которых, как известно, нет) и я смотрелся как начинающий докладчик, который раздражающе часто запинается и делает долгие паузы перед тем как произнести очевидно единственно нужные слова. Стресс, конечно, тройной.

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

Подержал монологическо-монофоническую речь перед студентами курса «Certified Unicorns» по одолению ISTQB.

Они там вже вщент запутались:

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

или им раздают задачи, где надо думать, а это, естественно, очень неприятно.

Солдат ребёнка не обидит. Было нормально остановиться и объяснить, что вообще происходит, почему, зачем и куда.

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

Нужен конкретный пример. А то без примера каждому… парню кажется, что его принимают за идиота.

Например, здравствуйте, дети, вот это револьвер Смит и Вессон. Им можно решать разные задачи на поле боя. А ещё из него программист может выстрелить себе в ногу несколько раз. Сейчас я вам это покажу на конкретном примере. Ну, чья нога послужит хорошим, конкретным примером? Кто из вас знает C++?

Если пример непонятный — садись и слушай. Однажды, давным-давно…

Глава первая, вступательная в зыбкое болото терминов

Верификация — проверка соответствия приложения прописанным требованиям.

Валидация — проверка соответствия приложения всем остальным (подразумеваемым) требованиям.

Ну, и чо?

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

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

Верификационные тесты, с отсылками к требованиям, программисты принимали, не каркая.

А валидационные запросто отклоняли, бо «тестируется сценарий, которые не предусмотрен требованиями».

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

Если в этот момент юзер решит вернуться на шаг назад — он должен передвигаться между экранами только через JS-кнопки «back» и «forward» в приложении (почти каждый современный сайт — приложение). Так написано в требованиях, так реализовано программистами.

А если нажать на кнопку [Back] в браузере — всё поломалось.

Это очевидно для пользователя? Нет.

Пользователь может нажать на кнопку [Back] в браузере? Может.

И получит белый экран, и все данные пропали? Получит. Вот скриншот. Вот видео. Давайте чинить!

Ответ: Declined (out of requirements).

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

А понимал бы я тогда разницу между верификацией и валидацией…

«…я, может, и не женился бы» © бородатый папа дяди Фёдора

Глава вторая, патетическая, в которой шахматист ВНЕЗАПНО понимает, кто придумал защиту Тартаковича

А теперь будет ход конём.

Или про шахматы тоже надо отдельно объяснять?!

Поскольку мы занимаемся только тестированием и игнорируем всю остальную Computer science (нам о ней на курсах не докладывают!), то может показаться, что вся эта верифилидация — сугубо тестерское дело, которое относится только к тест-кейсам.

Нет.

Это всё приходит к нам из предыдущего этапа, на котором кто-то придумывает требования.

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

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

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

Ещё в прошлом веке человечеству было известно, что сами требования можно и нужно тестировать с помощью — и вот этот ход конём! — тех самых понятий Verification & Validation. Ёпт!

Об этом подробно написано в книге Karl Wiegers „Software Requirements“ (third edition) на стр. 331.

Где взять эту книгу — а проверь свои гигабайты скачанных, но не прочитанных книг, наверняка она там есть. Или глянь Amazon.

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

* Не дёргаемся, это единственно точное слово для описания того перевода.

В той же книге Вигерса на стр. 347 написано про Validating requirements with acceptance criteria. Знакомый термин? Он тоже кажется сугубо тестировщицким? 🙂

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

Или вот те раз, вот те два, вот те три — примеры очевидных техник проработки требований. Посмотри, как много из этого понятно тестировщику.

Тестировщику надо уметь прорабатывать требования? Надо.

Для этого надо быть аналитиком? Нет.

Важно уметь не подменять простую логику («я прочитал требования») с той самой аналитикой («я изучил требования»).

Совершенно ненужный эпилог

«Мы считаем сумасшедшими тех, кого не понимаем, и дураками тех, кто не понимает нас.

Поэтому сумасшедшие считают всех дураками, а дураки – сумасшедшими» ©

You know it’s sad but true.

Бен Коллинс — Водить как Стиг

В поезде лежал, книгу читал «Водить как Стиг» Бена Коллинса (второе издание, Альпина нон-фикшн, Москва, 2018).

Высокое качество печати и оформления, отличный текст, но все-таки четыре ошибки в тексте нашел, из них две совершенно нелепые. Глаз в бревне царапает, ну да ладно.

А вот на стр. 155 разверзлись хляби подземельные, и стало ыыыы:

Санитарная проверка

Вах-вах-вах, не может же быть же…

Поискал оригинал… Оказывается, может.

Sanity check

Короче, нет никакого санитарного тестирования.

Само слово Sanity переводится на русский язык проще:

• вменяемость,
• здравомыслие,
• нормальная психика.

Нет там никаких санитаров.

То, что вы называете Sanity, по-сути есть Smoke testing.

Я ещё не знаю, когда эти термины появились, но уже давно ясно, что это два разных названия одного и того же феномена. Просто тестировщики называют это Smoke, а программисты называют это Sanity. Так они привыкли, так оно укрепилось в их литературе.

Судя по моему опыту чтения старых книг для программистов, sanity было первым.

Канер в своей книге Testing Computer Software (1988, у меня второе издание, 1999-го) не упоминает ни про smoke, ни про sanity. Самое близкое к ним есть в главе 3 ‘Test types & Software development‘ на стр. 51, и ВНЕЗАПНО оно там называется «Acceptance testing»:

Each time you receive a new version of the program, check whether it’s stable enough to be tested. If it crashes at the slightest provocation, don’t waste your time on it. This first bit of testing is called acceptance or qualification testing.

На стр. 54 та же тема с уточнениями в разделе ‘Final acceptance testing and certification‘:

If your company developed the program on contract, the customer will ran an acceptance test when you deliver it. In small projects, this test may be informal. For most projects, however, test details are agreed to in advance, in writing. Make sure the program passes the test before trying to deliver it to the customer. An acceptance test usually lasts less than a day. It is not a thorough system test. Beizer (1984) describes the preparation and execution of formal customer acceptance tests. Perry (1986) is, in effect, a customer’s guide to creating acceptance tests. Consider using Perry (1986) to structure your negotiations with the customer when you jointly design the acceptance test.

Цитата на books.google.com

Для тех, кто не может прочитать больше одного предложения в абзаце перевожу:

заранее и письменно согласуйте с заказчиком набор приёмочных тестов. Убедитесь сами в том, что релиз на них не завалится. Ранее об этом писали Бейзер (1984) и Перри (1986).

Это воспринимается странно, бо в наше время «Acceptance testing» объясняется как «Заказчик сам тестирует, как хочет». И да, вероятно, он будет основываться на наших смоук-тестах. Предполагаю, что в наше время этот термин просто истолковывается неверно, но это уже не существенно.

А вот в 2001-ом Канер уже упоминает Smoke testing в «Lessons Learned in Software Testing: A Context-Driven Approach» на страницах xxvi (это предисловие, там сходу заявлены определения ключевых терминов), 41, 121, 162, 163, 169, 141 и 144. И ни разу не упоминается sanity testing.

Рекс Блэк в «Ключевые процессы тестирования» (2004) упоминает эти два термина одновременно. В русскоязычном издании «Лори» 2006-го года они на стр. 532:

Приемочное тестирование, тестирование на исправность (Smoke Test, Sanity Test). Тестирование, проверяющее, насколько стабильная предлагаемая на тестирование версия, чтобы можно было начинать штатное тестирование. Обычно это подмножество всего комплекта тестов, как правило, автоматизированное, затрагивающее все части системы, по крайней мере, поверхностно. Качественные приемочные тесты обычно довольно долго проверяют работу системы, чтобы проявились серьезные проблемы надежности и работоспособности. Термин “smoke test” (тест на задымленность) взят из электротехники: когда инженер включает цепь, первичный тест проверяет, не дымятся ли компоненты.

Википедия

ВНЕЗАПНО сообщает о том, что сэнити — даже не из мира тестирования, термин существует сам по себе, и применим ко всем аспектам человекодеятельности, от сервировки обеденного стола до запуска ядрённой атомной бомбы на головы мирных жапонцев.

In computer science, a sanity test is a very brief run-through of the functionality of a computer program, system, calculation, or other analysis, to assure that part of the system or methodology works roughly as expected. This is often prior to a more exhaustive round of testing.

Огромное, гигантское отличие от smoke test, да?!

ISTQB (скачать файл Glossary all terms 3.1.pdf).

Sanity test объявлен синонимом smoke test (стр. 61).

В канонах ISTQB вы не сомневаетесь, не так ли?!

Толковалка ISTQB

It is a kind of software testing which is done by the testers to ensure that the functionality is working as expected.

Огромная разница со smoke test, да?!

Кто-то сделал почти тот же обзор книг в поисках тех же терминов, что и я: almeln.github.io, и пришел к тем же выводам.

О переводах: «Да, но ведь гугл переводит это слово именно так!»

Google переводит слово Sanity

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

И напоследок. Я предполагал, что ебалайтунг с терминологией присущ нашему, русскоязычному сектору. Например, вон чего на protesting.ru пишут:

В некоторых источниках ошибочно полагают, что санитарное и дымовое тестирование — это одно и тоже. Мы же полагаем, что эти виды тестирования имеют «вектора движения», направления в разные стороны.

Но он процветает и на английской стороне. Быстро нагуглилась статья на эту тему с сайта h2kinfosys.com — оба термина представлены как нечто обособленное. Понятия не имею, что это за контора из штата Джорджия (США), но о себе они говорят «H2k Infosys provides world class IT Training, Real-time Live Project to gain hands on experience, and IT Staffing services».

Надо ли возражать людям вообще?

Предположим, что ответ «А мы проверяем то, что на сервер разрешено загружать только файлы с расширениями, разрешенными в параметре document-types«.

Сократим его, Сократ! Выбросим необязательное вступление, и  вот нам элегантный заголовок-утверждение «На сервер разрешено загружать только файлы срасширениями, разрешенными в параметре document-types«.

Почему заголовок выглядит как утверждение? А потому, что должно же в этом мире что-то быть однозначным.

Помним и о том, что первое слово в каждом действии должно быть глаголом.

Доклад зачитан 2 июня 2017 в Киеве, на конференции testingstage.com

Вот это самое «State-Transition Testing»

Трабла уже описана профессором Преображенским в соответствующей литературе в качестве первопричины разрухи.

Тут надо думать «исходное Состояние системы — Действие — иное Состояние системы».

А мы с «деццва» учимся продумывать тест-кейсы как «Действие — Результат действия».

Вот «кружочки» и не получаются.

А получается что-то вроде ‘Product available in the Cart — Proceed to Checkout — Checkout Page opened‘. Бред-то какой, полюбуйтесь на вашего Полиграфа…

Ну а потом начинается извечная шумерская жалобная песнь для успокоения сердца (просто выберите любимое и добавьте воды):

• У нас нет времени на тест-дизайн…
• На нашем проекте это не используется…
• Никто на проекте не говорит, какую именно технику надо использовать…
• Я тестирую только экивалентность и границы значений, и этого достаточно…
• Пожалуйста, спасите-помогите…
• Все эти техники — для задротов, реально они ничего не приносят…
• Я буду это применять, если это реально поможет уменьшать количество тестов…
• Тест-кейс — это когда надо проверить, что по шагам надо выполнять, и софт работает…
• Я клоун…

Что надо сделать

1. определить happy path — их может быть несколько.
2. определить другие сценарии и ветвления к ним.
3. выводить в отдельные ветки всё, даже если они подразумевают переход к одному и тому же состоянию (есть множество исключений, но это должно быть основным подходом; впоследствии он сэкономит силы и нервы).
4. стрелка — действие. Круг — состояние, а не результат действия, как мы привыкли писать в тест-кейсах.
5. не запихивать всё в один рисунок. Пусть будет много рисунков. Переключайтесь между листами.
6. если что-то пошло не так и надо перерисовывать — будете материться, а не ерзать ластиком. Проще будет быстро нарисовать правильную последовательность заново, поэтому рисуйте без детальной детализации.

Приоритет показывает степень важности выполнения задачи ДЛЯ БИЗНЕСА.

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

Рекомендуется использовать всего три уровня приоритета:

1. Приоритетно,
2. Не приоритетно,
3. .

Все очень просто, не так ли? Или задача приоритетна, или нет. Tertium, кагбэ,  non datur.

Если еще более по-взрослому говорить, то приоритизация означает не простое «Давайте расположим все по-важности и будем выполнять последовательно». Оно означает необходимость от чего-то отказаться, чтобы выполнить самое важное [подробности], но это уже слишком сложные материи…

В Jira используется аж пять уровней приоритетности. Надо бы меньше, но мы все тут с Jira бесимся, поэтому будем следовать ее визионерству:

Trivial — Lowest priority, punctuation or any very small issues

In ‘Contact us’ Tahoma font displayed instead of Arial.

Nobody else see the difference. In the future this issue may be fixed. Or not, because nobody cares, this doesn’t broke the business.

Minor — Indicates that this issue has a relatively minor impact.

In the ‘Contact us’ form placeholder text in ‘Message’ field is displayed as ‘Italic’ instead of regular text.

This doesn’t broke the business, but it’s a little annoying to write and read all text in ‘Italic’. Please, can you fix it?!

Major — Indicates that this issue has a significant impact.

Sending message from the ‘Contact us’ form works well, but sender email is unknown.

Unanswered emails can lead customers to nervosity, this can affect whole business, so please, fix the problem in the most appropriate time limit.

Critical — Indicates that this issue is causing a problem and requires urgent attention.

‘Contact us’ page is unavailable.

This is a required functionality for the web store, this can have a bad impact on the business, so, Kowalski, fix the problem ASAP!

Blocker — This problem will block progress of the project.

Web store is down. ‘Contact us’ page unavailable.

User cannot open the ‘Contact us’ page, because the whole web site is down, the business is down, Kowalski, don’t panic, immediately grab the monkeys and act like the server, while we will bring him back online!

Severity

Суровость бага (ну, вы же не дураки, чтобы переводить “Severity” как невнятное “Важность” или “Серьезность“? Суровость!) показывает технологическую степень влияния дефекта на всю систему.

Внимание, на ВСЮ СИСТЕМУ, а не только на отдельно взятый сценарий или функциональность.

То есть, если при тестировании Wish List выясняется, что невозможно добавить товар в Wish List, но при этом остальные важные части веб-магазина в принципе работают, то не надо орать, что у тебя Blocker, только потому, что ты не можешь выполнить твой тест-кейсик. Оно блокер, но не для всей системы, а только для тебя одного.

Важно понимать, что реально суровые дефекты в функциях в современных веб-системах сложно обнаружить, бо современные веб-системы не состоят из цельных кусков хрусталя, который можно расколоть одним движением. Вы больше блокеров найдете в MS Word, чем в Joomla, просто потому, что какой-то хитрый баг может тупо закрэшить вам всю вордину, дальнейшие действия становятся невозможными, надо запускать ворд с нуля. А как «положить» интернет-приложение, построенное на микро-сервисах? Сервак раздолбать кувалдой… Или продумать какую-то троянистую шнягу, которая по цепочке пронесет с собой разрушительный скрипт, и всю эту цепочку будет последовательно уничтожать.

Поэтому в большинстве случаев мы используем Severity  = Major, а Blocker’ом величаем разве что какие-то важные и сложно-составные сценарии, которые по каким-то причинам очень важно пройти, но не удается.

Trivial — Minor loss of function, or other problem where easy workaround is present.

‘Contact us’ form text was designed with Arial font 14 size, but I see the Arial font 13 size instead.

This doesn’t affect the functionality at all. Anybody will care about it?

Major — Major loss of function.

User messages from ‘Contact us’ page are not received by Support team.

Everything else works fine, only this particular loss of functionality can severely affect the business issues. Kowalski, fix the problem!

Blocker — Blocks the interaction with the system, production could not run, crashes, loss of data, severe memory leak, everybody dies.

Web store become inaccessible because ‘Contact us’ script overload the server.

Server continuously restarts, nobody can access it, web store became inaccessible. This severely affect all business issues. Kowalski!

Кстати, для Severity лучше использовать побольше нюансов.

В Confluence можно грамотно разметить оглавления в тексте, заголовками уровня 1-6.

Можно вставить автоматически собираемое «Содержание» всех заголовков на странице (макрос ‘Table of Contents’).

Можно вставлять в тело страницы другую страницу, целиком (макрос ‘Include Page’).

Даже можно сделать на странице, содержимое которой надо встроить, специальное выделение текста (макрос ‘Excerpt’), и вставлять ТОЛЬКО то содержимое, которое было помеченное таким хитрым образом (макрос ‘Excerpt Include’).

Можно вставлять ссылки на другие страницы внутри Confluence аж двумя способами: по-простому (по-дурацки) и грамотно.

Вставляем по-дурацки

1. Просто скопируй нужную ссылку из адресной строки, да вставь ее в нужное место на странице открытым текстом.

Буквально copy/paste ‘httр://confluence.test/display/~a.lupan/Action+Verbs+to+be+used+in+Goal+setting+process‘ в тело открытой на редактирование страницы.

Сработает сразу.

Но вероятно не будет работать в будущем, если в названии страницы изменится хотя бы один символ — ссылка просто «умрёт».

Например, если в названии только дружественные англо-символы (вроде «Action Verbs to be used in Goal setting process«), URL страницы будет выглядеть как ‘httр://confluence.test/display/~a.lupan/Action+Verbs+to+be+used+in+Goal+setting+process‘

Если изменить заголовок страницы на «Англ Action Verbs to be used in Goal setting process» (добавить неанглоалфавитный символ, или двоеточия, или что-то еще неординарное), URL страницы поменяется на что-то вроде ‘httр://confluence.test/pages/viewpage.action?pageId=54598262‘

Всё потому, что URL страниц в Confluence создается динамически, изменяясь «на лету» в зависимости от названия страницы.

А ссылки на страницы в Confluence существуют в системе как самостоятельные сущности (переменные). Поэтому привязываться надо не к ссылкам, а к сущностям, которые хранят в себе ссылки. Поэтому

Вставляем грамотно

1)

1. Вызвать макрос ‘Insert Link’ (элементарно вызывается по Ctrl+K).
2. В окне настроек выбрать Search > искать по названию страницы.

Будет мелкий неудобняк:

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

Поэтому более точный и удобный способ: в окне настроек макроса ‘Insert Link’ открыть раздел ‘Recently viewed‘. Нужная страница там безусловно найдется, практически всегда окажется, что я её уже открывал. Клик по её ‘Title’, и всё готово.

Confluence Recently Viewed

Теперь название страницы, на которую поставлена ссылка, может изменяться как угодно, вплоть до появления ‘pageId=54598262‘ — ссылка всё равно сохраняется «живой и невредимой».

2)

Как быстро вставить ссылку, не подергивая свою мышь:

1. В открытой на редактирование странице нажать на клавиатуре клавишу ‘[‘ — появится окно ‘Link suggestions’, аналог ‘Recently viewed’.

Дальше понятно?

Ссылки на имена юзеров вызываются через ‘@‘.

Вставлять картинки: через ‘!‘.

Можно внутри страницы организовать огневые перекрестные внутренние ссылки, что дичайше котируется в больших документах вроде ‘QA Vocabulary’ (например, в нашем 226 терминов, ой-вэй).

Ссылки на разделы внутри страницы

делаются так:

1. Разметить текст как заголовок (в моем случае ‘Definitions of Selected Functional Verbs‘).
   

   Confluence Heading

2. Скопировать этот текст в буфер обмена as is. Со всеми его пробелами и запятыми, если есть.
3. Перейти в другое место страницы, где надо сделать ссылку на данный заголовок.
4. Вызвать макрос ‘Insert Link’ (элементарно вызывается по Ctrl+K).
5. В окне настроек выбрать Advanced.
6. В поле ‘Link’ своими руками вписать символ ‘#‘ и сразу текст (заголовок) из буфера обмена со всеми его пробелами, as is, буквально ‘#Definitions of Selected Functional Verbs‘
   
   

   Confluence Advanced Links

   // Внимание: The anchor name is case sensitive. You must use the same pattern of upper and lower case letters as you used when creating the Anchor.

   // После обработки текст превратится в #DefinitionsofSelectedFunctionalVerbs (ибо справка: The anchor name in the full URL is concatenated into a single word, with all spaces removed).

   // В поле ‘Link text’ автоматически будет вписан тот же текст. Его спокойно можно отредактировать, при этом содержимое поля ‘Link’ уже не изменится.

7. Insert.

Итоговая ссылка на заголовок ‘Definitions of Selected Functional Verbs‘ будет выглядеть так: httр://confluence.test/display/~a.lupan/Action+Verbs+to+be+used+in+Goal+setting+process#ActionVerbstobeusedinGoalsettingprocess-DefinitionsofSelectedFunctionalVerbs

Мелкий неудобняк: ничто не подсказывает, что надо вставить ‘#‘. GTFO, если не знаешь про этот хинт. Я про него знаю, и вроде не дурак, но иногда забываю вписать эту чертову решеточку…

Серьезный, раздражающий неудобняк: если заголовок раздела ‘Definitions of Selected Functional Verbs‘ когда-нибудь изменится хоть на одну букву, ссылка внешне останется активной, но превратится в ссылку, просто закрытую заглушкой ‘#’.

Ок, это был простейший сценарий, ссылки внутри страницы. Теперь дело посложнее:

Поставить ссылку на заголовок с другой страницы, которая находится в другом space

Учли, что прямой Copy/Paste возможен, но потенциально недолговечен, и надо действовать через макрос ‘Insert Link’ (элементарно вызывается по Ctrl+K).

И пусть там можно найти только общий Title нужной страницы, внутренние ссылки оттуда недоступны, однако действовать надо именно через макрос ‘Insert Link’ (элементарно вызывается по Ctrl+K). Если в будущем изменится название страницы, в которой находится заголовок, на который надо ссылаться, Confluence эту ссылку грамотно обновит. Confluence рулит!

Вот если внтури страницы изменится тот самый внутренний заголовок, на который сделана «ссылка внутри страницы», тогда уж увы.

И всё равно придется действовать через раздел Advanced, да еще и вручную вписывать название страницы.

А это уже раздражающий неудобняк.

Если страница с внутренней ссылкой, на которую надо сослаться, находится в том же space:

1. Вызвать макрос ‘Insert Link’ (элементарно вызывается по Ctrl+K) > Advanced
2. Вставить ссылку по шаблону ‘Page Name#MyHeading‘.
3. В моем случае это ‘Action Verbs to be used in Goal setting process#DefinitionsofSelectedFunctionalVerbs‘
4. Insert.

Если страница с внутренней ссылкой, на которую надо сослаться, находится в другом space:

1. Вызвать макрос ‘Insert Link’ (элементарно вызывается по Ctrl+K) > Advanced
2. Вставить ссылку по шаблону ‘spacekey:Page Name#MyHeading‘.
3. В моем случае это ‘~a.lupan:Action Verbs to be used in Goal setting process#DefinitionsofSelectedFunctionalVerbs‘
4. Insert.

Работает.

ВНЕЗАПНОСТИ

1)

Полностью URL на определенный заголовок внутри определенной страницы выглядит так: httр://confluence.test/display/~a.lupan/Action+Verbs+to+be+used+in+Goal+setting+process#ActionVerbstobeusedinGoalsettingprocess-DefinitionsofSelectedFunctionalVerbs

Что же это за #ActionVerbstobeusedinGoalsettingprocess-DefinitionsofSelectedFunctionalVerbs, если я вписывал только #DefinitionsofSelectedFunctionalVerbs? Что за Wtf?

Ответ такой: все в порядке.

The page name is repeated in the URL, after the # sign. The second occurrence of the page name is concatenated into a single word, with all spaces removed.

Но зачем?

Ок, учтем, что в виде ссылки надо использовать только то, что идет за решеткой, но только после дефиса.

Неочевиднейший подход. Пока это поймешь…

2)

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

Но если я решу отредактировать эту ссылку… в ней исчезает spacekey, и вместо

‘~a.lupan:Action Verbs to be used in Goal setting process#DefinitionsofSelectedFunctionalVerbs‘

там будет написано

‘Action Verbs to be used in Goal setting process#DefinitionsofSelectedFunctionalVerbs‘.

Всё, ссылка сдохла.

Не обратишь на это пристальное внимание — увы, блеать…

Confluence Space Key Disappear

3)

Confluence Help организован не по-взрослому.

Есть дефолт-справка по работе со ссылкам: https://confluence.atlassian.com/display/CONFEAP/Links

Но также зачем-то существуют отдельные страницы справка для разных версий Confluence. Например, справка для Confluenct версии 5.6 находится тут: https://confluence.atlassian.com/conf56/confluence-user-s-guide/creating-content/using-the-editor/working-with-links

Я работаю с Confluence 5.5.2, поэтому смотрю на https://confluence.atlassian.com/conf55/confluence-user-s-guide/creating-content/using-the-editor/working-with-links

Между всеми тремя версиями справки разницы НЕТ, количество слов в двух документах идентично. Wtf?

Confluence Help Links Word Count

В целом Confluence рулит неимоверно!

Просто надо немного оторвать ноги/руки тем, кто реализовал механизм работы с ссылками, и мир во всем моем мире наступит.

Сразу.

Всей подошвой.

Кагбэ, да, но тогда почему это называется «Регрессионное тестирование», а не «Перетестировывание всего заново»?

«Заново всё тестируем» — это не объяснение сути обсуждаемого феномена! Это лишь описание внешних признаков сего феномена. Так ребенок может объяснить, что такое автомобиль, не понимая, как и почему вот это вот всё работает. Вроде «Автомобиль — это когда папа за рулём, он едет на работу, а я в детский сад, и мне удобно в нём сидеть». Всё правильно же?!

Кроме термина регресс еще есть термин регрессия — сам по себе термин неоднозначный. Это бывает и в психологии, и в финансовой аналитике, и это разные феномены ВААПЩЕ.

Значитца, так. В википедии правильно указана суть термина «Регрессионное тестирование» (англ. regression testing, от лат. regressio — движение назад), но дальнейшее объяснение недостаточно адекватно. Дитячее оно.

Давайте объясняться по-взрослому.

Есть понятие Прогресс.

Есть же…

А есть понятие Регресс — обратная сторона прогресса.

Любая/каждая система по мере накопления функциональных возможностей развивается (прогрессирует). Это круто.

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

Любая ERP-система развивается по тому же принципу — все больше информации собирается и учитывается по каждому чиху. Отчёты все красочнее, объемнее, в запросах все больше ЕСЛИ и НО НЕ и КРОМЕ.

Однако увеличение функциональности незаметно приносит и увеличение взаимосвязей между функциями.

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

Это и есть регресс.

Чтобы убедиться в том, что в существующей системе не начинается регресс, полезно иногда проводить ее полное тестирование.

И уж тем более логично перетестировать всё, что можно, если в систему были внесены какие-то существенные изменения.

Со стороны это выглядит как «Внесли новый функционал — обязательно перетестировываем всё!» Словно тестировщики в тысячный раз прогоняют уже существующие тесты, вот и всё.

Не всё. Этого недостаточно.

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

Смысл просто гонять старые тест-кейсы, если они были написаны без учета новых ситуаций?

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

А «в интеграции» бытуют такие баги, о которых и не догадаешься, рассматривая функцию логина по-отдельности от остальных функций…

Поэтому регрессионное тестирование — нескончаемый кошмар, вообще-то… И выяснение «не наступил ли регресс» (внимание, не путать с «не наступила ли регрессия«) — постоянная задача, которую с какого-то момента необходимо постоянно решать.

В любом проекте с какого-то момента начинается уже не улучшение продукта, а борьба за «чтобы оно всё еще продолжало работать, как раньше«… с постоянным выяснением, а не наступил ли регресс из-за усложнения системы.

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

Но чем дальше влез в лес…

Ещё в тему

Regression is my profession!