Тестирование

В этой статье вы узнаете:

• Что такое Cypress и когда его стоит использовать

• Основы тестирования с использованием Cypress

• Расширенные команды Cypress

• Взаимодействие с элементами пользовательского интерфейса

• Лучшие практики с использованием Cypress

Введение

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

• Запустить приложение

• Подождать пока сервер запустится

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

• Проверить, что результат вашего теста корректен(изменения заголовка, части текста и т.д.)

• Повторить эти шаги ещё раз после простых изменений кода

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

Именно здесь в игру вступает Cypress. При использовании Cypress единственное, что вам нужно сделать, это:

• Написать код вашего теста(нажатие на кнопку, ввод текста в поля ввода и т.п.)

• Запустить сервер

• Запустить или перезапустить тест

Только и всего!Библиотека Cypress выполняет все тесты за вас.И самое приятное, что она не только сообщает вам все ли ваши тесты успешны или нет, но также сообщает вам, какой тест не удался.

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

Теперь, когда мы обсудили преимущества Cypress, давайте узнаем об основах этой библиотеки.

Начало

Установка и настройка Cypress

Сначала создайте отдельную папку для вашего проекта, а затем инициализируйте ее:

Наконец, чтобы установить библиотеку Cypress:

Примечание. Если вы используете дистрибутив Linux, перейдите кэтим инструкциям,прежде чем продолжить установку Cypress через NPM.

Теперь, когда Cypress установлен, попробуйте запустить его с помощью следующей команды:

Она открывает запускалку тестов(Test Runner):

А теперь давайте перейдём к написанию тестов.

Основы Cypress

Создание файла

Cypress требует, чтобы все наши тесты находились вкаталоге cypress/integration.Сначала перейдите в этот каталог:

Теперь создайте файл JavaScript с именемbasicTest.js:

Если вы не отключили сервер Cypress, ваши новые файлы появятся в Test Runner в реальном времени:

Теперь давайте напишем наш первый тест.

Простые тесты с утверждением и ожиданием значения

В вашем файле /cypress/integration/basicTest.js напишите следующий код:

• Строка 1:Функция describe сообщает Cypress название набора наших тестов.

• Строка 2: Функцияit, обозначает название теста.

• Строка 3: Создаём утверждение.Здесь мы подтверждаем, что 2 + 2 равно 4. Если тест вернётfalse, то он будет немедленно остановлен.

Чтобы запустить вашу программу, щёлкните поbasicTest.js в вашем сервере Cypress.

Результат запуска:

Отлично!Значит, наше утверждение было успешным.

Что, если мы сделаем заведомо ложное утверждение?Теперь в/cypress/integration/basicTest.js добавьте следующий код впределах функцииdescribe:

• Строка 2: Если сумма 4 и 5 равна 10, тест будет пройден. В противном случае, незамедлительно остановлен.

Снова запустите код.Результат будет:

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

Давайте больше поиграем с утверждениями.Добавьте в basicTest.jsследующий код:

• Строка 2: Если сумма 5 и 5неравна 100, то тест должен пройти.

Результат выполнения теста:

Отлично!Наш тест прошел. Функцияexpect выполняетBDD (behavior-driven) утверждения.В следующем разделе мы выполним утверждения, основанные на тестировании(test-driven assertions).

Сейчас/cypress/integration/basicTest.jsдолжен выглядеть так:

Написание утверждений основанных на тестировании(test-driven assertions) с явным использованием assert

Мы даже можем писать утверждения на основе TDD с использованиемassert.

В вашем файлеbasicTest.js напишите следующий код:

• Строка 2: Создаём объект со свойствамиnameи age.

• Строка 6: ФункцияisObjectподтверждает,что переменнаяpersonявляется объектом.Если результатtrue, то будет напечатаноvalue is object.В противном случае будет показано, что этот тест не прошел.

• Строка 10: Убеждаемся, что переменнаяnameсодержитстроковое значение.

• Строка 14: Убеждаемся, что переменнаяname неявляется целым числом.

Запустите код.Результатом будет:

Отлично!Наш код работает.В следующем разделе мы научимся работать с сайтами через Cypress.

Сейчас нашbasicTest.jsдолжен выглядеть так:

Запуск веб-сайтов

Здесь мы попробуем запуститьDemoblaze, сайт, созданный для проведения тестов.

В своей папке/cypress/integration/ создайте файл с именемbasicCommandsTest.js.В этом файле напишите следующий код:

• Строка 3: Используем методvisit, чтобы сообщить Cypress о переходе на веб-сайт Demoblaze.

Сохраните свой код и нажмите наbasicCommandsTest.js в меню Test Runner:

Результат запуска:

Отлично!Наш код работает.В следующем разделе мы более глубоко погрузимся в тестирование с помощью Cypress.

В итогеbasicCommandsTest.jsдолжен выглядеть так:

Cypress: Расширенные команды

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

Как идентифицировать элементы

Cypress используетселекторы JQueryдля идентификации компонентов на веб-странице.

Например, чтобы получить элемент myButton используя id, мы должны написать следующий код:

В качестве альтернативы, чтобы идентифицировать элемент myButton используя имя класса, могли бы использовать следующую строку:

Давайте теперь поработаем с взаимодействием с пользовательским интерфейсом нашего сайта.

Нажатие кнопки

В этом разделе мы будем использоватьстраницу The-Internetдля запуска наших тестов.На этом веб-сайте мы будем использоватьразделдобавления/удаленияэлементов.

Давайте сначала попробуем идентифицировать нашу кнопку Добавить элемент.

Используя DevTools, заметьте, что уbuttonесть свойствоonclick, имеющее значениеaddElement().

Соответствующий селектордля этой кнопки будет выглядеть так:

В папке/cypress/integration создайте файл с именемrunningClickCommand.js.В этом файле напишите следующий код:

• Строка 2: Переходим на веб-страницу.

• Строка 6: Связываем в одну цепочку получение элемента button и нажатие на эту кнопку.

Запустите код.Результат:

Отлично, наш код работает!Обратите внимание, что как только страница загрузилась, в нашем тесте автоматически происходит нажатие на кнопкуAdd Element.

Давайте теперь поработаем с вводом текста в текстовое поле.

Ввод текста

В этом разделе мы будем использоватьстраницуThe-Internets login.Нам нужен способ сначала идентифицировать элементы.

Поле username имеетid равноеusername, а полеpassword имеетid равноеpassword.Кроме того, кнопка Login имеет свойствоtype равноеsubmit.Таким образом, для определения полейusername иpassword, нам понадобитсяселектор JQuery id:

Более того, чтобы получить кнопкуbutton, нам понадобитсяселектор атрибутов, например:

В своей папке/cypress/integration создайте файл с именемrunningTypeCommand.js.В этом файле напишите следующий код:

• Строка 3: Переходим на страницу входа в систему.

• Строка 6: Переходим в полеusername и добавляем методtype вцепочку вызовов, чтобы напечатать в этом текстовом поле значениеtomsmith.

• Строка 7: Переходим в полеpassword и вводимSuperSecretPassword.

• Строка 10: Нажимаем на кнопку Отправить.

Запустите код.Результатом будет:

И мы закончили!В следующем разделе мы узнаем о работе с чекбоксами.

Переключение чекбоксов

В этом разделе мы будем использоватьраздел чекбоксов на странице The-Internet.

Давайте сначала посмотрим на DevTools:

Оба этих чекбокса имеют свойствоtypeсо значениемcheckbox.Кроме того, они также являются дочерними элементамидля элементаform сid равнымcheckboxes.В этом случае мы бы использовалиселектор JQuery родитель-потомок:

В каталоге/cypress/integration/ создайте файл с именемrunningCheckCommand.js и напишите следующий код:

• Строка 4: Находим обе группы чекбоксов, а затем используем методcheck, чтобы отметить их выбранными.

• Строка 7: Просим Cypress приостановить процесс тестирования на одну секунду.

• Строка 8: Получаем список отмеченных чекбоксов.Затем используем методuncheck, чтобы снять выбор.

Запустите код.Результат:

Отлично!Наш код работает.Давайте теперь поработаем над неявными утверждениями с помощью Cypress.

Неявные утверждения

Ранее мы выполняли утверждения для переменных и объектов.Однако в реальном мире мы хотели бы выполнять утверждения для текста, расположенного в нашем элементе HTML, или проверять, есть ли у нашего элементаul дочерние элементыli или нет.

Для выполнения таких утверждений мы будем использовать ключевое словоshould.В этом разделе мы будем делать неявные утверждения настраницедобавления элемента The-Internets Add Element

Наша кнопкаDelete имеет классadded-manually.Мы хотим выполнить следующее утверждение для этого элементаbutton:

Для этого мы должны использовать следующий синтаксис:

Альтернативно, можем выполнить такое утверждение:

Мы можем использовать эту строку кода:

Перейдите в/cypress/integration/runningClickCommand.jsи добавьте следующий код:

• Строка 1: Получаем элементы с классомadded-manually.Затем проверяем, что их количество(have.length)равно единице.

• Строка 3: Получаем кнопкуAdd Element, а затем проверяем, что текст на кнопке(have.text)действительно будетAdd Element.

Запустите код.Результат в конце теста должен быть следующим:

Отлично!Наш код работает.Теперь перейдем к изучению командыeach.

В итогеcypress/integration/runningClickCommand.js должен выглядеть так:

Команда each

Взглянитееще раз наThe-Internets Add Elements page:

Чтобы удалить все эти элементы, мы можем вручную прокликать все кнопкиDelete.Это возможно;однако рассмотрим ситуацию, когда кнопокDeleteбольше сотни.Следовательно, удаление всех их вручную займет много времени.

Вот здесь-то и появляется командаeach. Она позволяет вам перебирать серию элементов, а затем выполнять любую функцию для каждого из них.В этом случае мы хотим перебрать все наши кнопкиDelete и запустить функциюclick на всех них.

Откройте Developer Tools:

Все наши кнопкиDelete имеют свойствоclass равноеadded-manually.В этом случае мы будем использоватьселектор классови соединять его с командойeach, например:

Перейдите в/cypress/integration/runningClickCommand.jsи добавьте следующий фрагмент кода:

• Строка 2: Получаем все элементы, у которых есть класс.added-manually.Каждый элемент в серии будет представлен параметром$el.

• Строка 3: Обёртываем этот элемент, чтобы мы могли выполнять с ним команды Cypress.Здесь мы отправляем команду щёлкнуть по этим элементам.

Результат выполнения кода должен быть следующим:

Наш код работает!Поскольку наш тест был быстрым, давайте попробуем добавить на страницу больше элементов.

Найдите следующий фрагмент кода:

Измените это так:

• Строка 2: Запускаем цикл, чтобы сообщить Cypress, что нужно нажать кнопкуAdd Element 20 раз.

Запустите код еще раз.Результат должен быть таким:

Как видите, наша программа автоматически удалила все элементы на странице без каких-либо ручных усилий.Отлично!

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

В итогеcypress/integration/runningClickCommand.jsдолжен выглядеть так:

Лучшие практики

Держите тесты изолированными

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

В вашем Test Runner это будет выглядеть так:

Команда Cypress утверждает, что структура вашего проекта должна быть организована как можно лучше.Лучше всего перегруппировать ваши файлы проекта в другие папки, например:

Следовательно, это выглядело бы так:

По возможности используйте собственные команды

Взгляните на этот фрагмент кода:

Обратите внимание, что мы вынужденымногократноиспользоватькомандыgetиtype.Здесь мы можем реализоватьсобственные команды,чтобы сделать их короче.

В вашемcypress/support/commands.jsнапишите этот код:

• Строка 1: Создаём собственную команду, которая будет иметь два параметраidentifier иdata.

• Строка 2: Получаем элемент с соответствующим идентификатором, а затем вводим в него данные.

Примечание. Считается хорошей практикой записывать свои собственные команды в файл/cypress/support/commands.js.

Теперь вернитесь в свой тестовый файл и замените его вот так:

Как видите, наш код выглядит значительно короче.

Избегайте атомарных тестов

Взгляните на этот фрагмент кода:

Здесь мы повторно выполняем тесты на HTML элементе сid равнымfirst.

Cypress не одобряет такого поведения.Это неэффективно, и есть способ лучше переписать этот код, например:

Мы можем использовать методand для связывания дополнительных командshould с нашим элементом.

Не запускайте сервер в Cypress

Команда execприсутствует для запуска команд в терминале.Но запускать сервер с помощью этой команды крайне не рекомендуется.

Если вы хотите протестировать свое приложение наlocalhost, сначала запустите сервер,а затемзапустите свой тест Cypress.

Репозиторий GitHub и дополнительные ресурсы

Код GitHub

• Код этого проекта

Дальнейшее чтение

• Cypress Tutorial Videos

• End-To-End Testing With Cypressby codedamn

• Real Confidence With Cypress

• Best practices with Cypress: AssertJS Conference

Заключение

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

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

Файлы блокнотов Jupyter, в смысле количества одного из самых быстрорастущих типов файлов на Github, предоставляют простой интерфейс для итераций при решении визуальных задач, будь то анализ наборов данных или написание документов с большим объёмом кода. Однако популярность блокнотов Jupyter сопровождается проблемами: в репозитории накапливается большое количество файлов ipynb, многие из которых находятся в нерабочем состоянии. В результате другим людям трудно повторно запустить или даже понять ваши блокноты. В этом руководстве рассказывается, как для автоматизации сквозного (end-to-end) тестирования блокнотов можно воспользоваться плагином pytest nbmake.

К старту флагманского курса о Data Science области, в которой блокноты Jupyter незаменимы делимся переводом статьи из блога CI Semaphore о том, как при помощи Semaphore проверить, что ваши блокноты Jupyter находятся в рабочем состоянии и для этого больше не запускать блокноты вручную.

Предварительные требования

Это руководство предполагает владение основными навыками тестирования проектов на Python, о них рассказывается в статьеНепрерывная интеграция и развёртывание на Python с нуля. Прежде чем продолжить, пожалуйста, убедитесь, что вы знакомы с основами и на вашем компьютере установлен набор инструментов Python 3, таких как pip + virtualenv.

Демонстрационное приложение

Обычно проекты Python содержат папки с файлами блокнотов с расширением .ipynb, это может быть:

• код доказательства концепции;

• документация с примерами применения API;

• длинный научный туториал.

В этой статье мы разберём, как автоматизировать простые сквозные тесты некоторых блокнотов, содержащих упражнения на Python. Благодарим pytudes за предоставленные для нашего примера материалы; воспользуемся этим примером проекта, не стесняйтесь делать форк и клонировать его с GitHub:

Внутри репозитория вы найдёте содержащую блокноты папку, она называется ipynb. Установите зависимости из requirements.txt, а при необходимости сначала создайте виртуальную среду.

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

Локальное тестирование блокнота

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

Давайте начнём автоматизировать этот процесс в вашей среде разработки; первым шагом в автоматизации станет nbmake. Nbmake это пакет python и плагин к pytest. Он разработан автором этого руководства и используется известными научными организациями, такими как Dask, Quansight и Kitware. Вы можете установить nbmake с помощью pip:

pip install nbmake==0.5

Перед первым тестированием блокнотов давайте проверим, всё ли правильно настроено, указав pytest просто собрать (но не запускать) все тест-кейсы для блокнотов.

 pytest --collect-only --nbmake "./ipynb" ================================ test session starts =================================platform darwin -- Python 3.8.2, pytest-6.2.4, py-1.10.0, pluggy-0.13.1rootdir: /Users/a/git/alex-treebeard/semaphore-demo-python-jupyter-notebooksplugins: nbmake-0.5collected 3 items           ============================= 3 tests collected in 0.01s =============================

Мы видим, что pytest собрал несколько элементов.

Примечание: если вы получаете сообщение unrecognized arguments: --nbmake, оно означает, что плагин nbmake не установлен. Такое может произойти, если ваш CLI вызывает двоичный файл pytest за пределами текущей виртуальной среды. Проверьте, где находится ваш двоичный файл pytest, с помощью команды which pytest.

Теперь, когда мы проверили, что nbmake и pytest видят ваши блокноты и работают вместе, давайте выполним настоящие тесты:

 pytest --nbmake "./ipynb"================================ test session starts =================================platform darwin -- Python 3.8.2, pytest-6.2.4, py-1.10.0, pluggy-0.13.1rootdir: /Users/a/git/alex-treebeard/semaphore-demo-python-jupyter-notebooksplugins: nbmake-0.5collected 3 items                                                                    ipynb/Boggle.ipynb .                                                           [ 33%]ipynb/Cheryl-and-Eve.ipynb .                                                   [ 66%]ipynb/Differentiation.ipynb .                                                  [100%]================================= 3 passed in 37.65s =================================

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

Игнорирование ожидаемых ошибок в блокноте

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

К счастью, чтобы указать nbmake, что такие блокноты нужно игнорировать и продолжать работу после возникновения ошибок, в метаданные нашего блокнота мы можем поместить директивы. Возможно, вы раньше не использовали метаданные блокнота, поэтому самое время упомянуть, что, несмотря на их расширение ipynb, блокноты это просто JSON-файлы. Чтобы добиться от них нового поведения, добавьте новые поля:

• откройте файл .ipynb в простом текстовом редакторе, например Sublime;

• в метаданных блокнота найдите поле kernelspec;

• добавьте объект execution в качестве родственного элемента kernelspec.

Должно получиться что-то вроде этого:

{  "cells": [ ... ],  "metadata": {    "kernelspec": { ... },    "execution": {      "allow_errors": true,      "timeout": 300    }  }}

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

Ускорение тестов с помощью pytest-xdist

В крупных проектах может быть много блокнотов, каждый из которых требует много времени на установку пакетов, извлечение данных из сети и выполнение анализа. Если ваши тесты занимают более нескольких секунд, стоит проверить, как на время выполнения повлияет распараллеливание. Сделать это можно с помощью другого плагина pytest pytest-xdist. Сначала установите пакет xdist. Это похожий на nbmake плагин pytest, он добавит новые параметры командной строки:

pip install pytest-xdist

Запустите команду ниже с количеством рабочих процессов, равным auto:

pytest --nbmake -n=auto "./ipynb"

Запись выполненных блокнотов обратно в репозиторий

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

• отладить неработающие блокноты путём просмотра выходных данных;

• создать коммит в вашем репозитории с блокнотами в воспроизводимом состоянии;

• встроить выполненные блокноты в сайт с документацией при помощи nbsphinx или jupyter book.

Мы можем направить nbmake на сохранение выполненных блокнотов на диск с помощью флага overwrite:

pytest --nbmake --overwrite "./ipynb"

Исключение блокнотов из тестов

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

pytest --nbmake docs --overwrite --ignore=docs/landing-page.ipynb

Примечание: это не сработает, если вы выбираете все блокноты с помощью шаблона поиска, например (*ipynb), вручную переопределяющего флаги игнорирования pytest.

Автоматизация тестирования блокнотов на Semaphore CI

С помощью вышеописанных методов можно создать автоматизированный процесс тестирования с использованием непрерывной интеграции (CI) Semaphore. Ключ здесь прагматизм: нужно найти способ протестировать большую часть ваших блокнотов и проигнорировать сложные блокноты; это хороший шаг к улучшению качества.

Начните с создания содержащего ваши блокноты проекта для репозитория. Выберите Choose repository:

Затем подключите Semaphore к репозиторию с вашими блокнотами:

Пока пропустите Add People, чтобы мы могли настроить рабочий процесс с нуля (даже если вы работаете с деморепозиторием). Semaphore предоставляет некоторую начальную конфигурацию, настроим её перед запуском:

Создайте простой рабочий процесс в один блок; ниже о процессе в деталях:

1. Названием блока будет Test.

2. Названием задачи Test Notebooks.

3. В поле Commands введите команды ниже:

checkoutcache restorepip install -r requirements.txtpip install nbmake pytest-xdistcache storepytest --nbmake -n=auto ./ipynb

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

1. checkout клонирует репозиторий с GitHub;

2. cache restore загружает зависимости Python из кэша Semaphore. Это ускоряет процесс установки;

3. pip устанавливает зависимости и инструменты;

4. cache store сохраняет загруженные зависимости обратно в кэш;

5. pytest запускает тесты nbmake.

Теперь мы можем запустить рабочий процесс. Не беспокойтесь, если конвейер выйдет из строя: далее мы рассмотрим распространённые проблемы.

Конвейер должен заработать сразу же:

Устранение некоторых распространённых ошибок

Добавление отсутствующего ядра Jupyter в среду CI

Если вы используете имя ядра, отличное от имени по умолчанию python3, то при выполнении ноутбуков в свежей среде CI увидите сообщение об ошибке: Error - No such kernel: 'mycustomkernel'. Чтобы установить пользовательское ядро, воспользуйтесь командой ipykernel:

python -m ipykernel install --user --name mycustomkernel

Если в своих блокнотах вы работаете с другим языком, например С++, ваш процесс установки ядра может быть другим.

Добавление недостающих секретов в среду CI

В некоторых случаях ваш блокнот получает данные от API, требующих токена или аутентифицированного CLI. Всё, что работает в вашей среде разработки, должно работать и на Semaphore. Чтобы увидеть, как настроить секреты, сначала посмотрите этот пост. Как только вы установили секреты в Semaphore, чтобы прочитать их из переменной среды в средах CI, вам может потребоваться настроить блокнот.

Добавление недостающих зависимостей в среду CI

Стек Data Science на Python часто требует установки собственных библиотек. Если вы работаете с CONDA, вполне вероятно, что они будут присутствовать в вашем нормальном процессе установки. Если же вы используете стандартные библиотеки Python, их присутствие немного менее вероятно.

Если вы пытаетесь установить необходимые вам библиотеки, посмотрите на статью о создании образа docker в CI. С ним тестирование упрощается, и по сравнению со стандартными средами Semaphore этот подход стабильнее во времени.

Пожалуйста, помните совет о прагматизме; 90 % полезности часто можно достичь за 10 % времени. Следование совету может привести к компромиссам, таким как игнорирование блокнотов, на которых запускаются требующие GPU модели ML.

Заключение

В этом руководстве показано, как можно автоматизировать тестирование блокнотов Jupyter, чтобы поддерживать их воспроизводимость. Блокноты оказались эффективным инструментом для построения технических нарративов. Однако из-за новизны некоторые команды разработчиков программного обеспечения исключают их использование до тех пор, пока не появятся более чёткие процессы для тестирования, ревью и повторного использования их содержимого.

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

• для удаления громоздких выходных данных блокнота перед коммитом запустите pre-commit и nbstripout;

• для компиляции ваших блокнотов в красивый сайт с документацией используйте jupyter book;

• для просмотра блокнотов в пул-реквестах используйте ReviewNB.

Действительно, процессы в разработке ПО и в научных исследованих всё дальше уходят с локальных компьютеров на арендуемые мощности самого разного рода, в том числе потому, что требуют всё больших ресурсов. То же касается и растущих объёмов данных, работа с которыми преобразилась в несколько смежных, но очень разных областей; среди них центральное место занимает Data Science. Если вам интересна эта сфера, вы можете присмотреться к нашему курсу Data Science, итог которого это 16 проектов, то есть 2-3 года постоянного самостоятельного изучения науки о данных.

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

Меня зовут Владислав Романенко, я старший iOS QA Engineer в Badoo и Bumble. Несколько лет назад мы начали активнее использовать автотесты в разработке, но столкнулись с некоторыми трудностями.

Логичный вопрос: почему мы занялись автоматизацией тестирования? Ответ кроется в еженедельном выпуске новых версий наших мобильных приложений. QA-отделу приходится тестировать новые фичи, их интеграцию в сервисы и заниматься регрессионным тестированием. За неделю комплексное регрессионное тестирование нужно проводить как минимум один раз, что довольно утомительно. Автоматизация помогла нам выпускать новые версии быстрее и без потери качества. Подробнее об автоматизации мобильного тестирования в докладе моих коллег.

В разработке проблемы часто решаются с помощью паттернов обобщённых решений для часто возникающих проблем в заданном контексте. То же и с автоматизацией тестирования, есть даже хорошее wiki-описание. В этой статье мы поговорим о паттернах процессов (Process Patterns). Они помогают организовать и улучшить процесс автоматизации тестирования.

Без дальнейших предисловий перейдём к трудностям, с которыми мы боролись, и рекомендациям по их преодолению с помощью тех самых паттернов. Замечу, что это не единственные проблемы, которые у нас были и есть. Но в рамках данной статьи я решил остановиться именно на них.

Паттерн 1. Просьба о помощи (Ask for Help)

Как это часто бывает, мы все имели разный опыт, знания и навыки. На тот момент не все в команде сталкивались с автоматизацией тестирования некоторым пришлось учиться на ходу. Чтобы помочь коллегам из команды QA справиться со сложностями, мы предложили им обратиться за помощью к команде автоматизации. Идея в том, что если ты застреваешь на какой-то проблеме, то не нужно самостоятельно бороться с ней слишком долго, ведь другие уже могли столкнуться с подобным и найти решение. А чтобы автоматизаторов не завалили вопросами, мы решили формализовать этот подход. Прекрасным решением оказался паттерн ASK FOR HELP:

Просите о помощи, а не теряйте время, пытаясь всё сделать самостоятельно.

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

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

Внутрениий StackOverflow

Стоит отметить, что в нашей вики есть документация и описания решений для большинства распространённых проблем. Возможно, документировать все возможные ошибки и объяснения в вики не лучший подход, но мы считали, что сохранить их в одном месте будет полезно. Так у нас возникла идея создания локального Stack Overflow. Для этого мы воспользовались open source-решением Scoold. Оно предназначено для использования на первой линии обработки запросов и работает как обычная Stack Overflow, только для сотрудников компании. Когда у кого-нибудь возникает проблема, достаточно зайти в наш локальный Stack Overflow, чтобы найти решение или написать вопрос, на который ответит кто-то из специалистов.

Преимущества

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

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

• Стало меньше сообщений и веток в чатах, где их трудно отслеживать и искать. Мессенджеры не лучшее место для хранения документации и обращения к ней как к источнику истины. Stack Overflow гораздо удобнее.

Недостатки

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

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

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

Паттерн 2. Введение стандартов (Set Standards)

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

Для решения этой проблемы мы выбрали паттерн SET STANDARDS:

Введите и соблюдайте стандарты для артефактов автоматизации.

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

Что мы сделали

• Создали локальную вики с актуальными руководствами и документами (например, как настроить окружение, как запускать и поддерживать тесты), которая помогла сократить циклы ревизии кода. Всю документацию мы храним в Confluence, который разделили на несколько частей. Команды регулярно проверяют актуальность своей документации.

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

• Что касается самого кода тестов и ограничений на уровне кода для основных этапов и методов верификации, мы внедрили стандартные инструменты, включая RuboCop (статический анализатор и инструмент форматирования кода для Ruby), защитные проверки (Guard Cheсks) и pre-commit-хуки.

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

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

Преимущества

• На сопровождение тестов и исправление ошибок тратится меньше времени и сил. Руководство по написанию кода очень облегчает понимание того, что и как писать.

• На ревью кода уходит меньше времени. С одной стороны, код становится аккуратнее, с другой всегда есть источник истины для рецензента и рецензируемого.

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

Недостатки

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

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

Паттерн 3. Делимся информацией (Share Information)

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

Этот паттерн называется SHARE INFORMATION:

Просите и давайте информацию начальству, разработчикам и другим тестировщикам.

Для нас это способ улучшить автоматизацию тестирования за счёт более широкого набора знаний. Для реализации этого паттерна мы запустили еженедельные короткие презентации QA Lightning Talks. Любой человек может предложить тему и в течение 10-15 минут выступить с ней. Поскольку у встреч чёткий тайминг, это хорошая возможность узнать что-то новое, не потратив на это много времени. Для тех, кто не смог присутствовать, мы сохраняем видеозаписи встреч во внутренней библиотеке.

Доклады могут быть посвящены не только тестированию и его автоматизации. Например, однажды bayandin рассказывал о своём опыте поддержки проекта Homebrew. А я как-то рассказывал о том, что я диванный картограф в Humanitarian OpenStreetMap. Я создаю карты районов, которые плохо картографированы, и потом ими пользуются в работе сотрудники разных организаций вроде Красного Креста или Врачей без границ. Сокращённая версия этого доклада позднее была представлена на сессии Soapbox конференции EuroSTAR 2020.

Преимущества

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

• Общий объём знаний растёт. А согласно исследованию, обмен знаниями улучшает взаимодействие между департаментами и внутри них.

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

Недостатки

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

• Трудно удерживать интерес аудитории и увеличивать ее. Мы каждый раз меняем тему и сосредотачиваемся на актуальных проблемах. Например, один из проектов заключался в том, что мы собирали результаты всех тестовых прогонов тикета в таблицу и интегрировали её в Jira. Об этом на ближайшей встрече и рассказал один из участников команды автоматизации тестирования.

Бонус: паттерн для обучения разделение на пары (Pair Up)

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

Чтобы достичь цели, мы воспользовались паттерном PAIR UP:

Более опытный сотрудник получает себе в пару менее опытного.

Для QA-инженеров мы запустили внутреннюю программу менторства. Что это такое? QA-инженеры присоединяются к автоматизаторам на короткий промежуток времени (обычно на две недели) и работают над задачами из бэклога этой команды, а не из своего. Помогают им в этом менторы из числа старших инженеров-автоматизаторов. Цель внутреннего менторства заключается в обучении. Мы разработали такой манифест:

• Сосредоточенность на обучении, а не на строгом соблюдении сроков.

• Интерактивные обсуждения, а не работа в бункере.

• Ранняя и регулярная обратная связь, а не ретрообзор в конце менторства.

Хотя утверждения справа ценны, утверждения слева для нас ценнее.

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

Итоги

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

Какие проблемы мы смогли решить

• Нежелание обращаться за помощью к коллегам (решили с помощью паттерна Ask for help). Как отметили в своей книге A Journey through Test Automation Patterns: One teams adventures with the Test Automation Серетта Гамба и Дороти Грэхем, не бойтесь просить о помощи: большинству людей на самом деле нравится помогать.

• Высокая стоимость сопровождения кодовой базы тестирования (решили с помощью паттерна Set Standards). Если вы давно работаете над автоматизацией, то стандарты просто необходимы.

• Информационный бункер (решили с помощью паттерна Share Information). Общайтесь с другими людьми: в процессе обсуждения часто рождаются новые идеи.

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

Расскажите в комментариях, с какими сложностями при автоматизации тестирования столкнулись вы и как их решали.

В оригинальной статье на сайте Medium, хотя и написанной от лица мужского пола, можно сказать от библейского первого человека Адама, в пример топового разработчика приводится девушка, которая в 11 лет сделала свой сайт, а к 23-м годам стала миллиардером. Судя по тому, что у нас в компании девушки-разработчики большая редкость (их всего две), а мы типичная IT-компания, для адаптации к местным реалиям пришлось превратить ее в парня. Получилось почти как у Киплинга. Помните, пантера Багира в оригинальных книгах был мачо-мальчиком, а в советском мульте превратился в супердевочку с голосом актрисы Касаткиной.

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

Но реальность такова, что каждый разработчик, даже топовый, иногда ошибается, но исправляется. Разница в цене ошибки; если облажается программист, под угрозой оказываются базы данных, такие потери могут стоить компаниям миллиардов долларов. Почему мы все так боимся косяков? Они как клеймо: никто не говорит о своих ошибках, никто не хочет, чтобы его считали дураком среди гениев.

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

Тысячи URL-адресов были потеряны

Работая в крупном финансовом учреждении, я разработал систему для очистки неиспользуемых маршрутов на сетевом уровне F5. Пул маршрутов F5 мог поддерживать примерно 5000 URL-адресов. Затем он засорялся. Моя система автоматизировала процесс мониторинга трафика по этим URL-адресам, уведомляла владельцев о неиспользуемых ресурсах и в конечном итоге очищала их. Она не давала системе F5 выйти из строя и освобождала от ручной обработки операций.

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

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

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

Выяснилось, что большинство ресурсов, неактивных в течение недели, остаются такими целый месяц. Другими словами, важные приложения не бездействуют в течение недели. Так что в конечном итоге ущерб был управляемым; из 1000 удаленных URL лишь несколько команд пожаловались на проблему. Однако негативная обратная связь и стресс от проблемы сильно повлияли на меня и моих менеджеров. Особенно, когда мы только узнали о проблеме и не осознавали масштабов ущерба. В результате мы развернули военный штаб: вооруженная до зубов команда была готова в любой момент вручную воссоздать потерянные ресурсы или удаленные URL'ы.

Как это могло случиться?!

Сначала мне казалось, что в случившемся виноват только я. Масла в огонь подливало и то, что тимлиды были с этим согласны. Но, оглядываясь назад, могу сказать, что это был закономерный провал. Существующая система управления маршрутами F5 не могла удовлетворить потребности бизнеса и не имела четкой стратегии резервного копирования или отката.

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

Что я вынес из этой ситуации?

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

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

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

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

База данных и учетные записи должны быть доступны по умолчанию только для чтения, должны иметь четкие стратегии резервного копирования и восстановления. Например, на моей следующей работе разработчик случайно удалил файлы из корзины prod S3. Если бы у нас не было стратегии управления версиями S3, которую я установил всего за неделю до этого (она отключена по умолчанию, черт возьми, Amazon!), мы могли потерять ее навсегда.

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

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

Отправил письмо с кодом не сотруднику компании

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

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

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

Жена забрала меня в тот день с работы и была в отличном настроении. Она спросила, как прошел мой первый день, на что я ответил: Думаю, я нас подвел. Улыбка с ее лица исчезла. Когда я рассказал, что произошло, она абсолютно спокойно отреагировала и сказала, что хотя это действительно глупый поступок, мы справимся. Всю неделю голова была как в тумане, пока юристы из моей бывшей компании не связались со мной и не сказали, что не будут выдвигать обвинения, если я подпишу соглашение об удалении этого кода немедленно.

Как это могло случиться!?

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

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

Что я вынес из этой ситуации?

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

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

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

Потерял работу во время пандемии

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

Однако к июлю стало ясно, что нам нужно или сокращать команду, или наш корабль пойдет ко дну. В 11:30 генеральный директор лично отправил мне сообщение в Slack со зловещей просьбой позвонить ему в 12:00. В 12:15 меня уволили. Цитирую: Адам, мы вынуждены немедленно отпустить вас. Мы считаем, что вы хорошо поработали, однако из-за сложных условий мы сокращаем персонал. Я был одним из 15 человек, бесцеремонно уволенных в тот день, без предупреждения, выходного пособия, даже без пяти минут, чтобы попрощаться с командой (учетная запись Slack была отключена во время разговора).

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

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

Как это могло случиться!?

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

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

Я был новым сотрудником и мне дали вести крутые проекты с нуля. Я работал над конвейерами машинного обучения и анализировал данные в Jupyter. Однако наши основные системы были довольно посредственными приложениями Flask. Меня никто особо не подталкивал разбираться с этими системами, поэтому я и не лез. Когда в них обнаруживались баги, я их не устранял. Когда они тормозили работу, я ничего не предпринимал; меня никто не просил, и я не проявлял инициативу.

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

Что я извлек из этой ситуации?

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

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

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

Наконец последнее, чему я научился, это постоянно давать самому себе обратную связь. Как я себя чувствую? Почему я работаю над проектом X? Важен ли проект X для успеха компании? Если нет, то что важно? Не привязывайтесь сильно к своей работе. Часто мы боимся обратной связи, потому что она может задеть наше эго, но ее принятие это единственный способ движения вперед.

P.S. Позор тем компаниям, которые оставляют соискателей без обратной связи.

Основной вывод из прошлых ошибок заключается в том, что вы всегда будете сталкиваться с препятствиями и неудачами. Они не только неизбежны, но и необходимы. Редко когда неудачи являются следствием провала отдельного взятого человека. Факапы это возможность лучше понять себя и окружающих. Начальник сравнял вас с землей или вознес до небес? Семья и друзья не бросили в трудную минуту? В любом случае у вас есть отличная возможность перевести дыхание и подумать о планах.

Привет!

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

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

Меняется лишь состав спикеров и обсуждаемые вопросы. Вот они:

19:05 19:35, Контрактное тестирование Rest API

Семен Ковалев, старший специалист по тестированию, Альфа-Банк

Семен расскажет отом, что такое контрактное тестирование, иразберет простой пример контрактного теста наPostman.

19:35 20:05, Структурированный подход к организации тестов

Анна Сотниченко, специалист по тестированию, Альфа-Банк

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

20:05-20:35, Построение модели Onboarding в QA

Иван Боклач, руководитель группы тестирования,Альфа-Банк

Подключайтесь, будет интересно.

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

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

Содержание

• Что такое база данных

• Как она выглядит

• Как получить информацию из базы

• Как связать данные между собой

• Как ускорить запрос

• Преимущества базы данных

• Что знать для собеседования

• Статьи и книги по теме

• Резюме

Что такое база данных

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

Катя решила открыть свой магазинчик. Она нашла хорошую марку обуви, которую днем с огнем не сыскать в ее городе. Заказала оптовую партию и стала потихоньку распродавать через знакомых. Пришлось освободить половину шкафа под коробки, но вроде всё поместилось.

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

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

Теперь, если покупатель просит определенную пару, Катьке сложно её найти. Пока коробок было мало, она помнила наизусть, где что лежит. А теперь уже нет, да и все попытки организовать систему провалились. Места мало, да и детки любят с коробками поиграть.

Тогда Катька решила орендовать складское помещение. И вот теперь красота! Не надо теснить своих домашних, дома чисто и свободно! И на складе место есть, появилась система тут босоножки, тут сапоги...

Чем больше объемы производства, тем больше нужно места. Если в начале пути склад не нужен, всё поместится дома, то потом это будет оправданно.

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

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

Как она выглядит

Да примерно как excel-табличка! Есть колонки с заголовками, и информация внутри:

Это называется реляционная база данных набор таблиц, хранящихся в одном пространстве.

Что за пространство? Ну вот представьте, что вы храните все данные в excel. Можно запихать всю-всю-всю информацию в одну огро-о-о-о-мную таблицу, но это неудобно. Обычно табличек несколько: тут информация по клиентам, там по заказам, а тут по адресам. Эти таблицы удобно хранить в одном месте, поэтому кладем их в отдельную папочку:

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

Цель та же выделить отдельное место, чтобы у вас не была одна большая свалка:

• заходишь в папку в винде видишь файлики только из этой папки

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

Хранение данных в виде табличек это не единственно возможный вариант. Вот вам для примера запись из таблицы в системе Users. Там используется MongoDB база данных, она не реляционная. Поэтому вместо таблички словно в excel каждая запись хранится в виде объекта, вот так:

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

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

Да, базы бывают разные. Классификацию можно изучить, можно выучить. Но по факту от начинающего тестировщика обычно нужно уметь достать информацию из реляционной БД (обычно != всегда, если что).

Как получить информацию из базы

Нужно записать свой запрос в понятном для базы виде на SQL. SQL (Structured Query Language) язык общения с базой данных. В нем есть ключевые слова, которые помогут вам сделать выборку:

• select выбери мне такие-то колонки...

• from из такой-то таблицы базы...

• where такую-то информацию...

Например, я хочу получить информацию по клиенту Назина Ольга. Составляю в уме ТЗ:

Дай мне информацию по клиенту, у которого ФИО = Назина Ольга

Переделываю в SQL:

select * from clients where name = 'Назина Ольга';

В дословном переводе:

select -- выбери мне* -- все колонки (можно выбирать конкретные, а можно сразу все)from clients -- из таблицы clientswhere name = 'Назина Ольга'; -- где поле name имеет значение 'Назина Ольга'

См также:

Комментарии в Oracle/PLSQL мой перевод остается работающим запросом, потому что я убрала лишнее в комментарии

Если бы у меня была не база данных, а простые excel-файлики, то же действие было бы:

1. Открыть файл с нужными данными (clients)

2. Поставить фильтр на колонку ФИО Назина Ольга.

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

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

А в базе данных вы внутри запроса SQL указываете, какие колонки из каких таблиц вам нужны. И результат запроса их отрисовывает. Скажем, мы хотим увидеть заказ, который сделал клиент, ФИО клиента, и его номер телефона. И всё это в разных таблицах! А мы написали запрос и увидели то, что нам надо:

И пусть в таблице клиентов у нас будет 30 колонок, а в таблице заказов 50, в результате выборки мы видим ровно 4 запрошенные. Удобно, ничего лишнего!

Конечно, написать такой запрос будет немного сложнее обычного селекта. Это уже select join, почитать о нем можно тут. И я рекомендую вам его изучить, потому что он входит в базовое знание sql, которое требуется на собеседованиях.

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

Как связать данные между собой

Вот например, у нас есть интернет-магазин по доставке пиццы. Так выглядит его база данных:

• В таблице client лежат данные по клиентам: ФИО, пол, дата рождения и т.д.

• В таблице orders лежат данные по заказам. Что заказали (пиццу, суши, роллы), когда, насколько довольны доставкой?

Но как понять, где чей был заказ? Сколько раз заказывал Вася, а сколько Алина?

Тут есть несколько вариантов:

1. Запихать все данные в одну таблицу: тут и заказы, и информация по клиентам... В целом удобно, открыл табличку и сразу видишь ага, это Васин заказ, а это Машин.

Но есть минусы:

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

• Поиск будет работать медленнее. Чем меньше информации в таблице, тем быстрее поиск. Когда у нас много строк, количество колонок становится существенным.

• Много дублей один человек может сделать хоть сотню заказов. И вся информация по нему будет продублирована сто раз. Неоптимальненько!

Чтобы избежать дублей, таблицы принято разделять:

• Клиенты отдельно

• Заказы отдельно

• Новые объекты отдельно

Но надо при этом их как-то связать между собой, мы ведь всё еще хотим знать, чей конкретно был заказ. Для связи таблиц используется foreign key, внешний ключ.

Нам надо у заказа сделать отметку о клиенте. Значит, таблица orders будет ссылаться на таблицу clients. Ключ можно поставить на любую колонку таблицы. Какую бы выбрать?

Можно ссылаться на имя. А что, миленько, в таблице заказов будем сразу имя видеть! Но минуточку... А если у нас два клиента Ивана? Или три Маши? Десять Саш... Ну вы поняли =) И как тогда разобраться, где какой клиент? Не подходит!

Можно вешать foreign key на несколько колонок. Например, на фамилию + имя, или фамилию + имя + отчество. Но ведь и ФИО бывают неуникальные! Что тогда? Можно добавить в связку дату рождения. Тогда шанс ошибиться будет минимален, хотя и такие ребята существуют. И чем больше клиентов у вас будет, тем больше шанс встретить дубликат.

А можно не усложнять! Вместо того, чтобы делать внешний ключ на 10 колонок, лучше создать в таблице клиентов primary key, первичный ключ. Первичный ключ отвечает за то, чтобы каждое значение в поле было уникальным, никаких дублей. При попытке добавить в таблицу запись с неуникальным первичным ключом получаешь ошибку:

Вот на него и нужно ссылаться! Обычно таким ключом является ID, идентификатор записи. Его можно сделать автоинкрементальным это значит, что он генерируется сам по алгоритму прошлое значение + 1.

Например, у нас гостиница для котиков. Это когда хозяева едут в отпуск, а котика оставить не с кем оставляем в гостинице!

Есть таблица постояльцев:

Тут привозят еще одного Барсика. Добавляем его в таблицу:

Имя Барсик, 5 лет! (мы не указываем ID)

Система добавляет:

ID сгенерился автоматически. Последнее значение было 2, значит, новый Барсик получил номер 3. Обратите внимание Барсиков уже два, но их легко различить, ведь у них разные идентификаторы!

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

Мы видим, что в первой комнате живет котик с id = 1, а во второй с id = 2. В третьей комнате пока никто не живет. Так, благодаря связке таблиц, мы всегда можем понять, что именно за котофей там проживает.

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

И в таблице заказов! id_order пусть генерится сам и всегда будет уникален. А еще в таблицу заказов мы добавим колонку id_client и повесим на нее foreign key, ссылку на id_client в таблице клиентов.

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

И наоборот, несколько таблиц могут ссылаться на одну и ту же колонку текущей таблицы. ID клиента мы можем указывать в таблице адресов, телефонов, email адресов, документов, заказов... Ограничений на это нет.

Как ускорить запрос

Давайте представим, что у нас есть табличка excel. Если она небольшая (пара строк, пара колонок), то найти нужную ячейку не составит труда:

1. Открыли файлик открывается моментально (если нет проблем с жестким диском)

2. Нажали Ctrl + F, ввели запрос тут же нашли результат.

Но что, если у нас сотни колонок и миллионы строк в файлике? Тогда начинаются тормоза. Файл открывается долго, в поиск значение ввели и система подвисла, обрабатывая результат...

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

Что делать, чтобы запросы были быстрее? Тут есть несколько путей:

1. На этапе создания таблицы добавить индексы

2. На этапе написания запроса к большой таблице использовать хинты

3. Пересобрать статистику базы

Есть и другие, но мы остановимся на этих трех.

Индексы в таблице

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

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

Совсем другое дело, если книги отсортированы по авторам. А внутри автора по названию. Тогда найти нужную книгу будет легко!

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

Хинты

Хинт это код, вставляемый в SQL-запрос, который позволяет изменить план выполнения запроса. Выглядит это примерно так:

SELECT /*+ NO_UNNEST( @SEL$4 ) */*FROM v;

Хинт идет внутри блока /* */.

А что еще за план выполнения запроса? Смотрите, когда вы выполняете любой запрос, что делает система:

1. Строит план выполнения запроса (как ей кажется, оптимальный)

2. Выполняет его

Посмотреть план можно через ключевые слова EXPLAIN PLAN (в Oracle):

EXPLAIN PLAN FOR -- построй мне план для...SELECT last_name FROM employees; -- вот такого запроса!

А если вы работаете через sql developer (графический интерфейс для обращения к базе Oracle), то можно просто выделить запрос и нажать F10:

Что мы видим на этой картинке? Запрос говорит: достань мне всю информацию из таблицы клиентов. Так как нет никаких условий where, то мы просто проходим фулл-сканом Table Access (full) по этом таблице. План показывает стоимость (cost) этого запроса 857 ms.

А теперь изменим запрос, сделав выборку по одному конкретному человеку по колонке с индексом:

Оп, цена запроса уже 5 ms. Это, на минуточку, в 170 раз быстрее!

И это простейший запрос на тестовой базе. В реальной базе данных будет сильно больше, поэтому проход таблицы по индексированной колонке существенно сократит время выполнения запроса.

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

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

Допустим, поступает жалоба от заказчика клиент открывает карточку в вебе, а она открывается минуту. Что-то где-то тормозит! Но что и где? Начинаем разбираться. Причины бывают разные:

1. Тормозит на уровне БД тут или сам запрос долго отрабатывает, или статистику давно не пересобирали, или диски подыхают.

2. Тормозит на уровне приложения тогда надо копаться внутри кода функции открыть карточку, что она там делает, получив ответ от Базы (и снова есть вариант подыхают диски, на которых установлено ПО).

3. Тормозит на уровне сети сервер приложения и сервер БД обычно размещают на разных машинах. Значит, есть общение между ними по интернету. А интернет может тупить.

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

Собираете план, сохраняете в файлик и прикладываете в задачу в джире. Или отправляете по почте.

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

См также

17 Optimizer Hints в Oracle хинты в базе Oracle

Статистика

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

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

Найди мне всех клиентов, созданных в этом году,

У которых оператор связи в телефоне Мегафон

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

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

Так вот, в статистике по БД хранится в том числе информация о распределении данных и характеристики хранения таблиц и индексов. И когда вы запускаете запрос, база (а точнее, оптимизатор внутри нее) строит возможные планы выполнения. Для каждого плана рассчитывает примерное время выполнения, а потом выбирает лучшее.

Время же он рассчитывает, ориентируясь на статистику:

• Сколько данных находится в таблице?

• Есть ли индекс по колонке, по которой я буду искать?

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

См также:

Ручной и автоматический сбор статистики оптимизатора в базе данных Oracle

Преимущества базы данных

Почему используют базу, а не сохраняют данные в файликах? Потому что:

1. Базы поддерживают требования ACID (по крайней мере транзакционные БД)

2. Это единый синтаксис SQL, который используется повсеместно

Требования ACID

ACID это аббревиатура из требований, которые обеспечивают сохранность ваших данных:

• Atomicity Атомарность

• Consistency Согласованность

• Isolation Изолированность

• Durability Надёжность

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

См также:

Требования ACID на простом языке подробнее об этих требованиях

Единый синтаксис SQL

Я спросила знакомого разработчика:

Ну и что, что единый синтаксис? В чем его плюшка то?

Ответ прекрасен, так что делюсь с вами:

Почему в школе все преподают на русском? Почему не каждый свой язык? Одна школа один, другая другой. А ещё лучше не школа, а для каждого человека. Почему вавилонскую башню недостроили?

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

Что знать для собеседования

Для начала я хочу уточнить, что я сама тестировщик. И мои статьи в первую очередь для тестировщиков ))

Так вот, тестировщика на собеседовании не будут спрашивать про базы данных. Разработчика ещё могут спросить, а вас то зачем? Вполне достаточно понимания, что это вообще такое. И про ключи могут спросить что такое primary или foreign key, зачем они вообще нужны.

Зато тестировщика спрашивают про SQL. Вот вам обсуждение из чатика выпускников, пригодится для повторения материала:

В вакансии написано: уметь составлять простые SQL запросы. А простые это какие в народном понимании?

(inner, outer) join, select, insert, update, create, последнее время популярны индексы, group by, having, distinct.

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

Статьи и книги по теме

База данных

Википедия

Какие бывают базы данных

Базы данных. Виды и типы баз данных. Структура реляционных баз данных. Проектирование баз данных. Сетевые и иерархические базы данных.

SQL

Книги:

Изучаем SQL. Линн Бейли Обожаю эту линейку книг, серию Head First O`Reilly. И всем рекомендую)) Просто и доступно даже о сложном пишут.

Статьи:

Как изучить основы SQL за 2 дня

Полезные запросы

Тренажеры:

http://www.sql-ex.ru/ Бесплатный тренажер для практики

Ресурсы и инструменты для практики с базами данных | SQL

Задачка по SQL. Найти объединенные данные

Резюме

База данных это место для хранения данных. Они бывают самых разных видов, даже файловые! Но самые распространенные реляционные базы данных, где данные хранятся в виде таблиц.

Если посмотреть на информацию о таблице в БД, мы можем увидеть ее ключи и индексы. Что это такое:

1.PK primary key, первичный ключ. Гарантирует уникальность данных, часто используется для колонки с ID. Если ключ наложен на одну колонку каждое значение в ячейках этой колонки уникальное. Если на несколько комбинации строк по колонкам уникальны.

2.FK foreign key, внешний ключ. Нужен для связки двух таблиц в разных соотношениях (1:1, 1:N, N:N). Этот ключ указываем в "дочерней" таблице, то есть в той, которая ссылается на родительскую (в таблице с данными по лицевому счету отсылка на client_id из таблицы клиентов).

3.Индекс. Нужен для ускорения выборки из таблицы.

Транзакционные базы данных выполняют требования ACID:

• Atomicity Атомарность

• Consistency Согласованность

• Isolation Изолированность

• Durability Надежность

См также:

Что такое транзакция

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

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

См также:

Клиент-серверная архитектура в картинках

Чтобы достать данные из базы, надо написать запрос к ней на языке SQL (Structured Query Language). Разработчики пишут SQL-запросы внутри кода приложения. А тестировщики используют SQL для:

• Поиска по базе правильно ли данные сохранились? В нужные таблицы легли? Это select-запросы.

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

План-минимум для изучения: select, join, insert, update, create, delete, group by, having, distinct.

PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале

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

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

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

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

И тут нам понадобятся некоторые инструменты.

Инструменты

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

1. Сниффер для анализа трафика (у нас Charles).

2. Админка у медиатора, где можно настроить получение рекламы от конкретного партнёра на свой тестовый юнит (специальный id, используя который, паблишер запрашивает рекламу у медиатора).

3. Своя админка с фича-тогглами, где можно включить/отключить, или изменить наши эксперименты.

4. Наша дебаг-панель.

5. VPN.

6. Внешние гайдлайны.

7. Внутренняя база знаний и Confluence для её хранения.

8. Чек-листы.

9. Zephyr для хранения тест-кейсов.

Пройдёмся по каждому.

Инструмент 1. Charles. Активно используется не только тестировщиками, но и разработчиками. Практически все задачи требуют замены продакшн параметров на тестовые. Например, часто возникает необходимость добавить в конфиг эксперимент или обращаться к тестовым юнитам медиатора.

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

Инструмент 2. Тестовая админка медиатора. Медиатор это специальная платформа, которая позволяет подключать приложение сразу к нескольким рекламным сетям, а также управлять показом рекламы (например, Google AdMob, Fyber и другие). Ещё во время онбординга мы проводим обучающие курсы по рекламе, где сотрудники в тестовой админке медиатора создают свой тестовый юнит для настройки параметров рекламы под себя.

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

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

Документацию обновляем и дополняем по мере необходимости: если после обновления SDK изменилась описанная логика работы, или если вышли нормативы/регламенты, требующие внесения обязательных правок.

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

Инструмент 5. VPN. В основном используется для проверки задач, связанных с GDPR и CCPA. Для тестирования GDPR подходит VPN с возможностью получения IP европейской страны. Для тестирования CCPA необходим VPN с возможностью получения калифорнийского IP.

Инструмент 6. Внешние гайдлайны. В работе с рекламными SDK часто используем их официальную документацию, где можно получить:

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

• форматы запросов и ответов рекламной SDK, а также параметры, из описания которых понимаем, за что они отвечают, и какие возможные значения для них допустимы;

• changelog изменений рекламных SDK чтобы понять, на какие изменения при обновлении SDK нужно обратить внимание во время тестирования.

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

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

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

Инструмент 9. Тест-кейсы. Тест-кейсы неотъемлемая часть тестирования любого проекта/функциональности, в том числе рекламы. Тест-кейсы разделены по приоритетам, что позволяет использовать risk-based testing, о котором будет рассказано подробнее ниже. В тест-кейсах фигурируют такие проверки, как загрузка и показ рекламы, запросы на рекламу, работа разных механик (например: водопад, аукцион), а также запрос и отображение рекламы от партнёрских рекламных сетей. Данные проверки в полной мере позволяют убедиться, что рекламный функционал работает без сбоев/корректно.

Задачи

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

Разберём, с чем приходится сталкиваться на постоянной основе:

1. Обновление SDK.

2. Тестирование форматов.

3. Безопасность.

4. Регрессионное тестирование.

5. Смоук тестирование.

6. Другие задачи (юридические вопросы, локализации, эксперименты, аналитика, рефакторинг и так далее).

Задача 1. Обновление SDK. Можно сказать, что обновление SDK наиболее популярная задача в рамках тестирования рекламы. Из-за частого проведения тестирования обновлений SDK (а также медиатора или адаптеров) составили чек-лист проверок:

• Вёрстка. Проверяем всё: центрирование, размер, отображение на устройствах с разными разрешениями экранов.

• Пользовательские сценарии. Тап по контенту/кнопке и по privacy icon, возврат в приложение, воспроизведение и остановка видеорекламы.

• Репорт (отправка жалоб, связанных с рекламой). Пользователь может пожаловаться на рекламный контент или сообщить о технических проблемах.

• Соответствие стандартам GDPR и CCPA.

• Отправка аналитики. Внутренняя и внешняя (партнёру и медиатору).

• Технические проверки. Например, уход в фон во время загрузки рекламы.

Задача 2. Тестирование форматов. Баннерная и нативная рекламы у нас закрепились и работают стабильно, но мы пробуем интегрировать и другие виды, в частности, fullscreen-рекламу. В целом, тестирование Rewarded Video и Interstitial во многом схоже с тестированием других видов: проверяется корректная загрузка и отображение рекламы, а также отправка аналитики.

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

Отдельно нужно сказать про механику Rewarded Video после окончания просмотра рекламы (или просмотра до определённой временной метки) пользователь должен получить вознаграждение. Поэтому очень важно хорошо протестировать этот функционал.

Подробно про разные форматы мобильной рекламы мы уже писали в отдельной статье.

Задача 3. Безопасность. Чтобы следить за качеством трафика, интегрировали в iFunny внешнее антифрод-решение. В него для дополнительной проверки атрибуции показов и кликов на каждое событие генерируется новое. На стороне системы с помощью технологий машинного обучения и большого объёма накопленных данных происходит дальнейший анализ. Со своей стороны мы проверяем отправку и разметку событий для разных сетей и разных типов рекламы.

Задача 4. Регрессионное тестирование. Раз в две недели iFunny релизится на iOS и Android. Независимо от количества рекламных задач, попавших в релизную ветку, мы проводим регрессионное тестирование рекламного функционала/блока. В регрессионных паках собраны следующего рода проверки:

• Основные проверки, что реклама запрашивается и отображается на нужных экранах приложения.

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

• Работа разных механик: водопад и биддинг (что это такое, можно ознакомиться здесь).

• Проверка на соответствие юридическим нормам.

• Проверки каких-то наших внутренних разработок (например, эксперименты с дизайном).

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

Проведение полного ручного прогона регресса занимает порядка 2-3 дней. Поэтому, чтобы сократить время прохождения регресса, используется практика проведения Risk-based testing (вид тестирования, основанный на вероятности риска). Суть такого тестирования исключить некоторое количество тест-кейсов из прогона, проведение которых не может выявить потенциальных ошибок на текущем релизном билде. Иными словами, кейс не имеет смысла включать в регрессионное тестирование, если при разработке не был затронут функционал, проверяющийся в кейсе.

Задача 5. Смоук тестирование. Перед тем, как выкладывать сборку в сторы, а также при тестировании хотфиксов, мы прогоняем смоук тесты. В рамках смоук тестирования реклама проверяется, но не так детально, как при регрессе. Мы тестируем основные моменты, связанные с рекламой, а именно её загрузку и отображение.

Задача 6. Другое. К тестированию других задач можно отнести:

• юридические задачи, например, связанные с GDPR и CCPA;

• задачи локализации (для пользователей iFunny из Бразилии);

• эксперименты, связанные с дизайном рекламы;

• задачи аналитики;

• рефакторинг, оптимизации. Например, оцениваем доступный нам для анализа контент на предмет валидности.

Бонус. Онбординг новых сотрудников

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

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

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

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

Вместо заключения

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

App Store самая строгая площадка для размещения приложений. Ревью проходит дольше и строже, чем у Google Play и Huawei App Gallery. В 2020 году AppStore отклонил миллион приложений, которые публиковались впервые, и миллион апдейтов.

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

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

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

Нарушения политики конфиденциальности и пользовательских данных

Нет ссылки на пользовательское соглашение. Ссылка должна быть и внутри приложения, и на странице в магазине. Если ссылка ведёт на сайт компании, соглашение должно быть размещено там и ссылка должна работать.

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

Нарушение функциональных требований

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

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

У нас в Surf, например, однажды отклонили приложение, потому что в нём была подключена библиотека для Apple Pay, но она нигде не использовалась.

UI, не соответствующий Human Interface Guideline. Сложное для использования приложение, имеющее нелогичное поведение и расположение элементов, отклонят.

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

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

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

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

Для распознавания по FaceID используются сторонние технологии. Идентификация пользователя по FaceID должна происходить только с помощью библиотеки LocalAuthentication.

Нет входа по AppleID, если есть возможность входа через соцсети. Это обязательно для iOS 13 и новее.

Нарушения в оформлении приложения

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

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

Есть слова Beta, Demo или Debug в названии приложения. Такие приложения запрещены к публикации в магазине App Store. Для бета-версий есть Test Flight.

Нет описания новой функциональности у обновлённого приложения. Если в приложении появилась новая функциональность, необходимо описать её в поле в App Store Connect. Без чёткого описания приложение ревью не пройдёт.

Скриншоты приложения, иконка и другой контент на странице магазина не подходят для аудитории 4+. И не важно, что приложение может быть не предназначено для такого возраста: аудитория App Store дети от четырёх лет.

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

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

Файл с расширением .ipa превышает размер 50 мб в момент публикации.

Нет демо-пользователя для ревью, если приложение требует обязательной авторизации.

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

Реклама не соответствует возрастному рейтингу приложения. Также важно убедиться, что она не сбивает пользователя с толку и не мешает ему.

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

В период пандемии этот пункт стал особенно важен: Apple строго следит за распространением информации, связанной с COVID-19.

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

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

Приложение поощряет незаконное использование оружия или позволяет его купить.

Есть откровенно сексуальный или порнографический контент.

Приложение разрешает анонимную отправку смс/ммс, анонимные звонки, розыгрыши.

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

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

Покупки в приложении

Цифровой контент продаётся не через in-app purchase.К цифровому контенту относятся подписки, музыка в приложении, видео, расширенный доступ к функциям.

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

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

Приложение не предоставляет пользователю всю необходимую информацию о покупке до момента продажи. Это важно, если приложение использует Apple Pay. Также недопустима кастомизация окна оплаты.

Категория Kids

Kids в App Store отдельный вид приложений. К ним Apple относится максимально строго. Категория Kids делится на три подкатегории: до 5 лет, 68 лет, 911 лет.

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

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

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

Составили гугл-док с чек-листом требований для ревью App Store.

А по каким причинам App Store отклонял ваши приложения? Расскажите в комментариях.

Как ни странно, мало кто знает о том, что у Huawei есть ферма устройств в облаке, которую можно использовать для отладки и тестирования. И речь идет не об отладке через веб-интерфейс, что является более-менее известной фичёй консоли разработчика Huawei. Мы поговорим об отладке непосредственно из студии, с возможностью пользоваться ADB.

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

Следующим шагом открываем студию и устанавливаем плагин HMS Toolkit из магазин плагинов в самой студии (File -> Settings -> Plugins).

В верхнем меню появится пункт HMS, в котором будет всё, относящееся к Huawei Mobile Services, но нас сейчас интересует именно Cloud Debugging.

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

Лично я предпочитаю логиниться по QR-коду, но опять же, сейчас это неважно. После успешного логина нам надо будет подтвердить, что мы выполняем логин для HMS Toolkit.

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

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

Можно выполнять все команды ADB, получать с устройства скриншоты и так далее.

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

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

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

Я недавно латала дыры в понимании разницы между Quality Assuarance и Quality Control. Статей на эту тему много, я накидала свой вариант, хотелось по существу. Делюсь с вами. Enjoy, если актуально!

Кто такой QС Engineer

Контроль качества (QC) - часть международного стандарта управления качеством ISO 9000. Суть контроля качества сводится к поиску дефектов и ошибок после создания продукта.

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

Должностные обязанности QC Engineer

Примерный обобщенный список:

• Оценка и внедрение программного обеспечения для тестирования.

• Проверка продукта на соответствие установленным требованиям и ожиданиям.

• Настройка автоматического тестирования.

• Поиск дефектов или ошибок, которые могут подорвать доверие покупателей к вашим продуктам.

• Проверка, что конечный продукт соответствует стандартам компании, стандартам отрасли, законам.

• Составление отчетов об испытаниях и проверках.

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

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

• Тестирование инструкций, гайдов, документации.

• Работа со специалистами по обеспечению качества.

• Оценка отзывов и жалоб клиентов -- поиск и рекомендации решений, которые сделают их счастливыми.

• Мониторинг поступления на рынок только высококачественной продукции.

Кто такой QA Engineer

Обеспечение качества (QA) - часть международного стандарта управления качеством ISO 9000, которая помогает компаниям соответствовать требованиям, удовлетворять потребностям клиентов и постоянно улучшать свои процессы и процедуры.

Должностные обязанности QA Engineer

Примерный обобщенный список:

• Планирование, разработка и внедрение политики, процессов и процедуры обеспечения качества.

• Документирование и обновление типовых инструкций и лучших решений (best practices).

• Проверка процессов, процедур и документации на соответствие правилам и стандартам.

• Мониторинг текущих процессами с целью их улучшения.

• Обучение производственных и инженерных групп соблюдению установленных процессов и процедур.

• Анализ первопричин и внедрение решений, направленных на устранение проблем, обнаруженных в текущих процессах и процедурах.

• Сбор и оценка отзывы клиентов.

ВАЖНО. Даже если в компании есть четко определенная позиция QA Engineer, обеспечивать качественный процесс, создавать качественный продукт остается обязанностью каждого участника команды.

В общем, QA Engineer, если такой есть на проекте, человек, который прицельно отследит и поможет подтянуть проседающий процесс разработки: направит, надоумит, отправит учиться или подкинет инструментов и идей.

Разница между QA и QC

Кто такой Software Engineer in Test

На моей текущей работе недавно сменился босс и он регламентировал, что QA - полностью обязанность каждого сотрудника, а я для них Software Engineer in Test.

При ближайшем рассмотрении Software Engineer in Test у меня получилось, что это тоже QC Engineer с одной лишь разницей, что фокус его обязанностей в автоматизации тестирования и включает и разработку собственного фреймворка/инструмента, и написание автотестов:

• Создание/расширение фреймворка для тестирования.

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

• Настройка и поддержка тестового окружения.

• Настройка автоматизированных тестов для надежного и эффективного выполнения в средах CI / CD.

• Обеспечение оптимального покрытия автотестами на всех уровнях.

• Автоматизация отчетности.

• и т.п.

Обязанности второго плана по сути копируют список QC Engineer.

Заключение

Итак, в любой компании есть Quality assuarance - это обязанность каждого сотрудника работать на высокое качество, но может присутствовать QA Engineer, который держит улучшение процесса разработки в постоянном фокусе.

И есть Quality Control. В центре QC - различные виды тестирования и все, что с этим связано, поэтому это зона ответственности Тестировщика, QC Engineer и Software Engineer in Test.

Полезно выяснить какой же у вас все-таки список должностных обязанностей и кого в вас видит руководство. Распространено, что руководство не различает некоторые понятия, и чаще всего ожидается, что вы два в одном QA + QC Engineer, либо в вас видят только QC Engineer.

Но кем бы вы ни были совместным итогом поступательных шагов в QA и QC всегда будут:

• высококачественный продукт на выходе

• приятный процесс работы и профессионализм

• доверие и приверженность клиентов

• отсутствие серьезных дефектов в продукте

• оптимизация ресурсов и снижение затрат

Удачи!

Если вы тестируете API, то должны знать про два основных формата передачи данных:

• XML используется в SOAP(всегда)и REST-запросах(реже);

• JSON используется в REST-запросах.

Сегодня я расскажу вам про JSON.

JSON (англ. JavaScript Object Notation) текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования.

JSON используется в REST API. По крайней мере, тестировщик скорее всего столкнется с ним именно там.

См также:

Что такое API общее знакомство с API

Что такое XML второй популярный формат

Введение в SOAP и REST: что это и с чем едят видео про разницу между SOAP и REST

В SOAP API возможен только формат XML, а вот REST API поддерживает как XML, так и JSON. Разработчики предпочитают JSON он легче читается человеком и меньше весит. Так что давайте разберемся, как он выглядит, как его читать, и как ломать!

Содержание

• Как устроен JSON

  • JSON-объект

    • Как устроен

    • Ключ или свойство?

    • Итого

  • JSON-массив

    • Как устроен

    • Значения внутри

    • Итого

• JSON vs XML

• Well Formed JSON

  1. Данные написаны в виде пар ключ:значение

  2. Данные разделены запятыми

  3. Объект находится внутри фигурных скобок {}

  4. Массив внутри квадратных []

• Итого

Как устроен JSON

В качестве значений в JSON могут быть использованы:

• JSON-объект

• Массив

• Число (целое или вещественное)

• Литералы true (логическое значение истина), false (логическое значение ложь) и null

• Строка

Я думаю, с простыми значениями вопросов не возникнет, поэтому разберем массивы и объекты. Ведь если говорить про REST API, то обычно вы будете отправлять / получать именно json-объекты.

JSON-объект

Как устроен

Возьмем пример из документации подсказок Дадаты по ФИО:

{  "query": "Виктор Иван",  "count": 7}

И разберемся, что означает эта запись.

Объект заключен в фигурные скобки {}

JSON-объект это неупорядоченное множество пар ключ:значение.

Ключ это название параметра, который мы передаем серверу. Он служит маркером для принимающей запрос системы: смотри, здесь у меня значение такого-то параметра!. А иначе как система поймет, где что? Ей нужна подсказка!

Вот, например, Виктор Иван это что? Ищем описание параметра query в документации ага, да это же запрос для подсказок!

Это как если бы мы вбили строку Виктор Иван в GUI (графическом интерфейсе пользователя):

Когда пользователь начинает вводить данные в формочку, то сразу видит результат появляется список подсказок. Это значит, что разработчик прописал в коде условие делать некое действие на каждый ввод символа в это поле. Какое действие? Можно увидеть через f12.

Открываем вкладку Network, вбиваем Виктор Иван и находим запрос, который при этом уходит на сервер. Ого, да это тот самый пример, что мы разбираем!

Клиент передает серверу запрос в JSON-формате. Внутри два параметра, две пары ключ-значение:

• query строка, по которой ищем (то, что пользователь вбил в GUI);

• count количество подсказок в ответе (в Дадате этот параметр зашит в форму, всегда возвращается 7 подсказок. Но если дергать подсказки напрямую, значение можно менять!)

Пары ключ-значение разделены запятыми:

Строки берем в кавычки, числа нет:

Конечно, внутри может быть не только строка или число. Это может быть и другой объект! Или массив... Или объект в массиве, массив в объекте... Любое количество уровней вложенности =))

Объект, массив, число, булево значение (true / false) если у нас НЕ строка, кавычки не нужны. Но в любом случае это будет значение какого-то ключа:

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

Ключ ВСЕГДА строка, поэтому можно не брать его в кавычки.

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

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

См также:

CamelCase, snake_case и другие регистры подробнее о разных регистрах

Писать ключи можно в любом порядке. Ведь JSON-объект это неупорядоченное множество пар ключ:значение.

Очень важно это понимать, и тестировать! Принимающая запрос система должна ориентировать на название ключей в запросе, а не на порядок их следования. Ключевое слово должна )) Хотя знаю примеры, когда от перестановки ключей местами всё ломалось, ведь первым должен идти запрос, а не count!.

Ключ или свойство?

Вот у нас есть JSON-объект:

{  "query": "Виктор Иван",  "count": 7}

Что такое query? Если я хочу к нему обратиться, как мне это сказать? Есть 2 варианта, и оба правильные:

Обратиться к свойству объекта;

Получить значение по ключу.

То есть query можно назвать как ключом, так и свойством. А как правильно то?

Правильно и так, и так! Просто есть разные определения объекта:

Объект

В JS объект это именно объект. У которого есть набор свойств и методов:

• Свойства описывают, ЧТО мы создаем.

• Методы что объект умеет ДЕЛАТЬ.

То есть если мы хотим создать машину, есть два пути:

1. Перечислить 10 разных переменных модель, номер, цвет, пробег...

2. Создать один объект, где будут все эти свойства.

Аналогично с кошечкой, собачкой, другом из записной книжки...

Объектно-ориентированное программирование (ООП) предлагает мыслить не набором переменных, а объектом. Хотя бы потому, что это логичнее. Переменных в коде будет много, как понять, какие из них взаимосвязаны?

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

Например, создадим кошечку:

var cat = {name: Pussy,year: 1,sleep: function() {// sleeping code}}

В объекте cat есть:

• Свойства name, year (что это за кошечка)

• Функции sleep (что она умеет делать, описание поведения)

По коду сразу видно, что у кошечки есть имя и возраст, она умеет спать. Если разработчик решит добавить новые свойства или методы, он дополнит этот объект, и снова всё в одном месте.

Если потом нужно будет получить информацию по кошечке, разработчик сделает REST-метод getByID, searchKitty, или какой-то другой. А в нем будет возвращать свойства объекта.

То есть метод вернет

{name: Pussy,year: 1,}

И при использовании имени вполне уместно говорить обратиться к свойству объекта. Это ведь объект (кошечка), и его свойства!

Набор пар ключ:значение

Второе определение объекта неупорядоченное множество пар ключ:значение, заключенное в фигурные скобки {}.

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

• client_fio (в коде это свойство fio объекта client)

• kitty_name (в коде это свойство name объекта cat)

• car_model (в коде это свойство model объекта car)

В таком случае логично называть эти параметры именно ключами мы хотим получить значение по ключу.

Но в любом случае, и ключ, и свойство будет правильно. Не пугайтесь, если в одной книге / статье / видео увидели одно, в другой другое... Это просто разные трактовки \_()_/

Итого

Json-объект это неупорядоченное множество пар ключ:значение, заключённое в фигурные скобки { }. Ключ описывается строкой, между ним и значением стоит символ :. Пары ключ-значение отделяются друг от друга запятыми.

Значения ключа могут быть любыми:

• число

• строка

• массив

• другой объект

• ...

И только строку мы берем в кавычки!

JSON-массив

Как устроен

Давайте снова начнем с примера. Это массив:

["MALE","FEMALE"]

Массив заключен в квадратные скобки []

Внутри квадратных скобок идет набор значений. Тут нет ключей, как в объекте, поэтому обращаться к массиву можно только по номеру элемента. И поэтому в случае массива менять местами данные внутри нельзя. Это упорядоченное множество значений.

Значения разделены запятыми:

Значения внутри

Внутри массива может быть все, что угодно:

Цифры

[1, 5, 10, 33]

Строки

["MALE","FEMALE"]

Смесь

[1, "Андрюшка", 10, 33]

Объекты

Да, а почему бы и нет:

[1, {a:1, b:2}, "такой вот массивчик"]

Или даже что-то более сложное. Вот пример ответа подсказок из Дадаты:

[        {            "value": "Иванов Виктор",            "unrestricted_value": "Иванов Виктор",            "data": {                "surname": "Иванов",                "name": "Виктор",                "patronymic": null,                "gender": "MALE"            }        },        {            "value": "Иванченко Виктор",            "unrestricted_value": "Иванченко Виктор",            "data": {                "surname": "Иванченко",                "name": "Виктор",                "patronymic": null,                "gender": "MALE"            }        },        {            "value": "Виктор Иванович",            "unrestricted_value": "Виктор Иванович",            "data": {                "surname": null,                "name": "Виктор",                "patronymic": "Иванович",                "gender": "MALE"            }        }]

Система возвращает массив подсказок. Сколько запросили в параметре count, столько и получили. Каждая подсказка объект, внутри которого еще один объект. И это далеко не сама сложная структура! Уровней вложенности может быть сколько угодно массив в массиве, который внутри объекта, который внутри массива, который внутри объекта...

Ну и, конечно, можно и наоборот, передать массив в объекте. Вот пример запроса в подсказки:

{"query": "Виктор Иван","count": 7,"parts": ["NAME", "SURNAME"]}

Это объект (так как в фигурных скобках и внутри набор пар ключ:значение). А значение ключа "parts" это массив элементов!

Итого

Массив это просто набор значений, разделенных запятыми. Находится внутри квадратных скобок [].

А вот внутри него может быть все, что угодно:

• числа

• строки

• другие массивы

• объекты

• смесь из всего вышеназванного

JSON vs XML

В SOAP можно применять только XML, там без вариантов.

В REST можно применять как XML, так и JSON. Разработчики отдают предпочтение json-формату, потому что он проще воспринимается и меньше весит. В XML есть лишняя обвязка, название полей повторяется дважды (открывающий и закрывающий тег).

Сравните один и тот же запрос на обновление данных в карточке пользователя:

XML

<req><surname>Иванов</surname><name>Иван</name><patronymic>Иванович</patronymic><birthdate>01.01.1990</birthdate><birthplace>Москва</birthplace><phone>8 926 766 48 48</phone></req>

JSON

{"surname": "Иванов","name": "Иван","patronymic": "Иванович","birthdate": "01.01.1990","birthplace": "Москва","phone": "8 926 766 48 48"}

За счет того, что мы не дублируем название поля каждый раз surname surname, читать JSON проще. И за счет этого же запрос меньше весит, что при плохом интернете бывает важно. Или при большой нагрузке.

См также:

Инфографика REST vs SOAP

Well Formed JSON

Разработчик сам решает, какой JSON будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. Наш JSON должен быть well formed, то есть синтаксически корректный.

Чтобы проверить JSON на синтаксис, можно использовать любой JSON Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

Но учтите, что парсеры внутри кода работают не по википедии или w3schools, а по RFC, стандарту. Так что если хотите изучить каким должен быть JSON, то правильнее открывать RFC и искать там JSON Grammar. Однако простому тестировщику хватит набора типовых правил с w3schools, их и разберем.

Правила well formed JSON:

1. Данные написаны в виде пар ключ:значение

2. Данные разделены запятыми

3. Объект находится внутри фигурных скобок {}

4. Массив внутри квадратных []

1. Данные написаны в виде пар ключ:значение

Например, так:

"name":"Ольга"

В JSON название ключа нужно брать в кавычки, в JavaScript не обязательно он и так знает, что это строка. Если мы тестируем API, то там будет именно JSON, так что кавычки обычно нужны.

Но учтите, что это правило касается JSON-объекта. Потому что json может быть и числом, и строкой. То есть:

123

Или

"Ольга"

Это тоже корректный json, хоть и не в виде пар ключ:значение.

И вот если у вас по ТЗ именно json-объект на входе, попробуйте его сломать, не передав ключ. Ещё можно не передать значение, но это не совсем негативный тест система может воспринимать это нормально, как пустой ввод.

2. Данные разделены запятыми

Пары ключ:значение в объекте разделяются запятыми. После последней пары запятая не нужна!

Типичная ошибка: поставили запятую в конце объекта:

{  "query": "Виктор Иван",  "count": 7,}

Это последствия копипасты. Взяли пример из документации, подставили в постман (ну или разработчик API подставил в код, который будет вызывать систему), а потом решили поменять поля местами.

В итоге было так:

{  "count": 7,  "query": "Виктор Иван"}

Смотрим на запрос ну, query то важнее чем count, надо поменять их местами! Копипастим всю строку "count": 7,, вставляем ниже. Перед ней запятую добавляем, а лишнюю убрать забываем. По крайней мере у меня это частая ошибка, когда я кручу-верчу, местами поменять хочу.

Другой пример когда мы добавляем в запрос новое поле. Примерный сценарий:

1. У меня уже есть работающий запрос в Postman-е. Но в нем минимум полей.

2. Я его клонирую

3. Копирую из документации нужное мне поле. Оно в примере не последнее, так что идёт с запятой на конце.

4. Вставляю себе в конце запроса в текущий конец добавляю запятую, потом вставляю новую строку.

5. Отправляю запрос ой, ошибка! Из копипасты то запятую не убрала!

Я на этот сценарий постоянно напарываюсь при тестировании перестановки полей. А ведь это нужно проверять! Хороший запрос должен быть как в математической присказке: от перемены мест слагаемых сумма не меняется.

Не зря же определение json-объекта гласит, что это неупорядоченное множество пар ключ:значение. Раз неупорядоченное я могу передавать ключи в любом порядке. И сервер должен искать по запросу название ключа, а не обращаться к индексу элемента.

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

Чтобы протестировать, как система обрабатывает плохой json, замените запятую на точку с запятой:

{  "count": 7;  "query": "Виктор Иван"}

Или добавьте лишнюю запятую в конце запроса эта ошибка будет встречаться чаще!

{  "count": 7,  "query": "Виктор Иван",}

Или пропустите запятую там, где она нужна:

{"count": 7"query": "Виктор Иван"}

Аналогично с массивом. Данные внутри разделяются через запятую. Хотите попробовать сломать? Замените запятую на точку с запятой! Тогда система будет считать, что у вас не 5 значений, а 1 большое:

[1, 2, 3, 4, 5] <!-- корректный массив на 5 элементов -->[1; 2; 3; 4; 5] <!-- некорректный массив, так как такого разделителя быть не должно. Это может быть простой строкой, но тогда нужны кавычки -->!

3. Объект находится внутри фигурных скобок {}

Это объект:

{a: 1, b: 2}

Чтобы сломать это условие, уберите одну фигурную скобку:

{a: 1, b: 2

a: 1, b: 2}

Или попробуйте передать объект как массив:

[ a: 1, b: 2 ]

Ведь если система ждет от вас в запросе объект, то она будет искать фигурные скобки.

4. Массив внутри квадратных []

Это массив:

[1, 2]

Чтобы сломать это условие, уберите одну квадратную скобку:

[1, 2

1, 2]

Или попробуйте передать массив как объект, в фигурных скобках:

{ 1, 2 }

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

Итого

JSON (JavaScript Object Notation) текстовый формат обмена данными, основанный на JavaScript. Легко читается человеком и машиной. Часто используется в REST API (чаще, чем XML).

• JSON-объект неупорядоченное множество пар ключ:значение, заключённое в фигурные скобки { }.

• Массив упорядоченный набор значений, разделенных запятыми. Находится внутри квадратных скобок [].

• Число (целое или вещественное).

• Литералы true (логическое значение истина), false (логическое значение ложь) и null.

• Строка

При тестировании REST API чаще всего мы будем работать именно с объектами, что в запросе, что в ответе. Массивы тоже будут, но обычно внутри объектов.

Правила well formed JSON:

1. Данные в объекте написаны в виде пар ключ:значение

2. Данные в объекте или массиве разделены запятыми

3. Объект находится внутри фигурных скобок {}

4. Массив внутри квадратных []

См также:

Introducing JSON

RFC (стандарт)

Что такое XML

PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале

Это продолжение серии статей о нестабильных тестах.

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

В этой статье дадим советы как избежать нестабильных тестов в каждом из 4 компонентов.

Компоненты

Итак 4 компонента в которых могут возникать нестабильные тесты:

• Сами тесты;

• Фреймворк для запуска тестов;

• Сервисы и библиотеки, от которых зависит тестируемая система и тестовый фреймворк;

• Операционная система и устройство с которым взаимодействует фреймворк автотестирования.

Это отображено на рисунке 1.

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

Сами тесты

Сами тесты могут быть нестабильными.

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

Таблица 1 Причины, варианты локализации проблемы и варианты решения нестабильности в самих тестах.

Фреймворк для запуска тестов

Ненадежный фреймворк для запуска тестов может привести к нестабильности

Таблица 2 Причины, варианта локализации проблемы, и варианты решения нестабильности в фреймворке для запуска тестов

Сервисы и библиотеки, от которых зависит тестируемая система и тестовый фреймворк

Приложение (или тестируемая система) может быть источником нестабильности.

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

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

Таблица 3 Причины, варианта локализации проблемы, и варианты решения нестабильности в приложении или тестируемой системе

Операционная система и устройство с которым взаимодействует фреймворк автотестирования

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

Таблица 4 Причины, варианта локализации проблемы, и варианты решения нестабильности в ОС и устройстве с которым взаимодействует фреймворк автотестирования

Заключение

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

Ссылки на источники

• Откуда берутся нестабильные тесты? (оригинал/ перевод статьи на хабре)

• Нестабильные тесты в Google и как мы их исправляем (оригинал)

• Мои тесты на Selenium не стабильны! (оригинал)

• Избегайте нестабильных тестов (оригинал)

• Нестабильные тесты одна из основных проблем автоматизированного тестирования(оригинал/ перевод статьи на хабре)

... ну вот опять, снова вернулась ко мне задача из тестирования, сколько можно уже? Вася зло прокомментировал появившееся уведомление о новом письме.

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

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

Кому будет интересна статья:

• Руководителям команд/направлений, ищущим способы ускорить/удешевить разработку;

• Ручным тестировщикам, желающим начать заниматься Quality Assurance;

• QA, как ещё один успешный кейс улучшения процессов в команде;

• Разработчикам, неравнодушным к процессам в команде.

Пролог. История кнопки всевластия Reopen

В давние незапамятные времена, земли одной компании были поделены между Гильдиями, назовем их кратко, по виду боевых искусств, которыми они владели их участники C#, Python, JS.

За всеми Гильдиями присматривала каста предприимчивых управленцев, пользующаяся их услугами и продававшая результаты работы во Внешний Мир. Наместником их был СТО (Самый Трудолюбивый Организатор). Задачей СТО было повысить эффективность Гильдий.

Для помощи Гильдиям, СТО создал ещё несколько гильдий, более малых, использовав незанятые просторы компании. Состав пополнился:

• Гильдией Администрирования (SRE);

• Гильдией Обеспечения Качества (QA);

• Гильдией Сопровождения Разработки (DevOps).

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

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

С помощью руководителя Сопровождения Разработки были выкованы золотые кнопки Reopen, по одной для каждого инженера Обеспечения Качества их способности позволяли контролировать выполнение задачи на всех этапах разработки, что давало неописуемую власть над проектами. По договоренности с гильдиями SRE и DevOps, инженеры QA не могли вмешиваться в их дела кнопки были бессильны на их землях. Но одна кнопка, выкованная втайне от всех, всё же имела власть на всех землях Компании, и конечно же, она досталась...

Часть I. Тесты сгущаются

<52 часа до релиза>

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

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

<50 часов до релиза>

С найденным чеклистом, ребята поспешили к руководителю QA отдела.
Паш, привет, ты наверное слышал уже, что Катя заболела? У нас релиз фичи новой послезавтра, можешь кого-то из ребят найти, кто свободный, чтобы нам Катю заменить? ворвался Вася в кабинет к Паше.
Простите, ребята, сразу так никого не подскажу все у нас заняты. Может быть Артем может с чем-то помочь, но только чуть-чуть, потому что у него тоже завал развел руками Паша.

После недолгих поисков Артема в офисе и последующей беседы с ним, был сформирован план действий:

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

• Артем помогает придумать сценарии для проверки задач, насколько позволяет его знание продукта (Артем работает в другой команде, поэтому не знает всех тонкостей нашей фичи);

• интеграционное тестирование распределяется на всех участников команды одинаковыми частями (спасибо заранее готовому чеклисту от Кати).

Часть II. Возвращение QAроля

<72 часа после релиза>

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

Катя же, обсудив с Артемом её отсутствие в предыдущие дни, заручилась поддержкой Паши и приготовилась выполнять зловещий план, состоящий из следующих пунктов:

1. Провести интервью с каждым разработчиком о том, как он тестировал свои собственные задачи общие впечатления от процесса, ощущения от работы с Артемом в формате придумывания сценариев тестирования;

2. Собрать метрики по задачам, протестированным разработчиками самостоятельно как быстро такие задачи проходят тестирование, как много багов связанных с этими задачами.

Отрывок из интервью с Васей:

Мне понравилось в таком формате с Артемом работать, он мне подсказывал некоторые штуки, о которых я забывал пользователи с разными ролями, объекты разных типов. С легаси когда работаешь, бывает нет тестов на этот компонент, поэтому облажаться там можно легко. А Артем он умный, много знает про продукт очень удобно с ним генерировать идеи для тестов.
Максимум один раз задачу переоткрывали, я сразу всё фиксил и необходимые тесты дописывал. Времени конечно же больше тратится на такую работу, потому что сначала многое упускал и мы придумывали сценарии вдвоем отличается от того, что "кинул задачу в тестирование и ушел заниматься другой задачей".

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

Часть III. Подсчет эффективности

Результатами нашей истории стало:

• Небольшое увеличение ТТМ в начале самотестирования разработчиками, вызванное необходимостью обсуждений тестовых сценариев;

• Разработчики команды увеличили свои знания о продукте и теперь способны тестировать задачи, не привлекая QA для помощи в составлении сценариев;

• Незначительное снижение TTM для задач и проектов/фичей в целом после переходной стадии с обсуждением тестовых сценариев, избавление от пинг-понга задачами пошло на пользу;

• Увеличен bus-factor для тестирования, более нет потребности в ручном тестировании до стадии интеграционного тестирования (интеграционное тестирование на QA остается, как необходимость просмотра "чистым взглядом" проекта при желании можно и его размазать на команду разработки);

• И далеко не последнее по значимости отсутствие роста багов по задачам с самотестированием. Количество их и не уменьшилось, и не увеличилось, но это и не было целью данного исследования.

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

Автоматизация тестирования обычно вводится в проект для решения таких проблем, как повторяющаяся ручная работа, работа с большими наборами данных или получение более быстрой обратной связи в пайплайне CI / CD. Из-за этого шума вокруг автоматизации тестирования вы можете подумать о том, чтобы автоматизировать все. Возможно, вы уже выбрали фреймворк тестирования и команду, которая будет выполнять автоматизацию тестирования. Но серьезно ли вы задумывались о том, что вам следует автоматизировать или насколько это выполнимо для вас?

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

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

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

Автоматизируйте ваши смоук тесты

Смоук тесты очень важно выполнять для получение уверенности, что ваше приложение функционирует на базовом уровне, после каждого измененияили при создании нового билда. Смоук тесты могут быть интегрированы в пайплайн CI / CD, чтобы убедиться, что блокирующие ошибки обнаруживаются на ранней стадии. Смоук тесты гарантируют, что наиболее важные аспекты и основные компоненты приложения работают правильно. Они тестируют области, которые всегда должны работать, и могут помочь вам понять, достаточно ли стабильна сборка или приложение для продолжения дальнейшего тестирования. Автоматизация смоук тестов может:

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

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

3. Приводит к меньшему количеству ручного труда и экономит время. Путем интеграции ваших автотестов в пайплайн CI/CD ваши смоук тесты сворершают проверку до завершения сборки. Это означает, что сборка не передается QA, если автотесты не пройдут смоук.

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

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

1. Запускать тесты, которые быстро выявляют любые ошибки, возникающие в результате изменений в программном обеспечении. Эти изменения могут быть новыми функциями или исправлениями багов.

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

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

Автоматизируйте обширные тесты

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

Автоматизируйте тесты, требующие нескольких конфигураций

Речь идет о тестах в различных операционных системахи комбинациях браузеров. Делать все это вручную - утомительно. Также, автоматизация таких тестов может помочь сэкономить время. Автотесты можно запускать в различных средах (таких как Dev, QA, Staging, Integration или PROD), просто изменив переменную среды. Тесты также можно запускать параллельно, что сокращает время, необходимое для выполнения. Вы можете использовать различные инструменты CI, такие как CircleCI, чтобы указать ОС, браузеры и среды, в которых вы хотите запускать параллельные тесты. Убедитесь, что вы следуете лучшим практикам при создании параллельных тестов, чтобы получить от них максимальную пользу.

Автоматизируйте ваши тесты производительности

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

Ваш следующий шаг

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

Переведено командой QApedia. Еще больше переведенных статей вы найдете на нашем телеграм-канале.

Обеспечить представление данных из любой большой системы так, чтобы человек мог спокойно с этими данными работать задача нетривиальная, но давно решенная. В этой гонке уже давно победило "дерево". Папочные структуры в операционных системах знакомы всем и каждому и исторически простое дерево в UI/UX становится первым решением для упорядочивания и хранения данных. Сегодня поговорим о тестировании, так что в нашем случае объектами хранения будут выступать тест-кейсы. Как их хранят чаще всего? Верно, в папочках!

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

Единое дерево

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

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

Что с ним не так?

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

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

Минусы дерева папок отсутствие гибкости в доступе к данным и аналитике и сложность рефакторинга в условиях, когда требования к тестированию меняются.

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

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

В итоге папочки станут снова управляемыми, уровни вложенности структурируются, но снова получится только один срез по фичам. Если попытаться создать структуру с двумя срезами, по фичам и компонентам сразу, ее сложность и запутанность создаст больше проблем, чем пользы. А если у вас 3000 тест-кейсов? А если 10000?

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

Еще один подводный камень хранения тестов в папках ждет тех, кто планирует хранить в них автоматизированные тесты, написанные на разных языках программирования. Тут все просто: в Java тесты хранятся по полному имени пакет вроде io.qameta.allure, а в JavaScript или Python просто по имени пакета. Это значит, что при автоматической генерации тест-кейсов из автотестов, каждый фреймворк будет городить свои подструктуры в дереве и вся нормализация и базовая структура будет нарушена. Конечно, можно написать свою интеграцию для каждого фреймворка, но мы же стараемся упростить себе жизнь, верно?

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

Как эту задачу решали Ops'ы?

С ограничениями классического дерева разобрались, а как их обходить? На самом деле, с этой задачей уже сталкивались многие, и изобретать велосипед нет необходимости. Большинство систем, работающих с большими объемами данных или большим количеством объектов переходят на плоскую структуру с навигацией по признакам. Самый яркий из недавних примеров инструменты мониторинга типа Grafana и Graphite.

Давайте рассмотрим его повнимательнее и попробуем применить к тестированию. Админы и все те, кто работают в Ops к метрикам и данным относятся с большой щепетильностью и любовью. Просто потому, что о падении сервиса, сети или недоступности какой-то кластера вы захотите узнать раньше пользователя, так? Изначально весь мониторинг строился по классической иерархической структуре: дата-центр кластер машинка метрики (CPU, RAM, storage и прочее). Удобная и понятная система, которая работает, если не приходится в реальном времени отслеживать десяток метрик, которые не привязаны к физическим машинам. А метрики для Ops'ов очень важны.

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

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

Набор меток хранится в плоской структуре и свободно используется любой критерий поиска, фильтрации или группировки становится меткой

Чтобы получить отчет или анализ данных, нужно просто указать, по каким критериям срезы нас интересуют: нагрузка на CPU по инстанстам, разделенным по географии.

Такой метод управления данными позволяет не только фильтровать и делать выборки внутри структуры. Он предоставляет еще один уровень свободы в виде вышеупомянутой группировки: теперь можно спокойно сделать запрос к хранилищу вида "покажи статистику доступности всех машин, на которых крутится такой-то микросервис с группировкой по кластерам". Парсер проходится по всем машинам, забирает статистику доступности с тех, на которых стоит метка микросервиса и группирует их по кластерам.

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

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

Да это же просто автоматизация папочек! скажете вы.

И это прекрасно это классическое решение проблемы масштабирования. Конечно, у системы с метками есть несколько минусы:

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

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

Тест-кейсы: дерево против меток

Хорошо, с админами все понятно. Они там сидят и целый день смотрят в метрики и крутят данные. А нам-то зачем?

Ответ прост: мир разработки, к сожалению или к счастью, уже давно ушел от жесткой структуры релизы ускоряются, сборки автоматизируются. На фоне этих изменений, мир тестирования в большинстве компаний выглядит немного архаично: на новые фичи готовится по пачке новых тест-кейсов для ручных тестов и автоматизации, они раскладываются по папкам, запускается в тестирование на неопределенный срок (от 1-2 дней до недели), собирается результат тестирования и отгружается обратно в разработку после полного завершения. Ничего не напоминает? Это же старая добрая каскадная разработка (waterfall, то бишь)! В 2021 году. Если послушать Баруха Садогурского в одном из подкастов, где он довольно убедительно рассказывает, что любой процесс это по сути agile, в котором "мы пытаемся отложить принятие решения максимально далеко, чтобы перед этим собрать побольше данных", станет понятно, почему весь мир разработки гонится за короткими итерациями и быстрыми релизами. Именно поэтому разработчики уже давно пишут софт итеративно, внедряя по одной фиче или паре фиксов на релиз, опсы отгружают эти релизы как можно скорее, которые перед этим тестируются. А как они тестируются?

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

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

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

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

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

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

Согласитесь, звучит заманчиво: иметь гибкость JIRA-тикетов в управлении тест-кейсами. Останется только автоматизировать запуски на слияние веток и вот тестирование уже отвечает требованиям DevOps!

Всем привет! Недавно я наткнулся на World Quality Report (ссылку поставил в конце, чтобы не пугать вас сразу отчетом на 50 страниц) большой обзор трендов в тестировании 2020-2021 годов. А поскольку мы в Qameta Software сами постоянно сталкиваемся с командами тестирования, которые стараются как-то поправить свои процессы и наладить работу тестирования, я решил оценить, насколько они актуальны в России.

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

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

1. DevOps и Agile приходит в тестирование

Правда.

Больше релизов больше тестирования. Все больше компаний пытаются вплести тестирование в цикл разработки, построенный на принципах DevOps: нет времени прогонять сотни ручных тестов, приходится думать об автоматизации, инфраструктуре и процессах, которые обеспечат и скорость, и качество, и гибкость.

Именно поэтому в последнее время инструменты для автоматизации тестирования находятся на подъеме: Cypress, Playwright, Pupperteer и многие другие. Тестировщикам тоже приходится меняться и учиться подходам разработчиков: автоматизации, масштабированию и работе по спринтам.

2. Искусственный интеллект и машинное обучение

Пока нет.

Мы ждем прихода ИИ уже давно. Что же, все еще ждем теперь в управлении качеством. Появляются стартапы, фокус которых лежит в области подготовки, генерации и анализа тестовых данных или тестирования сервисов с помощью ИИ. Не верите? Посмотрите на Applitools, Functionize, Synthesized, TestIM или ReportPortal.

Под удар в первую очередь попадает ручное тестирование 90% участников опроса ищут ИИ-решения, ориентированные именно на замену ручного труда в тестировании. Пока мы такого тренда не наблюдаем, вполне вероятно, он придет к нам позже.

3. Оптимизация бюджетов на тестирование

Похоже на правду.

Расходы на тестирование сократились в среднем на 13%. Авторы обзора списывают тягу к оптимизации расходов на COVID-19 и развитие трендов цифровой трансформации, что бы это не значило.

Я бы не винил пандемию. Кажется, что двух предыдущих разделов достаточно, чтобы объяснить оптимизацию количества людей, задействованных в ручном тестировании. А тем, кто остался, в руки попадут инструменты, помогающие работать быстрее и эффективнее: и окружения в облаках, и автоматизация тестов, и пайплайны для их прогонов. В итоге, тестирование должно вернуться в цикл разработки DevOps/Agile.

4. Фокус на автоматизацию тестирования

Правда.

Этот пункт не про автотесты, как можно было подумать. Он про автоматизацию процессов тестирования в целом: от создания тест-кейсов до репортинга. Я писал об этом раньше, этот тренд мы видим как один из самых явных. Меньше людей больше автоматизации.

Этот тренд подтверждается нашими наблюдениями все больше пользователей Allure Report двигаются в сторону автоматизации и инструментов, которые позволяют эту автоматизацию аккуратно вплести в процессы (это мы видим по спросу на TestOps).

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

5. Управление тестовыми окружениями (ТО) и тестовыми данными (ТД)

Похоже на правду.

Управлять тестовыми данными и тестовыми окружениями сложно, хорошо, что под эту задачу тоже появляются инструменты. Участники исследования смотрят на это развитие с оптимизмом: ТО и ТД уходит в облака; внедряются тулы для управления тестовыми данными (пока преимущественно для маскирования); все чаще используются инструменты виртуализации серверов и данных.

Забавно, что в этой области вопросов больше с юридической точки зрения, чем с технологической.

6. COVID-19 помог компаниям трансформироваться

Неправда.

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

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

Вместо итогов

В общем, World Quality Report получился скорее интересный, чем нет. Да, где-то есть призывы в духе "нормально делай нормально будет", но в целом рекомендую к ознакомлению. В отчете несколько десятков страниц, из которых я постарался сделать выжимку, так что каждый при внимательном изучении сможет найти интересные детали.

Остается только спросить, какие тренды ощущаете вы? Что происходит в вашем тестировании, и насколько все это совпадает с наблюдениями из отчета.

Всем привет! Меня зовут Миша, я работаю на позиции ручного тестировщика, или Manual QA - кому как удобно. В связи с тем, что в моей работе преобладает ручное тестирование - я часто сталкиваюсь с консолью разработчика в браузере (думаю как и 99.9% web-тестировщиков).

В интернете огромное количество источников, в которых можно найти информацию про DevTools, как для разработчиков, так и для тестировщиков. Конечно, наполнение таких статей очень сильно разнится в зависимости от ее направленности. Изучив большое количество подобного материала и поняв, что нас (тестировщиков) обделяют информацией :), решил залезть в первоисточник для изучения инструментов разработчика в полном объеме. Пройдясь по всем пунктам огромного меню, выписал для себя порядка 20 пунктов, которые были бы интересны (читай полезны) для тестировщиков. Сразу скажу, что в статье я не буду рассказывать, как пользоваться тем или иным инструментом, так как это подробно описано в статьях, которые будут прикреплены к каждому из пунктов. Цель моего повествования - скорее вычленить из огромного списка возможностей DevTools, именно те, которые были бы полезны для QA-специалистов. Не претендую на объективность и полную раскрытость темы, но постараюсь это сделать.

P.S.: Очередность пунктов в списке не говорит об их важности.

1. Эмуляция android и ios, подключение android при отладке.

   Как мне кажется, на данный момент большинство компаний, которые делают продукты для мобильных устройств, имеют парк, из необходимых для полного тестирования их продукта, девайсов. Однако далеко не все считают необходимым тратить деньги на подобное. И, необходимость протестировать свой продукт на том или ином устройстве, не всегда зависит от того делают ли данный продукт для мобилок или нет. В связи с этим есть необходимость проверять свои сайты на мобильных устройствах без их физического присутствия. Минус данного подхода заключается в том, что большинство этих эмуляторов являются коммерческими.

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

2. Переопределение геолокации и подмена User-Agent.

   Продолжим рассматривать возможности DevTools для мобильных устройств. В вышеуказанных двух пунктах говорится о возможности изменять (подменять) геолокацию нахождения устройства и параметры юзер агента. Думаю, что многим тестировщикам частенько приходится воспроизводить какие-либо баги, которые были выловлены клиентами продукта не имея на то соответствующих технических возможностей. Подмена User-Agent поможет воспроизвести тот или иной баг, который был воспроизведен из какой-либо версии браузера или ОС. Закончив тестирование, никогда не забывайте возвращать данные User-Agent в исходное положение.

   Подмена User-Agent

3. Определение JS пути к строке.

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

4. Изменение стилей CSS у элементов.

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

   Пример изменения размера поля элемента

5. Неиспользуемые CSS и Javascript в вёрстке.

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

   Отчет о покрытии кода

6. Немного интересного про debug JavaScript.

   Многим этот пункт покажется лишним, ведь дебажить код - это вещь, которой в основном занимаются разработчики для отладки кода. Но со своей стороны хочу сказать, что это умение для тестировщика, лишним точно не будет. Безусловно для отладки кода необходимо уметь его читать. Думаю, многие видели большое количество мемов про JavaScript, которые красноречиво говорят о том, что язык далеко не самый легкий, особенно для простого обывателя. С другой стороны, некоторые данные иногда формируются на фронте, проходя несколько функций и понять почему в переменной сформировалось определенное значение, бывает очень важно. Даже в мои 3 года опыта работы в тестировании я уже сталкивался с дебагом кода именно в Chrome. Безусловно, без помощи разработчика я бы вряд ли смог это сделать, но в этой ситуации я понял, что этот момент очень важен.

7. Сохранение изменений в Chrome при перезагрузке страницы.

   Такую возможность добавили в DevTools относительно недавно (с 65 версией). Она позволяет сохранять все изменения, которые были внесены в те же CSS стили, о которых я говорил выше. И при перезагрузке страницы они сохранятся, чтобы, например, была возможность посмотреть, как ведет себя измененная кнопка при загрузке страницы.

8. Имитация медленного сетевого соединения.

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

   Выбор скорости соединения

9. Настройка столбцов на вкладке Network.

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

   Список возможных столбцов в Network

10. Снимки экрана при загрузке страницы.

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

11. Блокирование запросов.

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

    

12. Все о cookies во вкладке applications.

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

Бонусы:

Здесь я бы хотел оставить те ссылки (с небольшими пометками), которыми я лично еще не пользовался, но которые, по моему мнению, были бы полезны для изучения и последующего применении тестировщиком на практике:

• описание всех shortcuts, которые существуют в chrome DevTools;

• все об анализе безопасности;

• имитация нового посетителя;

• повтор xhr запроса;

• проверка анимации;

• основные команды для запуска JavaScript в консоли;

• основные проблемы, которые можно увидеть во вкладке network.

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

Всем спасибо за внимание!