|
So you like them when they show pictures of their holidays, don't you?
|
|
|
|
|
If they're nice pictures that give me an impression of their destination, then yes 
|
|
|
|
|
Sander Rossel wrote: everyone loves cats
 boooooo!
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
We had a period at work when one after the other became a mom or dad, and brought piles of their kids.
Then in spring one of the unmarried young guys bought himself a bright red motorbike (I believe it was a 1200cc), and spent the summer touring all of Norway on it, taking hundreds of pictures. When he returned, he had piles of photos of his bright red MC by the mountain lake, by the shore, at the ferry, at the mountain pass ... And it looked as if he always dusted off his MC before taking a picture.
He never told if this was a deliberate protest against those baby photos. I guess it was.
|
|
|
|
|
This is a reasonable setup, right?
1. Test Spec :
a.Explains the scope.
b.Defines how the testing should be approached.
c.It covers all the environment aspects : How to set up & start the tests.
d.Pointers to all the resources & links.
e.A link to test cases template
2. Test cases template Doc:
a.Testing team takes care of filling up this template.
b.Referring the Requirement doc & all the resources given to them for grasping the product.
c.They generate the whole test cases.
There are some confusion in team asking why we need two docs?
Does combining these two would make sense?
|
|
|
|
|
Where I work the developers work off 'user stories' and the testers write their tests independently, which I think is slightly ridiculous as it means that the testers get two days to test and discover defects then the devs have a short amount of time to put in the fixes and get it back to the testers.
The test documentation should really be part of the specification because the developers should ensure that their code passes the tests.
Sure it's good for the testers to independently try and break the code but for goodness sake why would you put the devs and testers in a position where they are not agreeing on what the functional specification is?
Actually I do know why, the answer is one word "Agile" 
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 18-Jan-19 5:27am.
|
|
|
|
|
There are no rules; you can call your documents by any name you want.
However, if I were handed two documents with the names you've given, I'd assume that:- The Test Spec doc is the overarching description of how all tests of everything should be configured/followed/whatever, and should be provided be the chief tester.
- The Test cases doc contains use cases that have to be given attention when designing tests for a specific project/component/app/whatever, and should be provided by either the docs team or someone in a customer-facing role.
I wouldn't expect docs with either of those names to contain any actual tests.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
The test spec also should state the requirements for the test cases, such as coverage (both in % of code lines and input values), identify external border case values and other environmental elements, and level(s) of reporting from each test case. (Maybe you consider this part of how the test is configured, but that should extend far beyond the technical aspects of how to hook up the pipes in order to make the test run.)
|
|
|
|
|
Sure, but I wouldn't expect a doc named Test Spec to be applicable to only a single project/product/whatever.
However, that's just me. As I said, you can call your docs what you like, so long as everyone who uses them is aware of their functions.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
You would expect a Test Spec to be just general considerations about testing at large? 
I would expect a specification to give the specifics of the testing of a system. General principles and methods with no specifics about a product or test suite I refer to as a Test Framework,
I would expect a Test Spec to make concrete specifications for this specific set of test cases: For this specific product we require a minimum of 98% coverage of ordinary code lines, 90% coverage of exception handler code for "expected" errors and 80% of "not expected exceptions", for input values of T from -30 to +70, input value B from -1 to 100,000 ...
Another, high reliability project might require coverage of 99% of all exception handlers, and 99,5% of all possible branch outcomes, more specific requirements to the input space testing (border cases, combination of border case input values - in a realistic scenario, it is never possible to test all possible inout combinations - etc. etc.).
A test spec is a requirements spec for the testing. A requirements specification is product specific. So is the test specification for the same product.
(But then again: In some environments, a "Requirements specification" goes way beyond the customer's requirements, even beyond the solution architecture but sometimes far into specific code design aspects. I have fought this for many years: The real customer requirements might be far better covered by a different architecture, and certainly by another code design. So why does a requirement spec limit us, prohibit us, from satisfying those requirements in a better way, through a different architecture and code design from that which is "required"?
THis is really the same question in a slightly different area: Which information goes into which document. Today, it seems to be fully accepted that a "Requierements specification" can go as far down as to include interface definitions in one specific language, and screen dialogs created by one given UI generator tool, all stated as a "requirement". Maybe we should simply give up, letting those who have succeeded in forcing their coding style and their pet development tools through, rule. Give them the power to reject any other solution: No, the customer has required that we implement it with exactly these interfaces, with a UI that can only be realized by this tool!
But then: When the customer identifies his problems and needs for a solution, without making any specific demands for implementation tools or inteface specs or whaterver, he just details his needs for the solution, what shall we call that document? Is "Customer Wishes" a term that might be used, or will the turf warriors grab that term as well, declaring that whatever the customer says, his real wish is a solution implemented in Python, using a cloud based iPhone app, even though the customer never mentioned any of this in the consultations?)
|
|
|
|
|
Hmm,
Sounds good, however the place I works 'Agile(ish)' which means the project gets given to whoever can do it, they start, get shifted on to other things, task gets hardware, hardware needs correcting, there are lots of 'hurry up' you are a bottle neck. Eventually something goes out.
We started to go the two doc route, stopped it went back to one monolithic document that can cure insomnia, try to integrate tests to a Jira system, fail, go back to monolith that takes a small forest to print (because you must record results on paper). So in short go for two!
|
|
|
|
|
We used to call them as Test Plan, and Test Cases Doc.
Test Plan is what you call as Test Spec. Test Cases Doc is where the test steps for each test case are listed, along with Traceability to Requirements, and additionally it has a column Pass / Fail / Marginal. Sometimes the Test Report, the actual pass/fail/marginal report for each test is a separate Excel sheet.
|
|
|
|
|
Mattress makers have begun switching to a solid piece of foam.
I lied (laid ?) down on one this week.
Brought back memories of judo mats from my teenage days.
But then,,,,,,
Is that such a bad thing ?
I will be purchasing something on which to sleep soon.
Has (or is) anyone else around here used (or using) a foam mattress ?
Any Difference ? Good ? Bad ? Better ? Worse ?
|
|
|
|
|
I need a new mattress, so I'll consider this option. I know you get some fancy ones with different density layers, memory foam, etc.
It seems like it could be hot / sweaty in summer? And I'm not sure about long term durability?
|
|
|
|
|
Foam is not good for hot country, it makes you feel uncomfortable
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
Nice for the top layer, but can be a bit firm. If you want more give, put an inch of memory foam on a sprung mattress.
Re lied vs laid, it is lie for people, lay for objects.
I always go here when in doubt about English words. https://www.etymonline.com/[^] It gives their origin, and origin is always the correct meaning.
|
|
|
|
|
Munchies_Matt wrote: lie for people, lay for objects
Unless you're out getting laid. 
|
|
|
|
|
But then you are the object, no?
|
|
|
|
|
But most of my friends lied about getting laid.
Socialism is the Axe Body Spray of political ideologies: It never does what it claims to do, but people too young to know better keep buying it anyway. (Glenn Reynolds)
|
|
|
|
|
Munchies_Matt wrote: Re lied vs laid, it is lie for people, lay for objects.
Nonsense.
Try looking it up from somewhere that isn't wikipedia, and isn't only an "on-line resource" (e.g. one that doesn't include words like "expert" and "girl" in its title).
Munchies_Matt wrote: https://www.etymonline.com/[^]
WTF has the etymology of the words got to do with anything?
According to the etymology of "precise", it means "truncated".
A huge proportion of our words do not mean what their etymological root words mean, and don't even start to say that their usage has remained the same.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: WTF has the etymology of the words got to do with anything?
Indeed, what has its original meaning got to do with its meaning eh? 
Lay or lie ? - English Grammar Today - Cambridge Dictionary[^]
"The verb lay means ‘to put something down carefully in a flat position’. It must have an object. "
"Lie is a verb which means ‘to be in or put yourself into a flat position’. ... the past simple is lay"
And of course as with all weak/strong forms of verbs you can use 'lied' as well as 'lay' as the past simple of 'to lie'.
So 'she lied on the bed' is the same as 'she lay on the bed'.
(if you dont know about weak strong verbs yet think about dived dove, weaved wove, etc. A strong form is one where the participle spelling is maintained in the past simple. )
But 'to lay' as a verb is for an object.
|
|
|
|
|
Your lack of knowledge of English grammar is amply demonstrated by your mindless misinterpretation of the clause "It must have an object".
Look up the grammatical meaning of the word "object".
It is neither the same as its meaning in programming, nor in the way that you interpreted it.
Hint: it says "have an object", not "be an object" (but even that is not strictly true -- it must be able to take an object, not always have one).
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I didnt say 'be an object' I said 'lay for objects'.
Moron.
|
|
|
|
|
Munchies_Matt wrote: Moron
Your new signature is highly appropriate.
Let's hope it's not a transitive thing (which is unlikely, because you obviously don't know the meaning of "transitive").
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Behind every paradox lies a Cretan.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
