I recently stumbled over an article about Microsoft's chatbot Tay which - after only 24 hours "training" turned into a more than questionable little "monster". The article was the inspiration for this one cartoon.
Showing posts with label robot. Show all posts
Showing posts with label robot. Show all posts
Saturday, February 4, 2023
AI Adventures in Babysitting
Labels:
adventures,
AI,
artificial intelligence,
babysitting,
babytalk,
cartoon,
chatbot,
Drift,
gbt,
gbtChat,
robot,
Tay,
testing,
zelger
Monday, January 2, 2023
Sunday, October 21, 2018
Tuesday, February 6, 2018
Thursday, February 20, 2014
Robots Wedding
Labels:
church,
computer,
oil,
priest,
robot,
robots,
rusty times,
wedding,
wedding vows
Wednesday, November 27, 2013
Robot Breeding
Tuesday, September 4, 2012
Captcha #1
CAPTCHAs are used to prevent automated software from
performing actions which degrade the quality of service of a given
system and/or to protect the service from attackers trying to hack login credentials using brute-force attacks.Until now, I never had to test CAPTCHAs but thinking about it, testing CAPTCHAs automatically is impossible if testability isn't considered at all. Testability here could mean for the roboter to offer a backdoor which contains the correct clear-text. Of course such information should only be available to the script and de-activated when deployed live. Sometimes, even I struggle to identify the clear-text of the CAPTCHA, and I am NOT a roboter...
Labels:
captcha,
cartoon,
robot,
security check,
test automation,
testing,
zelger
Wednesday, August 12, 2009
Functions As Designed
Many customers have different requirements or requirements that change backwards and forwards over time, especially in an early stage of the project. The developer's weapon against such ping-pong requirement changes are : make it all configurable
Whatever the customer sets is what he gets, even if the settings don't make any sense in their combination.
It is awkward if you have changes to existing behavior without noticing the parties concerned.
Testers raise defects whereas the symptoms are more a result of new features implemented and activated by default rather than actual defects.
We have an unwritten law that guarantees customers don't need to adapt their configuration files just to ensure existing functionality doesn't get changed due to some (unwanted) new features or restrictions in the use of some old existing features.
It is not only unpleasant for the customer, our test scripts won't work either. Well, that's the good thing of test automation. We wouldn't have detected those anomalies at the same speed as if we had done this test manually. However, we still struggle with a straight reaction to the findings. There are still some roadblocks to master.
Labels:
bugs,
configuration,
featue,
robot,
testing
Tuesday, November 13, 2007
Subscribe to:
Posts (Atom)






