Tag Info

For the most part, I've gotten by with running simple SELECT queries with various WHERE filters. With my current position, though, I'm finding that adding more complex JOINs are necessary to really get what I need out of the database. I think you are answering your own question here. Basically - "it depends". Sometimes the position requires just a ...

Like Sam points out experience with SQL and/or with MySQL will greatly depend on the project and/or the company with whom you hope to work. SQL skills are one aspect of Software Testing that focuses specially on technology. James Bach, an expert in the field of Software Testing with 20+ years experience, published a Tester's Syllabus for those who are ...

Another approach that might help with the portability is to run you SQL from an application test harness. If you use the SQL inline with this you have the ability to take the exe to any installation and just run it. To expand on using a testing framework there are several really good articles on Simple Talk about Unit testing sql code. They are good ...

If you only need rough precision, the dump method is crude but does get the job done. If you want a lot of precision, I have done a similar task using Python's SQLite module. (http://docs.python.org/library/sqlite3.html) I grabbed and directly compared alike rows in each table and wrote out changes to a file, with further post-comparison and UPDATEs ...

SQL is specific to the project you're working on. Knowledge of SQL may or may not be applicable to a SQA position. I would say there are probably more SQA positions than not that don't have that requirement. The most important thing for an SQA position is logical problem solving skills. Especially for entry level SQA positions most of the focus will be ...

Proficiency in SQL is just a start, there is something more that just being competent with the SQL syntax: Select, From, Join, Where, Order by, etc. A good Software tester in a job requiring DB skills needs to be willing to learn from the Developers and DBAs in the shop. The tester should want to refine and improve their DB data mining skill continuously. ...

If I am looking for a tester for either a database or for a heavily data driven application then the stronger they are with SQL the better. I think not only should they be comfortable with writing queries including JOINS, UNIONS etc, but they need to have a good understanding of what some of the different performance implications are around inserts and ...

If you work in a company using intensively with SQL databases, like in enterprise systems or online shops, you will very likely need at least basic skills in SQL, at least to create some test data in the database, to check results and so on. At least some DML knowledge, SELECT, INSERT, UPDATE, DELETE, will come handy sooner or later. But keep in mind it's ...

Turns out this was easily done using the LINKS table - here's an example of query to retrieve all the RUNS a bug is associated with: SELECT DISTINCT LN_BUG_ID as BugId, LN_ENTITY_ID AS EntityId FROM td.LINK WHERE LN_ENTITY_TYPE = 'RUN' UNION SELECT LN_BUG_ID, ST_RUN_ID FROM td.LINK INNER JOIN td.STEP ON LINK.LN_ENTITY_ID = STEP.ST_ID WHERE LN_ENTITY_TYPE = ...

Visual Studio 2010 has some built in tools for unit testing SQL server. This article is a good read: http://blogs.msdn.com/b/atverma/archive/2010/07/28/how-to-unit-test-sql-server-2008-database-using-visual-studio-2010.aspx I know that Red-Gate also has some good tools for testing SQL server, especially around comparing tables or results of queries from ...

RedGate offers a suite of tools to help with DB comparisons: http://www.red-gate.com/products/sql-development/sql-compare/ There is a tool to compare schemas from different DB's as well as a tool to compare the data from tables or from the result of a query. We use the data compare tool every time we update our database to ensure that queries often done by ...

Srihari... I'm also relatively new to QC. With regard to querying the QC DB, mostly I retrieve BUG data, and learned primarily through trial and error in the Dashboard module. Initially, I didn't know which columns to include so I just did a query to select * from BUG where bg_bug_id = <some bug ID I had logged> Essentially, my base query on BUG is ...