|
Need a review when you're done.
In 35 years, I've not yet worked in a shop that actually had deliberate testing. Sure, as the developer, you do (at least it's what I hold myself to) have a resp. to see that the code does basically what it's supposed to do. We only joke about "it compiled and linked, should be good".
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
Me: can you provide instructions on how to test your code?
Current Co-worker: I can't think in that kind of mind set.
Me: 
co-worker also refuses to answer most emails - they don't want to be pinned to a paper trail. It really sucks on so many levels.
|
|
|
|
|
umjaco69 wrote: Current Co-worker: I can't think in that kind of mind set.
Riiiiiiiiight. S/he can't think in that mindest. Whatevs!! Doesn't want to think, more like.
|
|
|
|
|
The next two words out of Dev's Boss' mouth should be: 1) "You're" and 2) should start with a "f" and end with an "ed".
|
|
|
|
|
Right on!!
|
|
|
|
|
Gives you a whole new perspective on driverless car software huh?
Speed: 60 kph
Terrain: mountain road on a bridge over a chasm
Altitude: 2000 meters above sea level
Forward Sensors: 5 workers on the road 10 meters ahead
Reverse Sensors: tractor trailer approaching at 65 kph 20 meters back
Plow into the workers (5 killed)?
Veer off the bridge? (1 killed: passenger)?
Things that make you go hmmmmmm.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
An interesting perspective.
|
|
|
|
|
It's about the environment. Having someone leave after 2 days is preferable.
When I was 19, my first full-time position was working with Insurance Calculations for Premiums.
Finding out that I COULD BE FINED for errors in my calculations CHANGED me for the better. I would add diagnostic output to the current code (based on a setting)... And it allowed me to see the internals of ANY Premium Calculation change.
The worse part was the ratings books were always being updated, and our #1 change was to the ratings system that adjusted "some" premiums.
So, I would make my changes, capture last nights run. Restore/rerun using my new calculation, and DIFF the 2 sets of data. Highlight, and MAKE MANAGEMENT sign off that the new calcs were good, and nothing else was affected...
From those days forward. Having some semblance of testable code (at least unit tests) was key. And my biggest goofs were thinking something was such an OBVIOUSLY SIMPLE solution that it did NOT need any "coverage" testing...
|
|
|
|
|
Thanks for adding to the conversation.
Kirk 10389821 wrote: my biggest goofs were thinking something was such an OBVIOUSLY SIMPLE solution that it did NOT need any "coverage" testing...
So true. I've found that often to be true also.
this whole dev-testing thing is really about the mentality you bring to the coding game.
And then, there are tools & methods that can help make it all are part of the process.
A good book that makes you contemplate the entire dev life cycle. I'm enjoying the book.
|
|
|
|
|
Over a 35-year career, I have worked in two shops where they did good unit tests. And these tests caught practically all bugs. Integrations were a breeze. Merging changes, no problems.
Both these shops had psychopathic managers that made life a horror. One was a startup that burned brightly for a year and went dark. The other was a zero-documentation, high tech debt nightmare.
My conclusion is that a conservation law may be at work limiting the amount of goodness in any workplace. I am still working on an experiment to reveal the exact nature of this fundamental law.
|
|
|
|
|
Great post. Very interesting.
And you may be right, no work place can probably be good for a long period of time as measured by numerous factors.
Too bad. Things degrade. 
|
|
|
|
|
I don't tend to write test cases; I write industrial automation code and to try to write tests for every possible interaction with the I/O would be a nightmare, so I do simulations with virtual and physical (dummy) hardware in my office. it's easier to simulate real time issues and faults with switches, knobs and various sensors. This finds 99% of all issues before they go out to the field, then on-site startups tend to find the remaining 1% of the edge cases.
As the sole programmer and tester (and installer, and trainer) for a decent sized company I have to manage my time very carefully. And yes I have to go to each facility for startups; way too much traveling.
|
|
|
|
|
...and this is the way any and every business should run. Nothing will ever be perfect in this new world of complexity. Wait until self driving cars start running into things..oh and they will!
|
|
|
|
|
Sounds like really interesting work.
and, that sounds like a developer-test based framework which is founded upon you being the sole owner (of the work) which drives great results. Ownership is a big part of getting to good product quality, I think.
|
|
|
|
|
I've owned business, managed, sold those and written code. There is a fine line between releasing perfect code and missing a window of opportunity. So many developers forget that they are employed because their software solves a problem and when it fails to solve something they look back and ask "Why did I get laid off?" I've found the trick to fixing bugs (and you all have them, and if you don't wait 5 minutes and you will) is to be nimble and fixing them quickly. 6 Month releases are a joke and cause users to struggle through potential nightmares and are ONLY around to justify QA groups and terrible managers. Some applications require test procedures which are always evolving and NEVER will be perfect because applications and their solutions evolve rapidly. If a developer is always being pushed for features and has little time to drive the entire application through it's paces I could see how someone would respond, "have someone test the product". There is always two sides to a story and if both aren't heard and weighed well that's crappy management or a market that demands it faster than you can deliver. You think Facebook was perfect the first release or even the second?
|
|
|
|
|
I agree with this 100%.
The most important thing is :
working code
That does not mean you wait to ship until everything is perfect.
It means you focus on MVP (Minimum Viable Product).
Your point also goes to a point that I like to make about Product Ownership.
I think it drives quality if a dev feels ownerhship.
I have created numerous projects that I am the requirements gatherer, system analyst, developer, tester and deployer. I own it 100%.
You can see the app I created this way on multiple platforms:
Swift (iOS) app in app store : CYaPass on the App Store[^]
Android app in Google Play ==> CYaPass in Google Play[^]
As a windows winform app: ==> C'YaPass: Forget All Your Passwords | Get C'YaPass[^]
and even as a JavaScript, HTML5, Canvas app -- no install required, try it in your browser:
C'YaPass: Forget All Your Passwords | WebApp[^]
Iterative Dev
I had a few bugs in my initial release of winform app and I fixed them in iterations.
Same thing with the SPA (single page app) version. There are probably still some bugs in there, but you can get the app on every platform and that is what is important.
Great discussion.
|
|
|
|
|
There are many types of tests, but most fall into one of two categories: unit and system.
The intent of unit tests is to establish that the low level functionality works as expected. They are also essential when refactoring and/or extending code. (I personally also find them very helpful in a) understanding code and b) improving the API.)
The intent of System tests is to show that the software DOESN'T work. This distinction is critical and is why system, or final, testing should not be done by developers and should be separate from engineering. It's also why automated testing only goes so far.
Over my career, I've had several brilliant testers. They challenged my software in ways I hadn't thought of. Even better, when they submitted a bug report, it was reproducible. In general, they also understood customer requirements better than the developers. (Another largely untapped resource by many developers and designers is support. When customers consistently complain about something, maybe it's time to change it.)
|
|
|
|
|
Great post, thanks for adding to the conversation.
When I was in QA I always:
1. Insured I could reproduce the bug
2. Provided the exact steps to reproduce the bug (along with pertinent system details - browser info etc) in the bug report.
Now that I'm a dev I cannot stand to receive a bug report that says something like:
"I clicked on the button and the thing didn't work."
Argh!!! Which button? What thing?  What does didn't work mean?
|
|
|
|
|
My first job (Programmer Trainee) was at an investment company. For any new project:
1) We first wrote "Input Edits".
2) But here a separate department of accountants started trying to break the edits, while..
3) We started writing master file loads
4) As the accountants get "valid" data through the new edits, the new file loads create "test" master files
5) In the meantime, we are now writing file compares.
6) As the test masters are being created, the master file maintenance programs are being written
7) Once the test masters are built, a target master is created and updated by the new input edits and master file maintenance.
8) At the same time, the file compares started running, feeding results back to the accountants that either
9) Add new cases to the test masters
10) Created new transactions for the parallel system
11) etc.
Now I just say to give me a copy of their database.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Pendulum - Still Grey[^]
An old favorite. Heard it again when I put my music on shuffle.
This song is from Pendulum's debut album, but only the sold-out first pressing. They've replaced it with an inferior song (by definition) on subsequent pressings. Luckily we still have internet.
Probably the most relaxing drum n bass I've ever heard 
|
|
|
|
|
Great ... note taken
|
|
|
|
|
I'm back in the UK now, after 5 months in Africa North. Mrs Wife and our children returned this morning to leave me here to do a few small jobs - get a job, find a house, enroll the girls in school for September.
Easy life I reckon.
ps. The 20°C temperature drop has really done my joints the world of good*.
* None what so ever.
veni bibi saltavi
|
|
|
|
|
Gee, you've been gone?
Welcome back.
Mongo: Mongo only pawn... in game of life.
|
|
|
|
|
didn't know Hungary was in North Africa ?
I'd rather be phishing!
|
|
|
|
|
Not even close. We have a home in Hungary but only spend the summers there now; after being there the week before Christmas.
veni bibi saltavi
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
