July 31, 2013 at 9:12 pm
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
Change is inevitable... Change for the better is not.
August 1, 2013 at 12:07 am
You spelt develop "develope", normally I wouldn’t say anything but in an article on testing, it's a bit funny.
August 1, 2013 at 7:23 am
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.
August 1, 2013 at 10:17 am
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.
August 1, 2013 at 4:01 pm
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.
August 6, 2013 at 2:59 am
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.
May 13, 2017 at 1:37 am
Gosh this seems terribly relevant after yesterday's attack
Madame Artois
May 15, 2017 at 8:07 am
S Hodkinson - Saturday, May 13, 2017 1:37 AMGosh this seems terribly relevant after yesterday's attack
Indeed.
How One Simple Trick Just Put Out That Huge Ransomware Fire
Whoever was behind the ransomware included a feature designed to detect security tools that would fake internet access for quarantined PCs by using a single IP address to respond to any request the computer made. This is a feature of a "sandbox," where security tools test code in a contained environment on a PC. When MalwareTech registered his domain to track the botnet, the same IP address was pinged back to all infected PCs, not just sandboxed ones. "So the malware thought it was in a sandbox and killed itself. Lol," MalwareTech said. "It was meant as an anti-sandbox measure that they didn't quite think through."
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 8 posts - 31 through 37 (of 37 total)
You must be logged in to reply to this topic. Login to reply