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 — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков.