Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Test Coverage Expand / Collapse
Author
Message
Posted Tuesday, November 12, 2013 11:55 AM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Friday, October 24, 2014 12:43 PM
Points: 4,126, Visits: 3,428
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.)
Post #1513580
Posted Tuesday, November 12, 2013 12:23 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 7:28 AM
Points: 7,179, Visits: 15,775
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?
Post #1513592
Posted Tuesday, November 12, 2013 7:11 PM


SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Tuesday, September 23, 2014 7:42 PM
Points: 635, Visits: 2,215
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.
Post #1513687
Posted Wednesday, November 13, 2013 4:13 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Thursday, December 11, 2014 5:47 AM
Points: 68, Visits: 452
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.
Post #1513791
Posted Wednesday, November 13, 2013 4:20 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 11:58 AM
Points: 5,819, Visits: 3,739
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!!!
Post #1513795
Posted Thursday, November 14, 2013 2:42 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 6:20 AM
Points: 2,923, Visits: 1,874
There is a very definite skill in writing a suite of useful tests. You can't approach it as a "check the box" exercise.

Automated testing allows a huge range of repeatable tests to be applied quickly. My first engagement with a professional tester was a humbling experience. I take pride in my work and do put a lot of effort into my code but the tester found gaps I simply hadn't thought of.

The thing is that over time the knowledge of what is required for testing is absorbed and results in a more rich set of automated tests.

I see UAT as separate to QA. UAT should be about the useability of a system rather than a "flush out the bugs".


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1514189
Posted Thursday, November 14, 2013 3:20 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 11:58 AM
Points: 5,819, Visits: 3,739
David.Poole (11/14/2013)
...I see UAT as separate to QA. UAT should be about the useability of a system rather than a "flush out the bugs".


I agree but feel that the reality is that other defects will be noted due to occurrences of such things as missed or misunderstood requirements.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1514200
Posted Thursday, November 14, 2013 4:12 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 6:20 AM
Points: 2,923, Visits: 1,874
Gary Varga (11/14/2013)

I agree but feel that the reality is that other defects will be noted due to occurrences of such things as missed or misunderstood requirements.


NSR = None Stated Requirements


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1514523
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse