Home

Автор: Нина Агеева, тест-менеджер компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/what_we_learn_from_mistakes_and_why_making_mistakes_is_a_good_thing/

Люди совершают ошибки. Это аксиома. Кто-то больше, кто-то – меньше; кто-то учится исключительно на своих ошибках и шишках на лбу, а кому-то достаточно чужого опыта. В своей статье я расскажу об ошибках, совершаемых в нашей индустрии, и постараюсь доказать читателю, что некоторые ошибки – это позитивный опыт.

Баг, там баг!

Однажды я заблокировала продакшн-релиз… Это вполне себе обычное дело в практике тестировщика. В том случае, когда ты работаешь недавно, блокировка релизов – дело более опытных коллег. Но что делать, если твои старшие товарищи в отпуске, а на продакшн-версию может попасть «поехавшая верстка»?

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

Хорошо, что мы не горели по срокам, и мне простили мою «маленькую революцию» (проблемы с версткой были исправлены за 20 минут, и на продакшн поставили хороший релиз). Счастью моему не было предела, и я искренне не могла понять, почему меня попросили больше так не делать: я ведь не пустила баг на продакшн! Лишь спустя какое-то время я все поняла и стала вспоминать этот опыт с улыбкой.

Большинство статей, посвященных тестированию и около-тестированию, – это так называемые истории успеха. Люди редко рассказывают про свои неудачи. Моя статья как раз и будет посвящена истории моих собственных ошибок и ошибок ребят из моих проектных команд, а также науке, извлеченной нами из этих неприятных ситуаций.

Возвратимся к истории о блокированном релизе. Уже позже, став тест-менеджером, я научилась правильно расставлять приоритеты ошибок. Да, ошибка верстки (особенно на «морде сайта») – это неприятно, но эта ошибка не была критичной, к ней привыкли наши постоянные пользователи, а главное – эта ошибка не мешала пользователям выполнять нужные им действия, не влияла на выполнение основных сценариев.

Нет тикета – нет задачи

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

Задолго до «Лаборатории качества» я работала в интернет-гипермаркете, где основным заказчиком был наш же отдел маркетинга. Как-то мы готовили промо-страницу перед каким-то праздником (8 марта или 23 февраля?) и сильно торопились (как обычно). Мне позвонил начальник отдела маркетинга и на словах объяснил, что именно он хочет видеть на странице, и какие там должны быть функционал и логика. Я сделала пару заметок в блокноте, рассказала разработчикам и своим ребятам-тестировщикам о новой задаче. Разработчики сделали страницу и передали нам. Мы протестировали новый функционал – все было здорово! Однако через пару часов мне снова позвонил начальник отдела маркетинга: он был очень недоволен, потому что мы, по его словам, «реализовали совершенно не то, что нужно, совсем не то, что он просил». Более того, он заявил, что я «единолично решила и сделала по-своему». Было обидно. Очень.

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

Правильным решением в данной ситуации было бы написание технического задания, но из-за особенностей заказчика и срочности задачи такой возможности не было. Как же можно было решить эту проблему? Довольно просто – с помощью ЧТЗ или даже банального макета, согласованного и подписанного на уровне начальника отдела маркетинга. Таким образом, ваша спина будет прикрытой, а реализация – полной и достоверной.

Всегда сохраняй ясность или сохраняй ясно

Спустя несколько лет я работала уже в другой компании, и мы с ребятами из моей проектной команды получили на тестирование технически сложное ПО: много интеграции, куча связанных таблиц, небанальная бизнес-логика. Ребята тестировали интеграцию и делали запросы в базу данных, брали за основу хранимые процедуры для того, чтобы применять свои данные в запросах. Все запросы были выданы команде аналитиками продукта, а ребята сохранили их (запросы) под какими-то странными названиями наподобие «1» и «2». К слову, нам вообще запрещалось использовать любые команды, кроме «select» (выборка данных из таблиц).

Сразу хочу отметить, что в данной ситуации это был мой недосмотр как руководителя: ну, что это за названия?! Позже, конечно, мы провели беседу с командой: с тех пор все, с чем мы работаем, сохраняется под понятными и простыми именами.

Так вот, все было хорошо до определенного момента. В день X (будем называть его так) девочка из команды как раз занималась тестированием интеграции, делала один и тот же запрос несколько раз, копировала данные, что-то искала и т.д. Был пятничный вечер, близилось окончание трудовой недели, и голова уже слабо соображала. Мария (девушка из команды) открыла свой, как она думала, рабочий запрос (а 90% этого запроса было идентично хранимой процедуре), отредактировала его и при помощи горячих клавиш запустила…. К сожалению, ей только показалось, что она открыла именно свой запрос: на самом деле это была сама хранимая процедура, которую трогать было нельзя.. (упс). В итоге одна из директорий базы данных пропала совсем, а на ее восстановление ушло около недели. Меня с ребятами спасло лишь то, что база была тестовая, и, слава Богу, мы смогли восстановить данные.

Да, мы ошиблись, но что можно вынести из этого опыта? Чему стоит научиться на примере этой истории? Конечно, во-первых, делать бэкапы! А во-вторых, всегда сохранять ясность в голове и сохранять под ясными названиями сущности, с которыми вы работаете! Но что делать, если бэкапы очень объемные, и на сервере постоянно заканчивается место? Тут следует на уровне администратора баз установить запрет на использование хранимых процедур без определенного набора пользовательских прав; права же нужно выдавать с умом.

То, к чему вы привыкли, может отличаться от того, с чем вам нужно работать

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

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

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

Заключение

Людей, которые не совершают ошибок, не существует. Наша с вами индустрия построена на ошибках: они повсюду, они нас окружают, мы на них учимся и растем. Не нужно бояться совершить ошибку (особенно если вы забэкапились) – они дают нам колоссальный опыт и знания, позволяя учесть их и не повторять в будущем!

Обсудить в форуме