Comments 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... - все в итоге своидтся к тому же. Нашли что-то, что повлияет на изменение продукта - продукт стал лучше. Нет - на прод пойдет тот же самый продукт, который туда пошел бы при полном отсутствии тестирования
Вы мне напоминаете менеджера, который уверен в том, что главный показатель работы сисадмина - это количество успешно решенных факапов. Типа если сисадмин не решает факапы каждый день - значит он не работает вовсе и нужно его уволить. Потому что он всё равно "ничего не делает".
И со странным упорством сводите смысл "получить информацию о состоянии продукта" к "если в отчете по тестированию нет багов - тестирование бесполезно". Забывая о том, что после грамотного тестирования бизнес получает информацию о том, что продукт работает. А кто владеет информацией, тот владеет миром. Без тестирования нет информации. Есть только предположения, что продукт работает. А как работает - непонятно.
Поэтому отчет о тестировании без багов - это мегаполезная штука, которая напрямую влияет на качество продукта. Это проверка на соответствие эталону. Тестировщики через план тестирования создают некий эталонный продукт. И это помогает разработчикам создавать этот эталонный продукт. Потому что понятно, где проходит черта, после которой продукт можно отдавать пользователям.
Но вы можете это упорно отрицать. Забыть о том, что перед каждым выпуском продукта по сути есть "бесполезный" отчет о тестировании "без багов", потому что без такого отчета нормальная компания просто не выпускает продукт в прод.
А ведь бывает и так, что отчет о тестировании с багами, и все эти баги уходят в прод как "известные проблемы". Т.е. по сути качество продукта не изменилось, но конечные пользователи получают информацию об ограничениях. И учитывают эти ограничения.
С сисадмином тоже все просто - работает или он, или система. Так что ваши домыслы мимо.
Насчет тестирования, немного копипасты:
— Кстати о качестве. Вот мы доподлинно знаем, что наши программисты пишут хороший код, — гордо сказала Молли, подходя к огромной красной надписи на дальней стене комнаты.
Надпись гласила: Ровно 14!
— Четырнадцать чего? — удивился мистер Томпкинс.
— Четырнадцать проверок кода без единой ошибки, — Молли прямо светилась от радости.
— Это впечатляет, — пробормотал мистер Томпкинс. — Я полагаю, мы вполне могли бы сэкономить те сорок два человекочаса, которые были затрачены на эти проверки кода, а на качестве продукта это никак бы не отразилось. Ведь ошибок все равно не было.
— Думаю, ты ошибаешься, — несколько раздраженно ответила Молли. — Именно благодаря проверке кода мы добились такого высокого качества работы.
— Только не благодаря последним четырнадцати, верно? Без них вполне можно было бы обойтись.
Отличная статья, спасибо. Одну цитату отправил в рабочий чат)
Мы же всё протестировали, или откуда берутся баги на проде (часть 1)