Как в жизни тестировщика полезен SQL?

Кроме того, что на порядок повышает уровень его крутости? Нуууу… обычно хватает и этого аргумента ) Но если вам хочется больше аргументов БОГУ АРГУМЕНТОВ! БОЛЬШЕ ПРУФОВ К ТРОНУ ПРУФОВ! , то их есть у меня ©

Вот вам банальный, часто попадающийся пример рабочей ситуации:  долго готовили тестовые данные для воспроизведения бага, отошли на 5 минут за кофе, а кто-то другой, совершенно случайно, по незнанию, испортил плоды ваших трудов (ну, например, заархивировал вашего тестового пользователя. Без возможности восстановления). Слабо залезть в БД и там вручную поправить чужую оплошность, вернув вашего пользака из-за грани небытия?

Если да — добро пожаловать на ПОИНТ, я вас этому научу!

Ну а для особо въедливых и недоверчивых скептиков, которых не убедил предыдущий пример, я приведу еще несколько аргументных аргументов:

primo: SQL очень сильно ускоряет процесс поиска подходящих тестовых данных: представьте себе, что вам нужно расследовать жалобу одного из пользователей, и там, в графе “предусловия”, написано “взять пользователя, чей аккаунт создан в день кровавой луны, в момент, когда Юпитер находится в Сатурне. При создании аккаунта использовались кровь первенца мамонта, молочный зуб честного политика и кинжал, которым закололи Цезаря”.

Ваши дальнейшие действия:

  • Если вы не знаете SQL: лихорадочный перебор всех известных вам пользователей(это после того, как вы перестанете рвать на себе волосы, бегая кругами) в надежде, что над одним из них звезды сойдутся в нужном порядке и он вам подойдёт.
  • В обратном случае: усмешка победителя, слова “ай, да тут делов на 5 минут”, написание  соответствующего SQL-запроса, выбор любого пользователя из списка, что вернет вам БД

secundo: SQL открывает новый уровень локализации багов. Увидели, например,  что где-то не отображается информация, которая отображаться должна? Завели баг. Потом пошли в БД, посмотрели, а есть ли в ней вообще эта информация, написали об этом в комменте к багу. И радостный разработчик, которому вы сэкономили время и нервы, поставит в церкви лишнюю свечку за ваше здоровье

tertio: SQL позволяет отвечать “да, влёгкую” на вопрос “а можешь протестить новый функционал? только мы еще не добавили на UI механизм добавления информации для него”. Ситуация, кстати, основана на реальном опыте — пришел ко мне как-то разработчик и сказал, что функционал есть, UI для него есть, а вот добавлять данные через стенд еще нельзя. Пришлось лезть в БД и запросами всё это туда добавлять. Ну да, так и было — сам инфу добавил, сам всё это дело протестил. Универсальный, в общем,  солдат тестировщик

Я, конечно, могу еще долго вытаскивать случайные карты из колоды железобетонных аргументов и предъявлять их вам… Но лучше я вас этому научу 😉

Го на ПОИНТ, народ!

Роман Буданов, тренер ПОИНТ

#ятренерпоинта

http://pointschool.ru/trainers

Метки
Android (1)HR (1)kaizen (2)QA (5)sql (4)usability (2)БАГИ (1)Исследовательское тестирование (2)Истории поинт (4)Курс тестирования для начинающих (1)Мнемоники (1)Мнемоники в тестировании (1)Нина Агеева (4)ПОИНТ (21)ПРомо-вебинар (1)Роман Буданов (3)Скриншот (1)Тестирование (8)Тренер (11)Туры (1)автоматизация (1)алгоритмы (1)баг (1)безопасность (1)введение в тестирование (1)домашки (1)займемсяпоинтом (1)игры (1)идеальный мир (1)интернет (1)истории выпускников (4)как надо тестировать (2)конференция (1)котик (1)курс для начинающих тестировщиков онлайн (1)мобилки (1)мобильное тестирование (1)настройка мозгов (1)начинающий тестировщик (2)негативное тестирование (2)организация тестирования (1)персонажи (1)постановка мозгов (2)работа над ошибками (1)рабочий процесс (1)радиоСаня (1)режим разработчика (1)резюме (1)сопроводительное письмо (1)тестировани (1)тестирование usability (2)тестирование безопасности (1)тестирование мобильных приложений (1)тестировщик (4)улучшайзинг (1)ученик (2)чит лист (1)что должен делать тестировщик (1)
С 25.03 по 6.06, ОНЛАЙН Зарегистрироваться