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 «««1234

Less QA? Expand / Collapse
Author
Message
Posted Wednesday, July 31, 2013 9:12 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Yesterday @ 3:36 PM
Points: 35,531, Visits: 32,114
sue.james (7/31/2013)
Let's all back up a minute and think about the true source of the problem .... poorly written specifications (if the developer even got one at all). When more emphasis is placed on requirements gathering and the development of a specification with use case scenarios and process flow charts, the end product is not only better, but there is less project/scope creep as well. A well written specification not only provides the business rules to the developer, it also guides the QA staff in the development of a testing plan. Wait, did I say testing plan? Yes, I certainly did. How many QA staff out there actually develop one for a major project so that they don't forget to test anything? This one certainly does!


+1 BILLION and 46 thumbs up!


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1479777
Posted Thursday, August 1, 2013 12:07 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Thursday, December 5, 2013 10:45 PM
Points: 20, Visits: 72
You spelt develop "develope", normally I wouldn’t say anything but in an article on testing, it's a bit funny.
Post #1479793
Posted Thursday, August 1, 2013 7:23 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, November 3, 2014 1:06 PM
Points: 7, Visits: 88
Software testers likely don't see testing as something to take pride in because they likely aren't sure if they've ever hit the mark. How are managers helping those who test understand what makes a good test plan?

My experience in the software development life cycle is that often, managers have no idea how the products work that their people work on. Most of the time, managers don't even know what kinds of technologies are involved in their product's stack or code libraries. Moreover, the things that make people tech minded people interested in their job I've found can often times be exactly opposite to what makes a manager type interested in their job. So by definition, it's often hard for the two to relate to one another on an interpersonal communication level. But most importantly. because of that large chasm of interest, managers usually have no way to help a QA tester know whether they are doing a good job. They likely aren't setting the bar for someone to shoot for. Human beings, by their very nature, like to measure themselves. Without knowing what makes "good quality tester" I can see why they aren't likely to take pride in their work.
Post #1479939
Posted Thursday, August 1, 2013 10:17 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 3:03 PM
Points: 31,276, Visits: 15,728
PhilipC (7/31/2013)


Yeah that's a fair enough point. Most of time, it seems to be rapid development over quality development that wins out. As a DBA, it just becomes a nightmare trying to support these kind of databases and maintain some kind of performance level when the vendors show very little interest in improving things.


I've had good luck working with support people if I show them my tests, results ,and recommendations for indexes or FKs. FKs are hard because sometimes their data models are broken and explicit FKs break functionality as well as ensure things are correct, but often I've had them take indexes back to their developers, get approval for me to test them. I've even seen a couple of them make it into upgrades for patches or new versions.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1480020
Posted Thursday, August 1, 2013 4:01 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, November 17, 2014 9:18 AM
Points: 2,912, Visits: 1,841
Vendor DBs tend to aim at multiple platforms and this boils down to lowest common denominator design.

If the product states that MySQL is supported expect heap tables in SQL Server and no foreign keys.
Ditto check constraints and probably defaults.


LinkedIn Profile
Newbie on www.simple-talk.com
Post #1480196
Posted Tuesday, August 6, 2013 2:59 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 8:03 AM
Points: 825, Visits: 319
David.Poole (8/1/2013)
Vendor DBs tend to aim at multiple platforms and this boils down to lowest common denominator design.

If the product states that MySQL is supported expect heap tables in SQL Server and no foreign keys.
Ditto check constraints and probably defaults.


We don't have any experience of MySQL but we support multiple platforms (Windows, Solaris, AIX, Linux) and DBs (Oracle & SQLServer) in one product and we certainly don't go for the LCD. It does mean we have to have a few checks on the DB in the code to see exactly which piece of code to execute but there's no compromise in the DB design just so we can have the two DBs.

Back to the original topic, testing. I see one of the main problems as coding is like a date with <Helena Bonham-Carter><Brad Pitt><your hottie of choice> compared to testing being like taking your Mum to bingo, so it's hard to get people to approach it with a lot of enthusiasm. Couple that with a lack of management commitment to investing the resources, e.g. salary, to make testing a worthwhile career and it's easy to see why it doesn't get done with the accuracy required.
Post #1481207
« Prev Topic | Next Topic »

Add to briefcase «««1234

Permissions Expand / Collapse