Про Качество, или почему Иногда Бывает Полезно Почитать ЖЖ
Дискуссия про качество в ЖЖ у psilonsk сработала для меня триггером и сподвигла заняться тем, до чего у меня давно не доходили руки. А именно - структурировать и формализировать наш собственный QA.
Разумеется, перед тем как выпустить новую версию, мы ее вовсю тестируем. Но у меня было постоянно ощущение какой-то неупорядоченности в процессе тестирования и отсутствие четкой структуры самого процесса. Как результат - решение об окончании тестирования и выпуске версии принималось скорее интуитивно, чем основываясь на каких-то определенных критериях. В итоге, пару раз у клиентов вылезали баги, которые мы вообще-то должны были поймать намного раньше. Разумеется, мы все быстро чинили, и все оставались довольны, но было понятно, что больше так продолжаться не может. К тому же, система, основанная на одной лишь интуиции, плохо масштабируема и в перспективе неуправляема.
В общем, на выходных мы с моим ко-фаундером посидели и начали приводить все процессы тестирования в порядок. Теперь есть формализованная процедура, и пока она вся не будет пройдена, версия не будет выпущена. Процедура включает в себя несколько шагов (внутри каждого шага есть четко прописанные процессы что и как делать):
1. Sanity check - это несколько базовых проверок, цель которых убедиться в том, что все в принципе запускается и не валится от малейшего прикосновения.
2. Regression tests - это серия тестов, цель которых проверить не повреждены ли существующие фичи. У нас для этого есть специальный сценарий, который обязан проходиться от начала до конца без единой ошибки. Пока этот сценарий не будет бесперебойно пробегать, версия выпущена не будет.
3. Тесты новых функциональностей. Здесь под каждую версию будет писаться план тестирования. План должен включать сценарии, которые надо проверить, и статус каждого сценария после проверки (passed или failed). Если сценарий провалился, то в нашей внутренней базе данных багов открывается новый баг, а в план тестирования заносится номер бага.
4. Серия тестов, которая проходит под кодовым названием Fuck Me if You Can. Здесь проверяются всякие неочевидные сценарии (например, что будет, если во время загрузки файлов из компьютера выдернуть сетевой кабель; или что будет, если посредине работы перегрузить сервер) и как DITAToo на них реагирует. Плюс всякие ad hoc сценарии, не вошедшие ни в п.2, ни в п.3.
(У нас и до этого похожая процедура была, но из-за того, что она была не формализирована, было сложно получить общую картину того насколько глубоко и тщательно проведено тестирование.)
Кроме того, мы, кажется, придумали формальные критерии для определения приоритета бага. Приоритет определяет, когда баг должен быть починен, и будет ли версия выпущена с ним или без него. До сих пор, приоритет присваивался чисто интуитивно. В очевидных случаях все понятно (скажем, багу, который приводит к крэшу системы, будет присвоен наивысший приоритет). Но в ряде случаев, все далеко не так понятно.
В общем, мы ввели два параметра:
1. Тип провалившегося сценария:
-- Стандартный: это сценарий, который широко встречается и характерен для большинства (если не для всех) юзеров
-- Нишевой: это сценарий, который может быть характерен для определенной группы юзеров, но внутри этой группы он вполне вероятен. Например, у нас однажды был баг, который был связан с использованием умляутов. Критичен этот баг был только для наших европейских юзеров, и то не для всех, а только для тех, кто хранит контент на языках типа немецкого.
-- Маргинальный: это очень маловероятный сценарий, который может произойти только у юзеров с очень-очень шаловливыми ручонками.
2. Критичность бага для работы:
-- Низкокритичный: это то, что практически никак не влияет на работу, хотя может немного раздражать
-- Критичный: это то, что мешает юзеру выполнить задачу или требует хитрых обходных путей
-- Высококритичный: это, как правило то, что вообще валит систему
Так вот, приоритет определяется комбинацией этих двух параметров. Например, если сценарий маргинальный и баг низкокритичный, то приоритет низкий. Если сценарий стандартный, а баг критичный, то приоритет высокий - с таким багом выпускать версию нельзя. Ну и так далее. Мы еще над критериями работаем, там не все пока ясно, но идея понятна.
Хорошие новости для нас в том, что у нас на подходе новая версия (minor upgrade), так что у нас будет возможность обкатать на практике и усовершенствовать наш новый подход прямо "не отходя от кассы".
Такие дела. Вот до чего может дойти простое прочтение одного-единственного поста в ЖЖ, даже не имеющего к нам непосредственного отношения ;-)
Разумеется, перед тем как выпустить новую версию, мы ее вовсю тестируем. Но у меня было постоянно ощущение какой-то неупорядоченности в процессе тестирования и отсутствие четкой структуры самого процесса. Как результат - решение об окончании тестирования и выпуске версии принималось скорее интуитивно, чем основываясь на каких-то определенных критериях. В итоге, пару раз у клиентов вылезали баги, которые мы вообще-то должны были поймать намного раньше. Разумеется, мы все быстро чинили, и все оставались довольны, но было понятно, что больше так продолжаться не может. К тому же, система, основанная на одной лишь интуиции, плохо масштабируема и в перспективе неуправляема.
В общем, на выходных мы с моим ко-фаундером посидели и начали приводить все процессы тестирования в порядок. Теперь есть формализованная процедура, и пока она вся не будет пройдена, версия не будет выпущена. Процедура включает в себя несколько шагов (внутри каждого шага есть четко прописанные процессы что и как делать):
1. Sanity check - это несколько базовых проверок, цель которых убедиться в том, что все в принципе запускается и не валится от малейшего прикосновения.
2. Regression tests - это серия тестов, цель которых проверить не повреждены ли существующие фичи. У нас для этого есть специальный сценарий, который обязан проходиться от начала до конца без единой ошибки. Пока этот сценарий не будет бесперебойно пробегать, версия выпущена не будет.
3. Тесты новых функциональностей. Здесь под каждую версию будет писаться план тестирования. План должен включать сценарии, которые надо проверить, и статус каждого сценария после проверки (passed или failed). Если сценарий провалился, то в нашей внутренней базе данных багов открывается новый баг, а в план тестирования заносится номер бага.
4. Серия тестов, которая проходит под кодовым названием Fuck Me if You Can. Здесь проверяются всякие неочевидные сценарии (например, что будет, если во время загрузки файлов из компьютера выдернуть сетевой кабель; или что будет, если посредине работы перегрузить сервер) и как DITAToo на них реагирует. Плюс всякие ad hoc сценарии, не вошедшие ни в п.2, ни в п.3.
(У нас и до этого похожая процедура была, но из-за того, что она была не формализирована, было сложно получить общую картину того насколько глубоко и тщательно проведено тестирование.)
Кроме того, мы, кажется, придумали формальные критерии для определения приоритета бага. Приоритет определяет, когда баг должен быть починен, и будет ли версия выпущена с ним или без него. До сих пор, приоритет присваивался чисто интуитивно. В очевидных случаях все понятно (скажем, багу, который приводит к крэшу системы, будет присвоен наивысший приоритет). Но в ряде случаев, все далеко не так понятно.
В общем, мы ввели два параметра:
1. Тип провалившегося сценария:
-- Стандартный: это сценарий, который широко встречается и характерен для большинства (если не для всех) юзеров
-- Нишевой: это сценарий, который может быть характерен для определенной группы юзеров, но внутри этой группы он вполне вероятен. Например, у нас однажды был баг, который был связан с использованием умляутов. Критичен этот баг был только для наших европейских юзеров, и то не для всех, а только для тех, кто хранит контент на языках типа немецкого.
-- Маргинальный: это очень маловероятный сценарий, который может произойти только у юзеров с очень-очень шаловливыми ручонками.
2. Критичность бага для работы:
-- Низкокритичный: это то, что практически никак не влияет на работу, хотя может немного раздражать
-- Критичный: это то, что мешает юзеру выполнить задачу или требует хитрых обходных путей
-- Высококритичный: это, как правило то, что вообще валит систему
Так вот, приоритет определяется комбинацией этих двух параметров. Например, если сценарий маргинальный и баг низкокритичный, то приоритет низкий. Если сценарий стандартный, а баг критичный, то приоритет высокий - с таким багом выпускать версию нельзя. Ну и так далее. Мы еще над критериями работаем, там не все пока ясно, но идея понятна.
Хорошие новости для нас в том, что у нас на подходе новая версия (minor upgrade), так что у нас будет возможность обкатать на практике и усовершенствовать наш новый подход прямо "не отходя от кассы".
Такие дела. Вот до чего может дойти простое прочтение одного-единственного поста в ЖЖ, даже не имеющего к нам непосредственного отношения ;-)