Зачем тестировщику SQL?
=========================

 В последнее время все чаще в списках вакансий для тестировщиков пишут: «Знание SQL» или «SQL на уровне понимания элементарных запросов». Зачем тестировщику SQL?  

Я спрашивала у знакомых тестировщиков, недавно изучивших SQL: «Зачем?». Ответы были примерно: «потому что надо», «знакомый опытный тестер посоветовал», «лишним не будет».   

Так надо ли это? Может, проще написать в гуглдоке пару запросов и потом копипастить куда надо?   

  

ЗЫ. Я не из праздного интереса — почитаю ответы и заодно статистику соберу :) Заранее спасибо всем ответившим :) 

 Чтобы дать разработчикам более понятную обратную связь. Не «вот эта красная кнопочка не делает то, что должна делать», а «у вас ошибка в запросе XXX». 

 А как насчет SQL иньекций? Довольно таки попурярная ошибка. 

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

 Тестировщикам частенько приходится **писать** автоматические тесты, и результаты тестов, разумнее всего, именно, напрямую в базу данных сливать, чтобы другие разработчики (программисты/отладчики) не собирали кучу файлов-логов по всем компам (за которыми сидят тестеры), а брали выборку сразу из этой базы.  

Конечно же можно самих программистов попросить написать нужную штуку для тестировщика, избавляя его тем самым от необходимости изучать **SQL**, но с точки зрения бизнеса, всякий раз при написании очередного теста отвлекать программистов от основной задачи, либо вбухивать кучу средств на разработку одной универсальной на все случаи жизни системы тестирования — крайне неоправданно. 

 Например, чтобы забить базу тестовыми данными.  

  

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

 Так как конкретно тут уже поотвечали, я позволю себе обобщить ваш вопрос: нужно ли тестировщику знать, как разработан продукт, который он тестирует?  

  

Соответственно, тут возможны два варианта:  

1. Обычный тестер, чёрный ящик, нажимаем кнопки.  

2. Необычный тестер, серый-белый ящик, мочим по полной — автотесты, автоматический анализ кода, анализ покрытия кода, генерация тестовых данных и так далее.  

  

Во втором варианте, очевидно, чем больше знаний, тем лучше.  

  

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

  

Тестер начинает думать: «Ох, как тут омерзительно выглядят шрифты… Ну, это же .NET с его сглаживанием, ничего не поделаешь» — и не заводит тикет. Между тем, это проблема менеджера и разработчика — выбор конкретного фреймворка; а ошибку лучше рассматривать исходя из ожиданий конечного потребителя продукта. Его не волнует, какая там была использована библиотека и с какой целью, его волнует, почему всё так тормозит и убого выглядит.  

  

Отсюда и полуанекдотичные случаи, когда женщина-бухгалтер лет 50 умеет разнести в клочья программу, которую до этого проверял профессионал и ничего не нашёл — потому что профессионал, сочувствуя (и программисту, он же понимает, каких трудов стоило накодить эту красивую кнопку, и написанному им продукту, жаль же!), не нажимает на кнопку, пока бедная программка не «прокашляется». А вот у бухгалтера такого ограничения нет. 

 Что-то все ходят вокруг да около. Правильный ответ такой:  

  

Знание SQL нужно тестировщику для написания автоматизированных модульных тестов, проверяющих правильность работы тех вызовов программы, которые работают с базой данных.  

  

Например, в программе есть функция «записать в базу данные пользователя». Как проверить, что функция работает правильно? Очевидно, нужно вызвать эту функцию, а затем посмотреть — тот ли получился результат, который ожидался?  

  

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

 Чтобы тестировщик был в состоянии забить таблицы в базе тестовыми данными, в особенности для построения отчётности. Чтобы мог справиться с локализацией в БД. Есть вообще специфичные тестировщики, тестирующие приложения БД и Data Warehouses, но скорее всего не Ваш случай.  

  

Ну и при любом не-ручном тестировании (а такого сейчас всё больше — приложения растут по сложности), SQL — ежедневный инструмент. 

 Тут проще описать на примере задачи. К примеру, программисту необходимо сделать программку, которая парсит экселевский файл, записывает из него данные в БД, а потом это где-то выводится на сайте. Разработка разбивается таким образом, что сначала идет парс, а потом создание интерфейса. Так вот для того, чтобы проверить корректность работы парсера, и соответственн данных в БД, на этапе отсутствия интерфейса, тестировщику просто необходимо знание SQL. 

 Один мой знакомый как-то сказал? что на самом деле существует только три языка: английский, С и SQL. 

 Всем привет! Можно дополнить вопрос, с позиции человека только начинающего изучать автоматизацию?  

Подскажите какой наиболее часто используемый SQL и какую литературу выбрать, что бы вникнуть в БД?