August 21, 2014 at 7:22 am
True, but then the developer has to go back and fix it when it fails instead of building it in as they go. I'd absolutely have performance tests, but still would require they work against a fully populated database. I can tell you that 100% of the time we've done this in my past, we have had zero scalability issues and better architecture as a result.
In the end, the only person that can make a quality product is the developer, everything else, Specs, unit tests, SIT, SAT, UAT, etc. only serve to help make sure that that quality is there. The farther you move away from the developer, the more expensive the feedback loop to get it fixed. The key to the most efficient development is understanding and driving towards this. This is why unit tests integrated into the build environment are a very good thing.
But all too often, regardless of process, it's attitude that is the major driving factor. It's critical to make sure developers understand this and don't get the 'chuck it over the wall' mentality. As a development manager, I once received an e-mail from a dev team lead that was multiple paragraphs long blasting the QA group because they were repeatedly rejecting builds due to failing an acceptance test. The last line of the e-mail was 'it didn't work, there's a bug we're fixing now'. Classic.
August 21, 2014 at 7:29 am
The Fault (8/21/2014)
This is all "perfect world" stuff, but we don't live in a perfect world. Project managers and stakeholders simply won't accept or sanction delays of a few weeks let alone months for extra testing, even if they do understand the benefits. The software is delivered, the project wraps up and the bug riddled software starts the long process of being fixed issue by issue (or not in many cases). The next project starts up and so the cycle continues.
I totally disagree. From experience.
My last project decided to go with the TDD model and also do more formal testing before it got to UAT (User Acceptance Testing). The project was delivered through UAT quicker than any project before it. Users were happy. Stakeholders were happy. PMs were happy. IT teams were more satisfied with what they had delivered (happy will always be a stretch too far).
Were there any defects? Yes. But far fewer and of far less of a consequence.
Did it cost more? Arguably not. The thinking was that it cost more to get it to UAT but much less to get through it and was cost neutral to deliver the system into production and with a higher level of quality.
Management recognised the success and has committed to continue to support the initiative moving forward.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 21, 2014 at 7:33 am
wayne.jared (8/21/2014)
But all too often, regardless of process, it's attitude that is the major driving factor. It's critical to make sure developers understand this and don't get the 'chuck it over the wall' mentality. As a development manager, I once received an e-mail from a dev team lead that was multiple paragraphs long blasting the QA group because they were repeatedly rejecting builds due to failing an acceptance test. The last line of the e-mail was 'it didn't work, there's a bug we're fixing now'. Classic.
Where exactly was he leading his team? Absolutely amazing.
You are totally right about attitude. The team with the right attitude is most likely to perform the best regardless of tooling, processes, etc.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 21, 2014 at 7:38 am
I guess the point I was trying to get across is that often developers are set up for failure. After all, contract bid wins are based on cost and speed of delivery, not quality of build. Extra testing goes against these factors right from the off.
August 21, 2014 at 7:40 am
Out the door, he didn't last long....
August 21, 2014 at 7:54 am
If sufficient functional requirements are not provided upfront, then all these "fixes" in production are really just change requests and phase I, II, ~ deployments. A solution that has been in production for months shouldn't be considered "broken" just because someone wakes up one morning and decides it should be working in a different way.
Really, software or database requirements documentation should include test plans with specific screen/report mockups, data inputs, and data outputs that can be unit tested by the programmer during the initial development phase and then reproduced and validated by QA.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 21, 2014 at 8:30 am
Totally irrelevant to the discussion, but for some reason, when I first glanced at the title, I read Booze Age Development instead of Bronze Age Development.
August 21, 2014 at 8:31 am
I've worked with a lot of developers who think they shouldn't have to test. That's QA's job. Their results show it.
My tendency is to believe I have mistakes in my code and I want to find them before QA does.
August 21, 2014 at 8:38 am
blah12345 83778 (8/20/2014)
I think the term bronze age development really does sum up writing t-SQL, there are some tools which are starting to emerge and get better but the tooling is a long way behind that of c# or other languages.A big issue for me is debugging, with SQL server you can step into a stored procedure but can't see the contents of a table, want to check the results of a cte?? Add an additional select and run the cte twice in your procedure!
I so wish debugging support had been improved over the years.
August 21, 2014 at 8:40 am
kiwood (8/21/2014)
Lets just say that the developer may have said no bugs, but his users didn't. (Unless they "tested" using production data.) The other thing this tells me is that the developer made some forms that look just like the paper he was replacing.
I asked about this. The users reported no bugs the first week things were being used.
August 21, 2014 at 8:42 am
The Fault (8/21/2014)
This is all "perfect world" stuff, but we don't live in a perfect world. Project managers and stakeholders simply won't accept or sanction delays of a few weeks let alone months for extra testing, even if they do understand the benefits. The software is delivered, the project wraps up and the bug riddled software starts the long process of being fixed issue by issue (or not in many cases). The next project starts up and so the cycle continues.
Except the idea is that testing should be alongside and with development, not after.
August 21, 2014 at 8:43 am
marcia.j.wilson (8/21/2014)
Totally irrelevant to the discussion, but for some reason, when I first glanced at the title, I read Booze Age Development instead of Bronze Age Development.
Long week? :w00t:
August 21, 2014 at 8:45 am
Steve Jones - SSC Editor (8/21/2014)
marcia.j.wilson (8/21/2014)
Totally irrelevant to the discussion, but for some reason, when I first glanced at the title, I read Booze Age Development instead of Bronze Age Development.Long week? :w00t:
Made me laugh. No, probably just trying to scan too quickly.
August 21, 2014 at 9:39 am
Steve Jones wrote:
The consultant who gave the presentation believes strongly in testing, not only at the application level, but also at the database level. This person has tried different levels of testing on different projects, and found that building and writing tests throughout development results in many fewer issues at release.
To me, this seems to be one of those 'no sh*t, Sherlock' revelations. I've being preaching and practising the same philosophy for decades.
But it's amazing how many development shops still don't get it.
August 21, 2014 at 10:08 am
blah12345 83778 (8/20/2014)
I think the term bronze age development really does sum up writing t-SQL, there are some tools which are starting to emerge and get better but the tooling is a long way behind that of c# or other languages.A big issue for me is debugging, with SQL server you can step into a stored procedure but can't see the contents of a table, want to check the results of a cte?? Add an additional select and run the cte twice in your procedure!
Like! Vote Up! 1+ Whatever it takes to indicate that I completely agree with you!!
Rod
Viewing 15 posts - 16 through 30 (of 38 total)
You must be logged in to reply to this topic. Login to reply