Learning to Think

Every thuth has four corners: as a teacher i give you one corner, and it is for you to find the other three
— Confucius

О чем он говорит? Разве не должен учитель показать все 4 угла и явно их описать? Нет. Чтобы по настоящему научиться, запомнить и понять, ты должен постоянно задавать вопросы, стремиться к поиску знаний. Если нет реального желания глубже понять тему, то все мудрые принципы стекут с вас как с гуся вода. ©

Честно говоря, не помню, в какой из книг я прочитала эту цитату (давно уже сохранила в черновики, а теперь разгребаю их). Скорее всего, в «Secrets of a buccaneer-scholar» James Marcus Bach или «Lesson Learned in Software Testing». Но сама по себе идея очень важная.

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

И здорово, когда вам тема настолько интересна, что вы сами в ней копаетесь. Задаете доп вопросы, делаете не только то, что тренер сказал, но даже немного больше! Такой огонек в глазах всегда ценится. И кстати, именно он виден на собеседовании. Это называется «горящие глаза», когда человек говорит про интересную ему тему, он всегда копает чуть глубже.

Как-то так...

Бесплатное место под ИТ-тренинги на 15 человек

Ссылка на оригинальный пост в фб.

Предлагаем переговорную HFLabs в качестве бесплатного места проведения небольших митапов или тренингов на IT-тематику (на 15-20 человек). Взамен за это — участие 1-2 человек от HFLabs в вашем мероприятии ツ

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

Нам все равно, платный ваш тренинг или бесплатный — мы всем будем рады. Главное, чтобы тематика была интересна кому-то из наших коллег.

Несколько минут пешком от метро Парк культуры: Турчанинов переулок, д. 6 стр. 2, БЦ «Крымский мост», 1 этаж (контакты).

Мероприятия можно устраивать после 18 в будни или в выходные.
Если интересно — пишите Лере Таныгиной на почту valeriyat@hflabs.ru или в личку HFLabs на фб. Ждем вас ツ

Максимальная концентрация. Люси Джо Палладино

Ссылка на OZON

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

• Нужно задавать себе вопросы «Что я сейчас НЕ делаю?»
• Нужно осмысливать свое поведение, словно сторонний наблюдатель.
• Нужно говорить себе «Я работаю, я работаю», когда ручки тянутся на котиков посмотреть
• ...

Пока читаешь, кажется «Пфффф, ничего необычного, даже не стоит пытаться». Но фишка в том, чтобы попытаться применить эти «легкие» методы. Я тоже сначала пфыкала, но потом специально концентрировалась на текущем деле. 

В конце концов, я книгу то начала читать потому, что у меня тяжело с концентрацией в последнее время. Книгу пишу? 5 минут пописала и ручки тянуться открыть фейсбук. Причем в ленте нет ничего нового, недавно просматривала, но все равно сидишь и тупо скролишь. Книгу читаю? Почитала минут 10 и снова хочется прекратить. 

Contains строки в XSLT

В нашей системе есть SOAP-методы и есть автотесты на них. В автотестах применяются файлики transform.xslt — чтобы можно было переформатировать ожидаемый результат и проверять только те поля, которые нужны нам в данном тесте.

См также:
Folks — open-source проект с API-тестами на Java → там есть пример автотеста на SOAP с transform.xslt
Эволюция нашего использования XSLT в SOAP-тестах → подробнее про наши тесты


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

<xsl:variable name="fieldsToCopy">
        |surname|name|patronymic|fullNameRawSource|fullNameQC|
        fioTrusted|birthdateTrusted|innTrusted|snilsTrusted|
        </xsl:variable>

А потом мы указываем, что нам нужны все поля переменной fieldsToCopy через contains

<xsl:apply-templates select="cdi:field[contains($fieldsToCopy, @name)]">
      <xsl:sort select="@name"/>
 </xsl:apply-templates>

Так вот, запускаю я тест, он падает, ожидаемый ответ не совпадает с моим. Смотрю, почему — в actual_transformed_response.xml вижу дополнительные поля: inn и snils

Эволюция нашего использования XSLT в SOAP-тестах

В нашей системе есть SOAP-методы и есть автотесты на них. В автотестах применяются файлики transform.xslt — чтобы можно было переформатировать ожидаемый результат и проверять только те поля, которые нужны нам в данном тесте.

См также:
Folks — open-source проект с API-тестами на Java → там есть пример автотеста на SOAP с transform.xslt

Этап 1. Сортировка

Сначала мы использовали transform.xslt для сортировки данных. Просто чтобы тестировщик мог указать в response.xml поля в любом порядке, чтобы перестановка местами не приводила к падению. А потом начали трансформировать ответы...

Этап 2. Исключение часто меняющихся полей

Исходно мы начали применять трансформацию для исключения строки из проверки. У нас есть стандартизация адресов, которая определяет кучу параметров, в том числе код КЛАДР или ОКАТО. А они могут меняться...

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

Так что нам надоело поднимать интеграционники каждый релиз, и из проверки адреса выкинули коды и дату актуальности КЛАДР (тоже с каждым обновлением менялась):


<xsl:apply-templates select="@* |
         cdi:field[
         @name!='kladrActualityDate' and @name!='kladrCode' and @name!='okatoCode'
]">

Классификация тестирования

Разделы видео

1. По знанию системы
2. По позитивности
3. По целям (объекту)
4. По исполнителям (субъекту)
5. По времени проведения
6. По степени автоматизации
7. По состоянию системы
8. По формальности

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

Anyway, про классификацию часто спрашивают на собеседованиях, так что совсем обойти ее стороной я не могла ツ

Статьи про классификацию

Инструменты для Pairwise

Desktop (windows, linux)

Самые популярные:

• Allpairs — скачать тут, инструкция тут. Самый простенький, но есть под все платформы, очень удобно (включая Mac)
• PICT — скачать тут, инструкция тут. Имхо, он "красивее" показывает входные файлы (строки, а не столбцы) + позволяет задавать условия IF =)

Есть еще куча разных, искать тут — http://www.pairwise.org/tools.asp

Mac

Для тех, у кого Мак - пару идей:

— можно скачать отсюда https://sourceforge.net/projects/allpairs/. Там python скрипт, который через терминал запускается → https://testitquickly.com/2017/02/13/allpairs/

— PICT тоже должен работать, вот этот https://github.com/Microsoft/pict

— или попробуйте с этим сайтом http://alarcosj.esi.uclm.es/CombTestWeb/combinatorial.jsp

Online

Так же есть онлайн тулза — https://inductive.no/pairwiser-tool/. Позволяет отметить отдельные пары как невозможные.

А вот еще очень простая — https://pairwise.teremokgames.com/


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

Как я забыла проверить обрыв соединения в процессе работы

У нас есть обратный поток в JMS, но обычно мы отправляем сообщения в EMS (Tibco). Тут возникла задачка отправлять сообщения сразу в два потока: EMS и RabbitMQ.

Так как на EMS уже все проверено и протестировано, размышляю я, моя задача только в том, чтобы проверить, а работает ли тоже самое для RabbitMQ. И даже учла возможность нерабочей шины! Проверила разные варианты, причем в автотестах:

1. Настройка включена, параметры настроены — все работает.
2. Настройка включена, параметры не настроены — в лог падает ошибка.
3. Настройка выключена, параметры настроены — сообщения НЕ уходят, настройка то выключена.
4. Настройка выключена, параметры не настроены — сообщения не уходят, проверки на корректность параметров нет (ошибки не валятся).

См также:

Применение класса «ноль-не ноль» при подключении к JMS — подробнее о том, почему именно такие тесты.

Все хорошо, все работает. А если настройка выключена или сам рэббит не работает — тоже все хорошо. Отдали Заказчику на тестирование. Они проверяют на своей стороне и приходят с вопросом:

Типы границ на примере стиральной машинки

Это статья из серии «Теория в картинках»

В моей классификации есть всего три типа границ (мнемоника ЛТП):

• Логическая — ограничение, накладываемое логикой, не программой.
• Технологическая — ограничение, накладываемое используемой технологией
• Произвольная — ограничение, накладываемое аналитиком или разработчиком.

(Откуда взялась моя классификация, я тоже напишу, но чуть позднее в другой статье. Скажу лишь, что автор типов — Алексей Баранцев, переиспользовать в книге / статьях разрешение давал)

Типы границ на примере стиральной машинки

(Пример любезно предоставлен Юлией Мироновой)

У вас есть стиральная машинка.

1. Логическая: нельзя засунуть меньше 0 киллограммов белья. Это логика.

Не заставляйте меня думать. Стив Круг

Ссылка на OZON

Боже мой, где эта книга была раньше? Это же просто прекрасно! Книга о юзабилити, которая.. юзер-френдли! Тонкая, много картинок, большие отступы между абзацами, читается легко и быстро... Must read!

Как сам автор пишет, он хотел, чтобы его книгу можно было прочитать за время перелета или другого длительного ожидания, но одного. Это круто! Тоже хочу такую книгу. На самом деле я свою книгу для начинающих исходно планировала как второго Савина, тоже тоненькую. Мол, что там такого рассказывать то? Но что-то где-то пошло не так ツ Будет толстая, как серия «Head First O`Reilly». Ну и ладно! Зато у меня примеров реальных много, это полезно. Но потом! Потом хочу тоненькую книжку, вот как эта от Стива Круга )))

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

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

Я при чтении не чувствовала какого-то раздражения из серии «здравствуй, кэп». Да, многое кажется очевидным, но при этом в духе «Да! Да! Именно так и надо», а не «Пффф, я и так это знал» ツ

Мысли, которые я себе выписала:

Мнемоники: БЛОК, СЛОН и NOPE

На моем курсе «Школа для начинающих тестировщиков» есть творческое задание — придумать свою мнемонику по тестированию! Разумеется, оно необязательное ツ

Посмотрите, что придумали ребята на этот раз!

Михаил: БЛОК

Вера: СЛОН

Тест должен быть конкретным!

Прочитав тест, я должна понять:

• Что мне сделать;
• Как это сделать;

Допустим, мы тестируем навесной замок:

Как будем тестировать? "Ну, я его открою и закрою" или “проверить, что он открывается и закрывается” — это не тест.

Классы эквивалентности для строки, которая обозначает дату

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

Но потом доходит до дела и сразу ступор: а как применять классы эквивалентности где-то еще? Ладно, используем правило «ищи число»: если речь идет о поле с символами, берем длину поля (число) и тестируем на границы. Вроде все хорошо, логично и понятно.

Однако на своих студентах я заметила, что это правило стало серебряной пулей. Если это нечисловое поле — по границам тестируем ТОЛЬКО на длину. Точка. Просишь протестировать дату, получаешь примерно такой ответ:

• Нормальная дата (17.03.2018)
• Дата «в прошлом» или «в будущем» (смотря что подходит под ваше ПО)
• Пустое поле
• Нафигачили туда 100500 символов
• Ввели «0»

За сим границы и проверены. И даже ноль проверен, чем тренер недоволен? А тренер недоволен тем, что по границам вместо ДАТЫ тестируется СТРОКА. Поэтому я предлагаю написать проверки именно для даты. И прежде, чем читать дальше, отложите книгу в сторону и попробуйте сами набросать эти проверки.  А потом сравните, все ли вы нашли?

Четкий формат дд.мм.гггг

Допустим, я могу ввести в профиле свою дату рождения и система сама посчитает, сколько мне лет. Формат даты известен заранее, на поле стоит маска, дату в другом формате я ввести не смогу.

Додо книга

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

Отличная книга из серии success-story про развитие бренда, как книги про Starbucks, Zappos, Toyota и т.д. Тоненькая, читается легко и быстро, я за пару поездок в метро прочитала.

В книге рассказываются концепции бренда, но соотношение «теория-практика» самое мощное из всех книг про бренды. Тут нет воды, сплошные истории из жизни. Очень интересно читать ツ

В Додо все, кто приходит в компанию, начинают с кухни. Делают пиццу, моют посуду, столы, месят тесто... Все, включая топ-менеджеров и региональных директоров. И сам основатель, Федор Овчинников, постоянно приходит поработать в свою пиццерию, чтобы лучше понять саму суть работы.

Folks — open-source проект с API-тестами на Java

Ссылка на youtube

Знакомьтесь, это Folks! Проект с открытым исходным кодом, сделанный на основе реальной системы. И в этом его ценность — это не просто абстрактный тестовый проект, написанный под студентов, неприменимый в реале.

Ссылка на документацию — https://testbase.atlassian.net/wiki/spaces/FOLKS/overview (доступна без авторизации)

Что интересного есть в проекте:

• Требования на поиск — можно проверить свои познания в тест-дизайне и тест-анализе.
• Фреймворк автоматизации — самое важное, что дает система. Возможность пощупать реальный фреймворк автоматизации. Увидеть, что автотесты — это не обязательно чистый код, это могут быть просто... Эксельки. Да-да!
• Код есть, GUI нет — тоже важное свойство. Если вы хотите проверить какую-то теорию, то только через автотесты. Для тестировщика важно уметь придумывать тесты ДО того, как их можно будет пощупать, но это тяжело. Осилите?))
• SOAP и XSLT — добавили в систему недавно, чтобы поиск можно было дергать и по SOAP в том числе. Сделано под будущий курс интеграционного тестирования, но пользоваться можно уже сейчас!

Тут и свои навыки тест-дизайна можно проверить, и баги в коде найти, и поавтоматизировать попробовать... Welcome!

См также:

Автотесты на уровне API для Java-приложений — доклад с SQA Days, где я рассказываю принципы, заложенные в тестовый фреймворк автоматизации.

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

Также буду делать дополнительные обучающие видеоролики, чтобы еще проще было начать автоматизировать в фолкс. Буду показывать, как это все делается. Ждите 

Панбагон. Вам не хватает «минус 4 тыс» на балансе

Попробовала я тут на wildberries списать деньги с баланса. Благо что деньги есть 5000 (делали возврат), а у меня заказик на 700р.

Оформляю заказ, система мне сама подсовывает способ оплаты «списать с баланса» — она так всегда делает, если сумма заказа меньше, чем денег на счету. Ок, не вопрос, списывай. Ввожу код подтверждения из смс и... Получаю гениальную ошибку:

«У вас не хватает -4 768 рублей»

Ошибка баланса

Вот так ツ

Кодеры за работой. Питер Сейбл

Ссылка на Литрес

Это оказалось немного не то, что я ожидала ツ

Судя по названию «кодеры», которое немного обидное, я думала это будет что-то типа «Софт отстой», весело и с юмором. Как потом оказалось, автору просто понравились серия «Писатели за работой» журнала «Paris Review» и книгой «Founders at work» (Учредители за работой) издательства Apress.

На самом деле книга — это интервью автора с 15-ю крутыми разработчиками, включая создателя Unix и даже Дональда Кнута. Вот вроде интересно, но... Есть минусы:

1. Вечная стена текста — очень сложно читать, хоть бы абзацы выделяли, где вопрос автора и ответ разработчика. А перед следующим вопросом пустую строку. Книга меж тем — толстый талмудик. С одной стороны, улучшение читабельности через пустые строки еще больше ее раздует, но зато читать приятнее будет.
2. Все разработчики — очень крутые, не спорю. Но все начинали с перфокарт :) Поэтому слушать их вроде как интересно, но... Не слишком актуально.