You can find a gallery of pictures from this week’s STPCon here.
Archive for March, 2012
Maybe he didn’t coin it, but Joe Strazzere talks about how QA needs to do some Crappy Path testing.
So I remembered this article I got in a newsletter, so I looked through my email archives to find it, and then it included a teaser paragraph and a “Click to read more” link, so I clicked, and….
The email links to the email service provider, not the actual link destination, to provide clickthrough metrics and measurements. When the email arrived in my inbox, this link redirected to the target, but now it redirects nowhere.
You might want to ask your email provider whether its links expire and consider whether the thing you’re emailing might be relevant beyond that time. With certain time-delimited offers, this isn’t a bad thing. But if you’re trying to drive traffic to your Web site generally or hope your featured whitepaper will get prospects now and in the future, it might behoove you to find an email provider whose links don’t.
For Jacob Arriola, a business development manager for a Spanish media company in Los Angeles, learning to program wasn’t a necessity. But figuring it might help with his job, he started using an online code-tutorial service called Treehouse in January.
After three months with the paid service, he’s earned several dozen badges for completing programming quizzes and challenges, and watching coding-related video lessons. More importantly, he’s built his own website from scratch and made some simple changes to websites that his company runs. “I’m able to do it myself, which is pretty cool,” he says.
You know, QA has had something like for over 30 years now. (more…)
As I mentioned on Twitter, I’m a member of the Rutger Hauer school of software testing. The Rutger Hauer school of software testing (RHSoST) focuses less on processes and procedures and more on how to wreak havoc using a varied set of tools upon a system or application regardless of its plot, I mean, its business rules.
But here are some of the primary texts of the school:
Beyond Justice. The basic primer in software testing describes how to create user scenarios to test systems, how to understand and work within and without established processes and procedures, and how to turn erstwhile enemies into allies.
- Exploratory Testing, Basic:
Blind Fury. Even when you lack basic knowledge about a system or insight into the business rules or considerations, you can still
cause damagefind defects with your swordbasic set of test cases that apply to any application.
- Exploratory Testing, Advanced:
Blade Runner. As your knowledge of applications grows, you can find more complexity and higher levels of business rules to test until the final deadline.
- Load Testing:
Escape from Sobibor. Learn how careful planning and execution of load tests can find the weaknesses in and actually crash the most rigid set of rules and constraints in an application.
- Career Planning: Working in a Large Corporation:
Deadlock. Learn how to find a payoff even when constrained by an explosive device bolted to your neck, figuratively speaking (and literally).
- Career Planning: Working as a Test Consultant:
Hobo with a Shotgun. This text deals with the itinerant tester and the challenges he/she faces with each new engagement, including how one fits in–or does not fit in–with the existing culture and how one can test effectively and efficiently on the run.
Rutger Hauer on the end of a project and the knowledge lost when a test consultant or team member moves on:
These are some of my favorite texts in the RHSoST. Undoubtedly, some of my fellow school members have their own. Don’t be afraid to share in the comments.
In your QA circles, you’ve got your Picard leaders, who confront a problem by calling a meeting, and you’ve got your Kirk leaders, who confront a problem by besting it in combat that somehow leaves the Kirk leader’s uniform torn.
When I was trying to sign up for something on Dice.com, I got this CAPTCHA:
So, if you mean in numerical order, it would be
seven, but wait a minute, seven is not a number in this question, it is a word representing a number, in which case 15 would be the first number in the series. BUT! in the list, 16 is the first number, and the list is missing the serial comma which might indicate that the
and is equivalent to the + mathematical operator, which would make the second number 22. But what if it’s one number: 16,157? Then the first number is 1. But wait! If we’re counting ordinal numbers along with cardinal numbers,
1st is the first number that displays!
I tried entering
I tried entering
To hell with it. I reloaded the page and got a CAPTCHA that makes sense.
So what are the effects of CAPTCHAs on users, particularly in abandoned forms? Here’s one fellow’s thoughts.
This book is the autobiography of Richard Marcinko, the man who organized SEAL Team Six. It recounts his history from his days as a lowly enlisted man in the United States Navy and his rise through the ranks as he becomes an officer, a leader, and commander.
So what? you might ask. I’ve read a bunch of books about testing, I’ve read a couple of books about managing, but I’ve never really read a book that captures a career path that mimics the one in software testing.
You start out bucking the system, complaining about the Man, and fighting hard to get quality. Eventually, if you get promoted to team lead and beyond, you have to subvert that fighting instinct to recognize the new environment and to work within its limitations to further your goals and missions.
Marcinko goes from a platoon leader who goes around the leadership he doesn’t like to being a ramrod straight commander of a SEAL team. He was to play the political game a bit and know how things are done in the Navy. When he gets an opportunity, he gets to form his own team, SEAL Team Six, in his own vision–which is closer to snake-eating SEAL grunt than ship-driver (that is, a commander that comes from a different milieu). Marcinko ends up training with his men even when he’s a high-level executive.
Definitely some interesting lessons in this book, but as it is his autobiography and it’s written from the point-of-view of a long time military man, the language is pretty vulgar and the outlook a bit crude. However, Marcinko has written two books that have his picture on the cover in suits and probably don’t have quite as many f-bombs: Leadership Secrets of the Rogue Warrior and The Rogue Warrior’s Strategy for Success.
Or, if you want some more sedate reading, you could pick a book off of James Bach’s recent list, but there’s probably not as much shooting in them.
Books mentioned in this review:
If you have the Turkish Lira symbol somewhere within your application (and, hey, who doesn’t?), be advised there’s a new symbol in town:
Turkey on Thursday introduced a new symbol for the national currency.
The symbol–a double-crossed, T-shaped anchor–is intended to mean “safe harbor” says Turkey’s Prime Minister Recep Tayyip Erdogan. The upward-facing crosses symbolize Turkey’s growing economic clout, he added.
I haven’t been able to find out how this will impact computer codes/symbols yet, but some of us need to consider the implications.
A quick review of leap day issues from this week:
- Leap day scuttles Eftpos
February’s extra day has been causing problems with computer systems here and in Australia.
Foodstuffs said an eftpos outage at lower North Island New World, Pak n’ Save and Four Square stores this morning occurred after its systems were unable to cope with today’s leap day date.
The outage, which has now been resolved, affected many stores across the lower North Island from early this morning.
(Source: A tweet from someone on the other side of the Pacific Rim whom I follow.)
- Windows Azure Leap-Year Glitch Takes Down G-Cloud:
Microsoft has confirmed that a service outage that affected its cloud computing service Microsoft Azure, appears to be caused by a leap year bug.
The Government’s G-Cloud CloudStore was among the sites affected by the outage, which Microsoft says has mostly been rectified.
(Source: Reader Isarian.)
Is that it?
That’s all we know about.
Sleep tight, and remember that December 31 is Day 366, as Microsoft knows. Or should know. But given this is the second Microsoft product leap year crash in as many leap years, who knows what Microsoft knows.
I noticed something in Windows 7 Explorer. Well, I noticed something missing. In the upper left corner of a Windows application, there’s a little icon not unlike the fav icon you get on the browser bar in a Web browser. You might not know this, child, but you can click that icon to get a short menu of window manipulation or you can double-click it to close the window. This has been pretty standard since OS/2 (go ask your grandpa what that means).
But in Windows 7 Explorer, there’s no icon. But the menu remains when you click that portion of the title bar:
Which got me to thinking.
If you’re working on a mature application, say something that’s been built two years ago, has customers, and plans new releases without a complete rewrite in the latest technology/platform fad, what do you do when your company sunsets a feature?
You know, they determine that the customers don’t use it and they don’t want to maintain it any more, so they turn off the Fax feature. What do you do, QA?
You tear the relevant test cases out of the binder (ask your grandpa) and schedule 2-5pm Friday for margaritas!
Well, that might be what you could do. But what you should do is analyze where that feature is exposed. Not just the Fax to dialog box, not just the Fax to menu item. Features woven into a robust application get exposed to the customer in a number of ways.
- Steps in a wizard where the Fax to is an option.
- Spots in the online help that launch the page/dialog box.
- The documentation and marketing materials.
- Buttons in other features that shortcut to the deprecated feature.
Only you know, or should know, where the features are exposed across your application. The developers look at their trees and don’t see the forest.
The simple act of excising features and dialog boxes, windows, or pages from the application requires not only the removal of test cases and test scenarios, but also the creation of separate tests to make sure it was removed completely and cleanly.