Как стать автором
Обновить

Мы же всё протестировали, или откуда берутся баги на проде (часть 1)

Уровень сложностиПростой
Время на прочтение12 мин
Количество просмотров16K
Всего голосов 14: ↑12 и ↓2+13
Комментарии25

Комментарии 25

А какие ваши предположения будут, когда Google выпускает в релиз версию Android Studio, которая не может скомпилировать код, потому что впадает в самоблокировку?

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

1) как можно было обнаружить эту проблему до релиза;

2) почему ее не обнаружили до релиза;

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

“Критичный баг на проде!”

Это сообщение в рабочем мессенджере, пожалуй, самый страшный сон тестировщика/QA-специалиста.


Ох уж эти сказочки, ох уж эти сказочники (с)

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

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

Разбудят аналитика, чтобы придумал WA, разбудят тимлида — чтобы начинал сначала разбираться в причинах, а потом чинить, разбудят руководителя проекта. Даже если сообщение придет в общий чат команды — правильный QA продолжит сладко спать. И правильно сделает, кстати.

Как минимум - тестировщик быстрее и лучше локализует проблему. Как максимум - пофиксит, доступными ему средствами. Если у вас это не так - могу только посочувствовать

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

Мне запомнились слова тимлида на этот счёт: не переживай, ты не один, мы втроём допустили этот баг [автор, ревьювер и тестировщик, к которым могут добавиться и другие участники процесса] :)

И вот как-то даже не поспоришь :)

Да, нас, тестировщиков, как правило, не будят посреди ночи, когда обнаружен баг на проде.

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

Поэтому, когда тестировщик узнает о баге на проде (пусть и утром), то чаще всего первая мысль, которая его посещает, - "Это я пропустил(а) баг". И это в любом случае не самые приятные эмоции, а для начинающих - так и вообще стресс.

Но это я про ответственных тестировщиков, конечно :)

те, кто последними проверяют фичу перед передачей в прод.

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

Так ведь и написано "страшный сон", тогда как для кого то в команде это уже не сон, а страшная реальность )

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

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

Когда-то одна из крупнейших розничных сетей (назовём так) развернула в многих десятках тысяч отделений наше решение на базе MS SQL Server. С центральными офисами была налажена репликация данных. При репликации из нескольких отделений стали стабильно пропадать отдельные блоки записей. Анализ бэкапов отделений показал, что ms sql change-tracking имеет странные "пропуски" - часть изменений записей MS SQL не видел.

Документация прямо утверждала, что такое невозможно из-за гарантий атомарности сохранения записи и ее отметки в change-tracking. То же самое утверждал и Microsoft (внимательно глядя на битые записи) и требовал воспроизведения.

<тут должна была быть очень длинная и интересная история воспроизведения>

Оказалось, что отметки change-tracking всё-таки ставятся не в той же транзакции, что и запись и при выключении питания отметки теряются. Парни из MS завязались на системное событие выключения Windows и прямо мамой клялись, что это норм - никто не включает сервер внезапно )))

А условная бабушка в мини-отделении, где всё было развернуто на одной машине и клиент и сервер, этого не знала и спокойно ногой выдергивала вилку питания, когда уходила на обед. Для пожарной безопасности!

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

Классная история! Прямо как стандартное "Никто ж так делать не будет!" + еще как минимум 10 причин ⬇️

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

Забавно )

У нас была отдаленно похожая история. Правда про предложения по улучшению.

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

Ну а фичу добавили в бэклог и спустя какое-то время зарелизили )

Я бы добавил еще такие:

  • Тестовых данных оказалось недостаточно для проявления бага

  • Не было комплексного или совместного тестирования всех доработок, особенно если несколько изменений были внесены разными командами в один механизм

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

👍

Пункты #2 и #3 в принципе могут как НЕ зависеть от тестировщиков, так и быть упущением со стороны QA-команды. Надо смотреть по ситуации, конечно.

Пункт #2. Если работают несколько команд, то как минимум QA Team Lead должен отслеживать и уточнять скоупы и их возможные пересечения. И соответственно планировать тестирование.

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

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

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

ИМХО. Основной смысл тестирования - повысить качество продукта /снизить риск выпуска некачественного ПО или фичи. Поиск багов это всего лишь один из способов, как этого добиться.

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

Тестирование же включает в себя разные активности на протяжении всего SDLC.

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

Или еще на этой же стадии (да и даже на стадии тестирования фичи) мы можем вносить предложения по улучшению.

Это ведь все не баги, но тем не менее на качество влияет.

Да и в целом тестирование - это не только поиск багов. В первую очередь - это подтверждение того, что приложение/фича работает по требованиям и позволяет достигать поставленной цели. И такое подтверждение - это уже отметка об определённом уровне качества.

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

А баги, найденные на более ранних этапах SDLC - это все-равно баги, просто ошибку допускает не разработчик в коде - до разработки дело еще не дошло - а, например, аналитик в требованиях

Смыслов у тестирования много

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

  2. Дать обратную связь разработчикам: насколько хорошо у них построен процесс разработки. Обычно есть корреляция: чем лучше построен процесс разработки, тем меньше ошибок на выходе (в том числе регрессионных).

  3. Минимизировать количество багов на этапе тестирования продукта за счет тестирования требований к продукту еще до написания кода.

  4. Верифицировать исправления багов.

Может еще чего забыл.

1, 2, 3, 4... - все в итоге своидтся к тому же. Нашли что-то, что повлияет на изменение продукта - продукт стал лучше. Нет - на прод пойдет тот же самый продукт, который туда пошел бы при полном отсутствии тестирования

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

И со странным упорством сводите смысл "получить информацию о состоянии продукта" к "если в отчете по тестированию нет багов - тестирование бесполезно". Забывая о том, что после грамотного тестирования бизнес получает информацию о том, что продукт работает. А кто владеет информацией, тот владеет миром. Без тестирования нет информации. Есть только предположения, что продукт работает. А как работает - непонятно.

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

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

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

С сисадмином тоже все просто - работает или он, или система. Так что ваши домыслы мимо.

Насчет тестирования, немного копипасты:

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

Надпись гласила: Ровно 14!

— Четырнадцать чего? — удивился мистер Томпкинс.

— Четырнадцать проверок кода без единой ошибки, — Молли прямо светилась от радости.

— Это впечатляет, — пробормотал мистер Томпкинс. — Я полагаю, мы вполне могли бы сэкономить те сорок два человекочаса, которые были затрачены на эти проверки кода, а на качестве продукта это никак бы не отразилось. Ведь ошибок все равно не было.

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

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

Отличная статья, спасибо. Одну цитату отправил в рабочий чат)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории