Tests vs Specs
Вторую неделю все собираюсь выложить свои мысли. И все не хватает времени... А почему не хватает? как раз причина в том, о чем хочу написать.
Наши доблестные QA человеки формально подчиняются другому начальнику. Что означает что задачи им даю я, но за их выполнение они несут ответственность перед другим начальником. А вполне естественно что тот, кто тебя оценивает, тот для тебя и главный. Это выливается в следующую картину. Даю задачу по бизнес проекту. Приходит формальный начальник и просит отчет. Кто побеждает? Конечно же отчет. А вместе с ним куча митингов, one-to-one, структура и оформление отчетов, метрики и всякая такая дребедень. У нормального российского QA это вызывает когнитивный диссонанс. С одной стороны он понимает, что все что мы делаем - делаем для наших любимых трейдеров и доставить продукт - важнее всего. С другой стороны его все время дрючат ругают за отсутствие томов с никому ненужными тестами и отчетами об их прохождении.
Что же нужно в действительность? Нужен хороший, рабочий продукт. Как удовлетворить качество? тестировать. Причем тестировать разумно. Для таких больших и древних систем как наша талмуды рукописных тестов, авто тестов в разных фреймворках порождают апатию к тестированию и понимание, что ничего мы не достигнем. Никакого мифического 100% покрытия.
Как же тестировать и не погрязть в тоннах макулатуры? На самом деле никаких тестов не надо. Мы же не индусы, чтобы прокликивать написанное. Нормальному QA специалисту надо знать как система должна работать. А для этого нужно описание системы, а не шаги по тестам. Поэтому я считаю, что самое главное - это иметь хорошо структурированное полное и неизбыточное описание поведения системы. Чтобы его легко было искать и понимать как в разных ситуациях система себя ведет (или должна).
А вот как это описание создать - тема отдельного топика ))
Пока же QA строчат отчеты и тест кейзы, которые следующее поколение выкенет.
Наши доблестные QA человеки формально подчиняются другому начальнику. Что означает что задачи им даю я, но за их выполнение они несут ответственность перед другим начальником. А вполне естественно что тот, кто тебя оценивает, тот для тебя и главный. Это выливается в следующую картину. Даю задачу по бизнес проекту. Приходит формальный начальник и просит отчет. Кто побеждает? Конечно же отчет. А вместе с ним куча митингов, one-to-one, структура и оформление отчетов, метрики и всякая такая дребедень. У нормального российского QA это вызывает когнитивный диссонанс. С одной стороны он понимает, что все что мы делаем - делаем для наших любимых трейдеров и доставить продукт - важнее всего. С другой стороны его все время дрючат ругают за отсутствие томов с никому ненужными тестами и отчетами об их прохождении.
Что же нужно в действительность? Нужен хороший, рабочий продукт. Как удовлетворить качество? тестировать. Причем тестировать разумно. Для таких больших и древних систем как наша талмуды рукописных тестов, авто тестов в разных фреймворках порождают апатию к тестированию и понимание, что ничего мы не достигнем. Никакого мифического 100% покрытия.
Как же тестировать и не погрязть в тоннах макулатуры? На самом деле никаких тестов не надо. Мы же не индусы, чтобы прокликивать написанное. Нормальному QA специалисту надо знать как система должна работать. А для этого нужно описание системы, а не шаги по тестам. Поэтому я считаю, что самое главное - это иметь хорошо структурированное полное и неизбыточное описание поведения системы. Чтобы его легко было искать и понимать как в разных ситуациях система себя ведет (или должна).
А вот как это описание создать - тема отдельного топика ))
Пока же QA строчат отчеты и тест кейзы, которые следующее поколение выкенет.