November 11, 2013 at 8:49 pm
Comments posted to this topic are about the item Test Coverage
November 12, 2013 at 2:56 am
Due to the overall poor support for unit testing for SQL Server (and I have found it to be the same for Oracle) often the Data Access Layer (DAL) unit tests are used to unit test the stored procedures (SPs). This breaks the principle of unit testing a single unit, however, it is a pragmatic approach as the DAL is so tightly coupled to the SPs anyway.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 12, 2013 at 5:34 am
The link to http://tsqlt.org/ is not working for me.
November 12, 2013 at 6:05 am
netmikem (11/12/2013)
The link to http://tsqlt.org/ is not working for me.
The link works fine for me. In what way is it not working? What are you browsing on/with/via?
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 12, 2013 at 6:11 am
Odd, it is fine now. Seems to have been a transient issue. Thanks.
November 12, 2013 at 7:24 am
I'll typically place a few unit test examples in the comment block of each stored procedure I write. Sometimes I'll use SQLProfiler to cature sample procedure calls while the QA tests the application, and then save that off as a script for unit testing, mostly just as a smoke test to make sure I havn't broken any dependencies whenever I make a change to a procedure, view, or table.
Also, whenever I make a change to a stored procedure that returns a result, if the result is not expected to change, perhaps something like a performance optimization, then I'll save a before and after text copy of results into a comparison tool like WinMerge and comfirm nothing unexpected like sort order, doubling up of rows, or NULL columns has changed.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 12, 2013 at 8:20 am
From the article:
These days most testing of software is automated.
Oddly enough, I believe that's part of the problem with delivered software, today. There's nothing like a human using the software as the ultimate test because that's the ultimate goal. I've also found that, except for certain types of load testing software, most automated software doesn't even consider performance and a lot of people don't set the test software up for "negative path" testing.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2013 at 8:43 am
Jeff Moden (11/12/2013)
From the article:
These days most testing of software is automated.Oddly enough, I believe that's part of the problem with delivered software, today. There's nothing like a human using the software as the ultimate test because that's the ultimate goal. I've also found that, except for certain types of load testing software, most automated software doesn't even consider performance and a lot of people don't set the test software up for "negative path" testing.
I agree.
The best scenario is for automated testing by the developers, automated testing by the test team, manual script testing by test team where automation difficult or impossible, manual exploratory testing by test team and finally UAT testing by users.
Also, penetration testing, performance testing, integration testing, disaster recovery testing and usability/user experience (UX) testing.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 12, 2013 at 9:28 am
Jeff Moden (11/12/2013)
From the article:
These days most testing of software is automated.Oddly enough, I believe that's part of the problem with delivered software, today. There's nothing like a human using the software as the ultimate test because that's the ultimate goal. I've also found that, except for certain types of load testing software, most automated software doesn't even consider performance and a lot of people don't set the test software up for "negative path" testing.
I agree. It takes something special to be a good QA person, and most developers (I include myself) don't have it. Also, while the *Unit test frameworks work well for unit tests, they are still unit test. I believe that QA groups are still needed for the larger integration efforts. I haven't read or heard anything about the test matrix for the new healthcare market place, but I can make some guesses about what it looked like prior to the opening, and how much larger it will be in a couple of months.
November 12, 2013 at 9:43 am
Tom Bakerman (11/12/2013)
Jeff Moden (11/12/2013)
From the article:
These days most testing of software is automated.Oddly enough, I believe that's part of the problem with delivered software, today. There's nothing like a human using the software as the ultimate test because that's the ultimate goal. I've also found that, except for certain types of load testing software, most automated software doesn't even consider performance and a lot of people don't set the test software up for "negative path" testing.
I agree. It takes something special to be a good QA person, and most developers (I include myself) don't have it. Also, while the *Unit test frameworks work well for unit tests, they are still unit test. I believe that QA groups are still needed for the larger integration efforts. I haven't read or heard anything about the test matrix for the new healthcare market place, but I can make some guesses about what it looked like prior to the opening, and how much larger it will be in a couple of months.
QA needs to be performed by a dedicated "QA engineer" using a formalized process and test plan. Simply asking the business analyst, a stake holder, or an intern to famliarize themselves with the requirements documents and then sit down and "poke around" with the application doesn't cut it.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
November 12, 2013 at 11:55 am
However more and more testing is being pushed back onto developers to handle, with frameworks like NUnit and JUnit.
I would say that as testing tools are easier and easier to use, developers are expected to do more unit testing. I am expected to have a test class for each sproc, with number of methods generally depending on the number of parameters.
That, however, does not mean that QA will not do their own testing without looking at what I tested and how. (After a while, they do not have to look anyway because they know me and they know how I go about things.)
November 12, 2013 at 12:23 pm
Eric M Russell (11/12/2013)
Tom Bakerman (11/12/2013)
Jeff Moden (11/12/2013)
From the article:
These days most testing of software is automated.Oddly enough, I believe that's part of the problem with delivered software, today. There's nothing like a human using the software as the ultimate test because that's the ultimate goal. I've also found that, except for certain types of load testing software, most automated software doesn't even consider performance and a lot of people don't set the test software up for "negative path" testing.
I agree. It takes something special to be a good QA person, and most developers (I include myself) don't have it. Also, while the *Unit test frameworks work well for unit tests, they are still unit test. I believe that QA groups are still needed for the larger integration efforts. I haven't read or heard anything about the test matrix for the new healthcare market place, but I can make some guesses about what it looked like prior to the opening, and how much larger it will be in a couple of months.
QA needs to be performed by a dedicated "QA engineer" using a formalized process and test plan. Simply asking the business analyst, a stake holder, or an intern to famliarize themselves with the requirements documents and then sit down and "poke around" with the application doesn't cut it.
No - "poking around" won't cut it. Test coverage of code and test coverage of scenarios require quantitative analysis to determine progress.
That said - a BA worth their salt should be able to take the requirements documentation, create a basic Ishikawa diagram of common failures, and document happy and sad paths to test. A QA engineer might be skilled in knowing how to CODE said tests into testing suite, but they would have to do the very same analysis to determine which tests to run if a BA was not involved.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
November 12, 2013 at 7:11 pm
Revenant (11/12/2013)
I would say that as testing tools are easier and easier to use, developers are expected to do more unit testing. I am expected to have a test class for each sproc, with number of methods generally depending on the number of parameters.That, however, does not mean that QA will not do their own testing without looking at what I tested and how. (After a while, they do not have to look anyway because they know me and they know how I go about things.)
The problem is that the DBA developer will work with the parameters given in the spec, using the old subset of the DB that they are allowed to use for testing.
They won't know that the end date is optional or what the limiting scopes will be. So then it goes to production and times out or fails. But they didn't do "sufficient testing" because they designed to the specs.
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.
November 13, 2013 at 4:13 am
Unlike testing applications, where failure is an common sign of some flaws in the code, testing database facilities like stored procedures, user defined functions, views and queries is much harder, because most of the time the result of a code flaw will not be a complete failure but just a little inconsistency in the results. For example, when using an INNER JOIN instead of a LEFT OUTER JOIN to list people with their skills, it might go easily unnoticed that you are missing someone without any registered skill, especially if nearly all of them do have registered skills. Even harder to track down are the small errors introduced in the values of SUMs or COUNTs when someone overlooked the sometimes unexpected behavior of NULLable columnsin JOIN and WHERE clauses.
As a long time developer and DBA, in my humble opinion testing a piece of code should not be the responsibility of the one that implements the feature. No matter how hard you try, you will always have some 'blind spots' and miss some edge cases that someone else will come up with. However, in most smaller organizations the DBA has no colleague to test and review his work, making it even harder to maintain the required code quality standards. I do agree that every part of the application should be tested both separately and in conjunction with other parts. But that is not always feasible without the contribution of testers with other skills then an average developer has in his suitcase.
November 13, 2013 at 4:20 am
vliet (11/13/2013)
...For example, when using an INNER JOIN instead of a LEFT OUTER JOIN to list people with their skills, it might go easily unnoticed that you are missing someone without any registered skill, especially if nearly all of them do have registered skills. Even harder to track down are the small errors introduced in the values of SUMs or COUNTs when someone overlooked the sometimes unexpected behavior of NULLable columnsin JOIN and WHERE clauses...
Totally disagree. These are valid test cases that should be considered by the developer. These are similar types of scenarios to division by zero, null references, empty collections etc. They even have a term (or two): Edge Cases/Boundary Testing etc.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 15 posts - 1 through 15 (of 22 total)
You must be logged in to reply to this topic. Login to reply