Как QA-инженеру вырасти из джуна в руководителя?

А мне очень интересно ваше мнение)

С большей частью этапов я столкнулась вне Авито, но, когда была наставником для новых сотрудников и стала руководителем, увидела пересекающиеся с моим опытом особенности мышления. И перейти от "тестировщика" к "QA инженеру" именно в голове не так просто, а к каждому своему инженеру я ищу индивидуальный подход.

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

Как и зачем мы написали 5000 интеграционных тестов за пару часов

Нужны) На генератор также пишем тесты, как и на любой свой сервис

Как и зачем мы написали 5000 интеграционных тестов за пару часов

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

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

Как и зачем мы написали 5000 интеграционных тестов за пару часов

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

Как и зачем мы написали 5000 интеграционных тестов за пару часов

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

Как и зачем мы написали 5000 интеграционных тестов за пару часов

Мы пишем на Go, у нас принят формат табличных тестов. Шаблон выглядит достаточно просто - это каркас табличного теста, в который подставляется набор тестовых сценариев после этапа сбора данных

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

Выглядит это примерно вот так:

// собираем тестовый сценарий 
func {{ testScenarioName }}(t *testing.T) { testCategory := &domain.Category{ Name:     "{{ $testScenario.Category.Name }}", }
testdata := []struct{
    name              string
    Category          *domain.Category
    expectedFields    []*domain.Field
}{
// собираем тест-кейсы. Каждый тест-кейс - это ожидаемый набор полей от валидатора
{{- range .Cases }}
    {
        name:              "{{ testCaseName }}",
        Category:     testCategory,
        expectedFields: []*domain.Field{
        {{- range .ExpectedFields }}
            {
                Data: &domain.FieldData{
                    Label:         "{{ .Data.Label }}",
                    Widget:        &domain.Widget{
                        Type: "{{ .Data.Widget.Type }}",
                        Config: `{{ .Data.Widget.Config | escapeBackQuotes }}`,
                    },
                    IsRequired:    {{ .Data.IsRequired }},
                },
            },
        {{- end }}
    },
{{- end }}

// инициализируем клиент валидатора для запросов реального текущего состояния
validationClient := out.NewValidationClient("master")
testComparator := test_comparator.New()
for _, data := range testdata {
    t.Run(data.name, func(t *testing.T) {
        // получаем актуальный список полей после внесенных изменений от контент-менеджера
        actual, err := validationClient.GetForm(context.Background(), data.Category)
        if !assert.NoError(t, err) {
            return
        }

        // сравниваем набор ожидаемых полей с теми, что получили в результате запроса к изменениями контент-менеджера
        assertions := make([]test_comparator.Assertion, 0)
        assertions = append(assertions, testComparator.CompareFields(actual.Fields, data.expectedFields)...)
        
        for _, assertion := range assertions {
            assertion(t)
        }
    })
}
}