Про тестирование и организацию процессов
Сегодня в чатике тестировщиков (не знаю, почему я продолжаю его читать, несмотря на преимущественно бредовые темы и админа с синдромом вахтёра) было бурное обсуждение ситуации: пропустили в прод баг, из-за которого был простой прода и недовольный заказчик. В итоге тестировщика, пропустившего это, депремировали.
Изначально было известно, что тестировщик мидл с 15 годами опыта, полгода на проекте. Потом выяснилось, что вроде как даже тест-кейс был на сломанную функциональность.
Разумеется, основным мнением чата было: депремирование отстой, ну и вообще нашли крайнего, а надо было искать причину, почему так произошло.
Если подробнее, то были идеи о том, что тест-лид должен был проверить за ним, если нет уверенности в качестве работы этого человека. Либо проговорить заранее вместе, что именно он будет проверять, а потом проконтролировать, если это какая-то критичная фича. (Насчёт этого непонятно, была ли это обычная задача или “повышенной сложности и риска”). А если уж разбирать ситуацию, то спросить, что именно помешало человеку выполнить задачу хорошо.
В общем-то, я против поиска виноватых, а за поиск и устранение причин. В описанной ситуации профакапились и программист, и админ/девопс/кто там отвечает за выкатывание на прод (потому что видимо не было возможности быстро откатить), и тимлид, и вообще все. Но меня здесь интересует часть про тестирование.
Я, кстати, сталкивалась с практикой депремирования на одной из прошлых работ. Но это было не тестирование, а проектирование: по сути довольно механическая и простая работа. Не помню точные условия снятия премии там, потому что у меня не снимали, но была норма выполнения проектов в день, и если в течение месяца регулярно её недовыполнять, получался минус. Норма была что-то типа 5 штук в день, при том что не напрягаясь можно было сделать 10.
Не знаю, чего там было реально больше: нежелания работать или непонимания (нежелания разбираться?), как пользоваться проектными программами.
Но тут оценка при (не)выплате премии была понятна. Да и вообще я отвлеклась.
Так вот, в моём мире (при отсутствии какой-то ещё информации, кроме вышеописанной) человеку с опытом, да ещё и не только вчера пришедшему на проект, вполне можно доверить выполнять задачу самостоятельно, и в контроле он не нуждается. А уж если был тест-кейс, то тут и обсуждать нечего.
Кстати, в обсуждении сегодня была и мысль: а были ли у тестировщика необходимые данные, а был ли чёткий тест-кейс, а если кейса не было, а был только вопрос “ну ты там проверил всё?”, то он вообще ни в чём не виноват. Но если кейс такой, что чётко описывает ситуацию, а тестировщик такой, что проверяет исключительно по кейсам, зачем вообще нужен такой тестировщик, можно же заавтоматизировать?
С января я перешла в новую (старую) команду, и всё это время помимо проверки текущих задач я разгребаю говнотесты. В них названия не соответствуют действиям, вместе они не соответствуют описанию, а уж если там внутри комментарии написаны, то все шансы, что и они ни с чем вокруг не сочетаются. А ещё много тестов, которые ничего не проверяют, проверяют какую-то ерунду (а не то, что было в задаче, для которой они написаны), дублируют друг друга. И в поисках “а какого хрена оно вообще должно так работать” (проект старый, и не на всё есть описание в документации) натыкаюсь на заверифаенные задачи, которые, судя по коммитам, изначально были сделаны совершенно неправильно.
Исхожу из предположения, что люди всё-таки не вредители и такая ситуация сложилась не из злого умысла. Ну у автоматизатора точно.
Когда работала с джунами, показалось, что они хотят быстрее-быстрее, не успевают подумать и бегут дальше. А уж если такой человек начинает автотесты писать, то туши свет: он свои проверки не придумал до конца, а уже код пишет. Получается либо каша из головы сразу попадает в том же виде в автотест, либо человек сталкивается с какой-то программерской проблемой, решает её и тогда вообще забывает, что он там проверить собирался. Впечатление такое, что не хватает внутренней способности остановиться, подумать и продумать.
В понедельник к нам в команду выходит новый тестировщик. Формально не в подчинение мне, но фактически наставничать и первое время давать задачи буду я. Голова забита размышлениями, как сделать, чтобы не было опять, как было. А чёткого понимания в этом нет.
Изначально было известно, что тестировщик мидл с 15 годами опыта, полгода на проекте. Потом выяснилось, что вроде как даже тест-кейс был на сломанную функциональность.
Разумеется, основным мнением чата было: депремирование отстой, ну и вообще нашли крайнего, а надо было искать причину, почему так произошло.
Если подробнее, то были идеи о том, что тест-лид должен был проверить за ним, если нет уверенности в качестве работы этого человека. Либо проговорить заранее вместе, что именно он будет проверять, а потом проконтролировать, если это какая-то критичная фича. (Насчёт этого непонятно, была ли это обычная задача или “повышенной сложности и риска”). А если уж разбирать ситуацию, то спросить, что именно помешало человеку выполнить задачу хорошо.
В общем-то, я против поиска виноватых, а за поиск и устранение причин. В описанной ситуации профакапились и программист, и админ/девопс/кто там отвечает за выкатывание на прод (потому что видимо не было возможности быстро откатить), и тимлид, и вообще все. Но меня здесь интересует часть про тестирование.
Я, кстати, сталкивалась с практикой депремирования на одной из прошлых работ. Но это было не тестирование, а проектирование: по сути довольно механическая и простая работа. Не помню точные условия снятия премии там, потому что у меня не снимали, но была норма выполнения проектов в день, и если в течение месяца регулярно её недовыполнять, получался минус. Норма была что-то типа 5 штук в день, при том что не напрягаясь можно было сделать 10.
Не знаю, чего там было реально больше: нежелания работать или непонимания (нежелания разбираться?), как пользоваться проектными программами.
Но тут оценка при (не)выплате премии была понятна. Да и вообще я отвлеклась.
Так вот, в моём мире (при отсутствии какой-то ещё информации, кроме вышеописанной) человеку с опытом, да ещё и не только вчера пришедшему на проект, вполне можно доверить выполнять задачу самостоятельно, и в контроле он не нуждается. А уж если был тест-кейс, то тут и обсуждать нечего.
Кстати, в обсуждении сегодня была и мысль: а были ли у тестировщика необходимые данные, а был ли чёткий тест-кейс, а если кейса не было, а был только вопрос “ну ты там проверил всё?”, то он вообще ни в чём не виноват. Но если кейс такой, что чётко описывает ситуацию, а тестировщик такой, что проверяет исключительно по кейсам, зачем вообще нужен такой тестировщик, можно же заавтоматизировать?
С января я перешла в новую (старую) команду, и всё это время помимо проверки текущих задач я разгребаю говнотесты. В них названия не соответствуют действиям, вместе они не соответствуют описанию, а уж если там внутри комментарии написаны, то все шансы, что и они ни с чем вокруг не сочетаются. А ещё много тестов, которые ничего не проверяют, проверяют какую-то ерунду (а не то, что было в задаче, для которой они написаны), дублируют друг друга. И в поисках “а какого хрена оно вообще должно так работать” (проект старый, и не на всё есть описание в документации) натыкаюсь на заверифаенные задачи, которые, судя по коммитам, изначально были сделаны совершенно неправильно.
Исхожу из предположения, что люди всё-таки не вредители и такая ситуация сложилась не из злого умысла. Ну у автоматизатора точно.
Когда работала с джунами, показалось, что они хотят быстрее-быстрее, не успевают подумать и бегут дальше. А уж если такой человек начинает автотесты писать, то туши свет: он свои проверки не придумал до конца, а уже код пишет. Получается либо каша из головы сразу попадает в том же виде в автотест, либо человек сталкивается с какой-то программерской проблемой, решает её и тогда вообще забывает, что он там проверить собирался. Впечатление такое, что не хватает внутренней способности остановиться, подумать и продумать.
В понедельник к нам в команду выходит новый тестировщик. Формально не в подчинение мне, но фактически наставничать и первое время давать задачи буду я. Голова забита размышлениями, как сделать, чтобы не было опять, как было. А чёткого понимания в этом нет.