Write test cases as if a 5 year old will do the tests.
-
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”. There should be a similar saying in regards to writing (non unit) test cases. "Always write test cases as if the person who ends up testing your software is a 5 years old without any knowledge of the software" I'm going through some test cases on a large software and the tests cases are just a description of what I need to do. In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Seriously, do you know of any good white paper on how to write good test cases ? groan.
CI/CD = Continuous Impediment/Continuous Despair
-
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”. There should be a similar saying in regards to writing (non unit) test cases. "Always write test cases as if the person who ends up testing your software is a 5 years old without any knowledge of the software" I'm going through some test cases on a large software and the tests cases are just a description of what I need to do. In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Seriously, do you know of any good white paper on how to write good test cases ? groan.
CI/CD = Continuous Impediment/Continuous Despair
Maximilien wrote:
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”.
This... this right here... is gold. :laugh:
Maximilien wrote:
In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work.
Sounds like someone who wrote those tests didn't know squat about writing tests (which is a lot of people). A unit test should never connect to a live resource. Not only is that non-deterministic, but you can't run 1,000s of tests quickly that way.
Maximilien wrote:
Seriously, do you know of any good white paper on how to write good test cases ?
Wish I could help with that buddy. For me, it was a combo of coworkers helping and trial and error with Stack Overflow Googling.
Jeremy Falcon
-
Maximilien wrote:
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”.
This... this right here... is gold. :laugh:
Maximilien wrote:
In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work.
Sounds like someone who wrote those tests didn't know squat about writing tests (which is a lot of people). A unit test should never connect to a live resource. Not only is that non-deterministic, but you can't run 1,000s of tests quickly that way.
Maximilien wrote:
Seriously, do you know of any good white paper on how to write good test cases ?
Wish I could help with that buddy. For me, it was a combo of coworkers helping and trial and error with Stack Overflow Googling.
Jeremy Falcon
we're not running unit tests; I don't know how I could integrate that in our ancient/antiquated codebase :(( We're doing functional and integration testing and acceptance testing. It's just hard to change the inertia; that's why I would need some good resources to help me suggest some changes. Thanks for the moral support.
CI/CD = Continuous Impediment/Continuous Despair
-
we're not running unit tests; I don't know how I could integrate that in our ancient/antiquated codebase :(( We're doing functional and integration testing and acceptance testing. It's just hard to change the inertia; that's why I would need some good resources to help me suggest some changes. Thanks for the moral support.
CI/CD = Continuous Impediment/Continuous Despair
Ooops. Totally missed the non-unit part. :-O If these are integration "test cases" they sound more like documentation for manual steps than anything else then. Probably could've achieved the same thing in a README. :laugh:
Jeremy Falcon
-
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”. There should be a similar saying in regards to writing (non unit) test cases. "Always write test cases as if the person who ends up testing your software is a 5 years old without any knowledge of the software" I'm going through some test cases on a large software and the tests cases are just a description of what I need to do. In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Seriously, do you know of any good white paper on how to write good test cases ? groan.
CI/CD = Continuous Impediment/Continuous Despair
Would test automation help? Had used Selenium framework, for a web application, some years ago, and our test scripts automated all the steps. There must be a similar framework for desktop apps.
-
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”. There should be a similar saying in regards to writing (non unit) test cases. "Always write test cases as if the person who ends up testing your software is a 5 years old without any knowledge of the software" I'm going through some test cases on a large software and the tests cases are just a description of what I need to do. In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Seriously, do you know of any good white paper on how to write good test cases ? groan.
CI/CD = Continuous Impediment/Continuous Despair
My Sr. partner is the best when it comes to breaking things: 0: Entering non-numeric chars where numbers should go or invalid numbers such as 1,1.2 or 1.1,2 (fun fact, letters up to f will happily identify as numeric) 1: Extremely long text/numbers, special characters, 0s as divisors 2: Leaving 'required' fields blank 3: Using the back button in web apps Of course, there are some situations you can't predict. That's what users are for! :laugh:
"Go forth into the source" - Neal Morse "Hope is contagious"
-
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”. There should be a similar saying in regards to writing (non unit) test cases. "Always write test cases as if the person who ends up testing your software is a 5 years old without any knowledge of the software" I'm going through some test cases on a large software and the tests cases are just a description of what I need to do. In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Seriously, do you know of any good white paper on how to write good test cases ? groan.
CI/CD = Continuous Impediment/Continuous Despair
It comes down to my biggest beef with tests and that's being only as good, generally, as whoever wrote what they're testing. For one, some jabroni didn't really write tests for your system. They wrote some documentation. If you can't run them in an automated fashion - without manually hunting records down and manipulating data? Then they simply aren't tests and if the person's task was to write tests, they 100% failed that task. You write the test so that it stages the data you know will work and then delete that data post-test. [OneTimeSetup] / [OneTimeTearDown] are the decorators for NUnit to do stuff like that. When we started writing a bunch of tests, we settled structuring things linearly like the following with regions for: Class Members Assemble/Setup Act/Invoke Test Asserts Cleanup
-
My Sr. partner is the best when it comes to breaking things: 0: Entering non-numeric chars where numbers should go or invalid numbers such as 1,1.2 or 1.1,2 (fun fact, letters up to f will happily identify as numeric) 1: Extremely long text/numbers, special characters, 0s as divisors 2: Leaving 'required' fields blank 3: Using the back button in web apps Of course, there are some situations you can't predict. That's what users are for! :laugh:
"Go forth into the source" - Neal Morse "Hope is contagious"
and/or - cancel dialogs - close app (with click on "X") while db is in edit mode - kill app with task manager while someone is editing something - use special - non ascii - chars where it is not expected - simulate high load with endless read/write operations - change screen size/resolution to unusual values
-
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”. There should be a similar saying in regards to writing (non unit) test cases. "Always write test cases as if the person who ends up testing your software is a 5 years old without any knowledge of the software" I'm going through some test cases on a large software and the tests cases are just a description of what I need to do. In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Seriously, do you know of any good white paper on how to write good test cases ? groan.
CI/CD = Continuous Impediment/Continuous Despair
Get some experienced testers to bash it hard - much better than test scripts IMHO - writing(and testing / maintaining test scripts) is often harder than coding the application
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
-
Get some experienced testers to bash it hard - much better than test scripts IMHO - writing(and testing / maintaining test scripts) is often harder than coding the application
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
It seems like you're suggesting that getting experienced testers to thoroughly test a product is more effective than relying solely on test scripts. This approach can indeed provide valuable insights and uncover issues that might not be caught through automated testing alone. Your quote by Hunter S. Thompson highlights the importance of thoroughness and vigilance in testing to avoid pitfalls. Click Here
-
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”. There should be a similar saying in regards to writing (non unit) test cases. "Always write test cases as if the person who ends up testing your software is a 5 years old without any knowledge of the software" I'm going through some test cases on a large software and the tests cases are just a description of what I need to do. In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Seriously, do you know of any good white paper on how to write good test cases ? groan.
CI/CD = Continuous Impediment/Continuous Despair
For at least 30 years, we have had/practiced the "5-year-old robustness test": Put the kid in front of a keyboard and a screen, and tell him: Do anything you want. If you make it lock up, and can show daddy/mommy what you did, you'll have an ice cream cone!" I know of a few ice cream cones awarded that way :-)
Religious freedom is the freedom to say that two plus two make five.
-
For at least 30 years, we have had/practiced the "5-year-old robustness test": Put the kid in front of a keyboard and a screen, and tell him: Do anything you want. If you make it lock up, and can show daddy/mommy what you did, you'll have an ice cream cone!" I know of a few ice cream cones awarded that way :-)
Religious freedom is the freedom to say that two plus two make five.
-
My Sr. partner is the best when it comes to breaking things: 0: Entering non-numeric chars where numbers should go or invalid numbers such as 1,1.2 or 1.1,2 (fun fact, letters up to f will happily identify as numeric) 1: Extremely long text/numbers, special characters, 0s as divisors 2: Leaving 'required' fields blank 3: Using the back button in web apps Of course, there are some situations you can't predict. That's what users are for! :laugh:
"Go forth into the source" - Neal Morse "Hope is contagious"
-
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”. There should be a similar saying in regards to writing (non unit) test cases. "Always write test cases as if the person who ends up testing your software is a 5 years old without any knowledge of the software" I'm going through some test cases on a large software and the tests cases are just a description of what I need to do. In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Seriously, do you know of any good white paper on how to write good test cases ? groan.
CI/CD = Continuous Impediment/Continuous Despair
Maximilien wrote:
In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work.
Why not edit a single record so it will work? I'm currently doing a project where we're rewriting an old VB6 application that used to use a dBase database. It's SQL Server now, but everything is not what you'd expect (everything is char(x), even bools, which have "Y" or "" (and sometimes "N"), except some ints, which are int or decimal(x,y)). Lots of magical numbers and strings too. Some fields even are like
"X X "in which the first X means "option 1 should be used" (whatever option 1 is), the empty second and third position means those options are off and the fourth X means option 4 should also be used (the software only uses four options, even though it's a char(10), also it's not always X, sometimes and option can be, for example, "S" for small or "L" for large, etc.). Anyway, finding a row you can use and writing a WHERE clause is a pain, so I just edit the top row so it'll fit my test/use case.Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”. There should be a similar saying in regards to writing (non unit) test cases. "Always write test cases as if the person who ends up testing your software is a 5 years old without any knowledge of the software" I'm going through some test cases on a large software and the tests cases are just a description of what I need to do. In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Seriously, do you know of any good white paper on how to write good test cases ? groan.
CI/CD = Continuous Impediment/Continuous Despair
- Mind internationalization. Is your app translated? In how many languages? Serious work to do if this number is greater then 10. 2) How does the GUI looks like on a native Chinese (Traditional or Simplified)/Japanese/Korean PC? 3) Input long texts in various languages, with many specific characters. Special care when comparing and processing texts - in which culture? 4) Did you specify a culture when installing the app DB? If not, the SQL server default one will be used. Try different cultures/collations etc. 5) Input/use numbers in various cultures, alternating decimal/thousand separators etc. 6) Input/use datetimes in various cultures. 7) Set the date of the PC to 29th february in a leap year and test app functionality. 8) If you read text from disk/stream, create test files containing binary data (e.g. 0x1A/EOF - can your app read text beyond that byte?). Or create test files that have \r\n or only \n as end of line etc.
-
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”. There should be a similar saying in regards to writing (non unit) test cases. "Always write test cases as if the person who ends up testing your software is a 5 years old without any knowledge of the software" I'm going through some test cases on a large software and the tests cases are just a description of what I need to do. In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Seriously, do you know of any good white paper on how to write good test cases ? groan.
CI/CD = Continuous Impediment/Continuous Despair
When I was working on an ActiveX control embedding a video stream into a web page (a long time ago when others were still working to prevent millenial apocalypse), we had a customer who used the "coffee cup" test - put a coffee cup down on F5 so it would continually refresh. Extremely harsh!
-
John F. Woods once said : “Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.”. There should be a similar saying in regards to writing (non unit) test cases. "Always write test cases as if the person who ends up testing your software is a 5 years old without any knowledge of the software" I'm going through some test cases on a large software and the tests cases are just a description of what I need to do. In reality, I have to do about 20 different steps to get there and go through thousands of records (SQL) to find one record that will work. Seriously, do you know of any good white paper on how to write good test cases ? groan.
CI/CD = Continuous Impediment/Continuous Despair
Maximilien wrote:
Seriously, do you know of any good white paper on how to write good test cases ?
No, but I can list what I do: 1. Write use cases. What are users supposed to do with the system? From use cases, build test plans which not only test the system but teach the testers how to use it. 1A. Ideally most test cases start with new records and build upon them. For cases where that is not feasible, construct test records. Create scripts that will insert or revert the test records. If you have to hunt for test records, do it just once. 2. If you have role-based authentication and authorization, conduct each test in #1 for each role. 3. Most applications have pre-defined choices (radio buttons, drop down lists, list boxes). Test every possible combination. 4. This one is the hardest -- make as many totally illogical choices as possible. Try to do things out of order. Paste 10,000 characters into a textbox. Enter a string of special characters only. Save while missing mandatory inputs. Basically the "five year old" part. 5. Ask the end user testers to do as many weird things as they can think of. Trust that they will think of things you will never consider. I'm no longer surprised at how much basic error handling is NOT built into applications, e.g., the DB field is 20 characters but the text entry field is unlimited. #4 will identify things like that.
-
For at least 30 years, we have had/practiced the "5-year-old robustness test": Put the kid in front of a keyboard and a screen, and tell him: Do anything you want. If you make it lock up, and can show daddy/mommy what you did, you'll have an ice cream cone!" I know of a few ice cream cones awarded that way :-)
Religious freedom is the freedom to say that two plus two make five.
Brilliant! I need to offer more ice cream cones to my QA team.
Religious freedom is the freedom to say that one plus one plus one does not always make three. Scientific freedom is the freedom to say that parallel lines in a non-euclidean reference system may shake hands.
