|
GKP1992 wrote: Was it too easy?
I didn't get it, so I did not consider it easy, if that helps! It probably doesn't help a lot as I get very few of them; yesterday's was the first for a long time.
As others have said, what is easy for one person is hard for others and vice versa.
|
|
|
|
|
Origa - Inner Universe[^]
A song recommended to me by YouTube.
I didn't know it yet, but apparently it's from the soundtrack of the Ghost in the Shell series.
It's pretty cool with fast paced beats and classical singing.
I still remember King of my Castle from the animated film.
If all Ghost in the Shell music is like this it seems I'll have to find the complete soundtrack 
|
|
|
|
|
...Mothers[^]
Sorry, I couldn't resist (and I couldn't think of a way to make it work as a TotD if I'm honest) - I'll get my coat. 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Ugh, parents who show me pictures of their kids are the worst.
Especially if those kids are still ugly little trolls babies.
I do the same with my cat, but everyone loves cats 
|
|
|
|
|
They all look like a cross between Winston Churchill and a shaved chimpanzee to me ... and I have to pick a feature and saye "(S)He's got your ... !" trying not to spot anything too out of proportion. 
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: (S)He
It's impossible to get even that right 
OriginalGriff wrote: a cross between Winston Churchill and a shaved chimpanzee
Spot on!
|
|
|
|
|
Oh my, (s)he looks just like a...baby.
|
|
|
|
|
I know that "Did you keep the receipt?" doesn't go down well.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: I have to pick a feature and saye "(S)He's got your ... !" trying not to spot anything too out of proportion.
That's like the "nice shoes" thing -- it's advisable to say it to women, even if you haven't looked at them.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
Sander Rossel wrote: I do the same with my cat
Show us, show us!
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
|
|
|
|
|
|
Cute! 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
Never argue with a fool. Onlookers may not be able to tell the difference.
Mark Twain
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
