 |
Home > Detail: Testing the Bold and the Beautiful
Viewing 1-10 of 59 Collapse Descriptions
Sort by: Date Posted | Title | Content Type | Relevancy
 
ARTICLE: Testing the Bold and the Beautiful
Author(s): Yogita Sahoo
Summary: “During testing, testers mostly stress the ‘Bold’ part of the software and comfortably overlook the ‘Beautiful’ side. Beauty and functionality are treated as two extreme ends in software quality, where only one of the two can meet perfection at a given time. But the viewers of the famous soap opera The Bold and the Beautiful know very well that both are important.” In this article, Yogita Sahoo explains why aesthetics are such an important contribution.
BOOK: Beautiful Testing
Author: Tim Riley and Adam Goucher
Pages: 350 Published: 2009
Description: Successful software depends as much on scrupulous testing as it does on solid architecture or elegant code. But testing is not a routine process, it's a constant exploration o...More
BOOK: Beautiful Security
Author: Andy Oram and John Viega
Pages: 300 Published: 2009
Description: In this thought-provoking anthology, today's security experts describe bold and extraordinary methods used to secure computer systems in the face of ever-increasing threats. <...More
BOOK: Beautiful Teams
Author: Andrew Stellman, et. al.
Pages: 508 Published: 2009
Description: What's it like to work on a great software development team facing an impossible problem? How do you build an effective team? Can a group of people who don't get along still b...More
BOOK: Beautiful Architecture
Author: Diomidis Spinellis, et al.
Pages: 426 Published: 2009
Description: What are the ingredients of robust, elegant, flexible, and maintainable software architecture? <em>Beautiful Architecture</em> answers this question through a collection of in...More
BOOK: Beautiful Code
Author: Andrew Oram/Greg Wilson
Pages: 618 Published: 2007
Description: How do the experts solve difficult problems in software development? In this unique and insightful book, leading computer scientists offer case studies that reveal how they fo...More
 CONFERENCE MATERIALS: Small is Beautiful: Business Agility Through Adaptive Governance
Author(s): Sanjiv Augustine, LitheSpeed
Summary: In this economic downturn, is your company looking beyond knee-jerk cost cutting to focus on creative ways to solve business problems? When businesses tap the innovative capabilities that agile development teams possess and scale up through adaptive governance, they can produce game-changing solutions. Sanjiv Augustine shares how leading businesses are using agile to jumpstart and scale their new product development by incorporating user-centered product design and a user story “maturity progression” to support the creative evolution of system development. To optimize their project investments, these businesses are adopting incremental funding and portfolio-level feature prioritization, reducing team churn by creating stable teams with embedded specialists, and tracking and monitoring project portfolio progress across multiple teams in a visual, agile fashion. In addition, businesses are aligning individual compensation with team-based performance management to reward both teamwork and individual excellence. Join Sanjiv and learn how you can adapt these successful practices to your organization.
Conference: Agile Development Practices
ARTICLE: Make Reuse a Reality with STL Algorithms
Author(s): Chuck Allison
Summary: Good code is a beautiful thing—especially when you don't have to write it. While most of us are quick to use prepackaged containers such as vectors, lists, and maps in everyday programming, we often overlook algorithms as a reuse tool. Find out how standard template library algorithms, specifically, can put you on the road to reuse.
Date Posted: Aug 28, 2007 |
ARTICLE: Looks Do Matter
Author(s): Yogita Sahoo
Summary: In a previous article published on this site, "Testing the Bold and the Beautiful" (May 2001), the author received many thoughtful comments and questions about the importance of aesthetics in software. This paper was inspired in part from those questions. It clarifies the difference between aesthetic testing and usability testing. The paper makes the business case for "beauty testing" and argues that an ugly UI can undermine the bottom line. It offers methods and a survey-template for successful aesthetic testing. The paper concludes with a list of "Facts and Myths, Dos and Don'ts."
Date Posted: Feb 25, 2003 |
MAGAZINE ARCHIVE: Make Reuse a Reality with STL Algorithms
Author(s): Chuck Allison
Summary: Good code is a beautiful thing--especially when you don't have to write it. While most of us are quick to use prepackaged containers such as vectors, lists, and maps in everyday programming, we often overlook algorithms as a reuse tool. Find out how standard template library algorithms, specifically, can put you on the road to reuse.
Type of Article: Dept: Code Craft
Better Software Issue: September 2007| Date Posted: Aug 29, 2007 |
|
Viewing Item 1 of 59
| A StickyMinds.com Original |
|  | |
Testing the Bold and the Beautiful
By Yogita Sahoo
   
Summary: “During testing, testers mostly stress the ‘Bold’ part of the software and comfortably overlook the ‘Beautiful’ side. Beauty and functionality are treated as two extreme ends in software quality, where only one of the two can meet perfection at a given time. But the viewers of the famous soap opera The Bold and the Beautiful know very well that both are important.” In this article, Yogita Sahoo explains why aesthetics are such an important contribution. | | |
|
|
 |
We all make software that works beautifully, but how many put a high priority on making software with a beautiful look?
All our testing efforts are concentrated on functional enhancements and corrections so as to make the product work better. But how many of us really think about making it look better? Probably, in our terminology, beautiful software is software that is bug free and stable. But what does the end user understand and expect in terms of beautiful software?
For me, software is beautiful when it works effortlessly with the person sitting at the terminal. And the program has an appearance defect if something that you reasonably expect to appear is missing, awkward, or confusing. The user should find it painless and fun to use the software. Effective onscreen instructions, adequate information, and interactive dialogs can make the software look and function better.
Testers may argue here that they already perform usability testing on every application that is driven with a user interface. If you get a little deeper into the concept, you will see how Usability and Beauty are two independent and yet inseparable entities. Usability is all about the ease, speed, and pleasantness with which the user can use the application. And during usability testing, ease and speed are still given importance, but pleasantness often remains in question. If the “pleasantness factor” is well taken care of, we will certainly succeed in creating beautiful software with high-end functionality. Beauty actually serves toward acquiring better usability.
The major drawback of a technically competent team developing and testing software is that the look of the software often takes a back seat to functional mechanics. Perhaps that is because everyone on the team is so preoccupied with proving their technical skills and making the product tech-rich that they tend to forget the comforts and ease of the intended user. But paying a small amount of attention to the application’s serviceability toward the user can dramatically improve the software’s quality and the user’s overall productivity.
Nine out of the ten applications that I get to test are not really good-looking. To be more blunt, these applications are downright ugly. Now, don’t mistake them for being technically poor. They are rich with features. But they can be awarded, at max, two points on a scale of ten for their visual merits. When it comes to captions, font color and styles, meaningful and appropriate dialog boxes and error messages, I often feel like redoing the whole thing. For such products, my bug list actually starts with appearance and communication issues.
In my personal experience, developers love to ignore such issues. “It’s not a bug as long as the window has some caption,” they are apt to say. “Throwing an error dialog in there is enough. Users at least get to know there is something wrong with their input.” Developers suggest that I keep these types of issues in my bug list as lower priority ones. “If time permits,” they say, “we may think of looking into those. After all, the application runs fine without them.” This attitude on the part of developers probably discourages testers from reporting cosmetic bugs. Testers may feel reluctant, fearing that they might be misunderstanding the functionality or reporting “trivial” bugs. But I always practice and preach that a tester should approach the developer with every issue that pinches him. It’s never offending to clarify doubts. What if you are actually seeing something that makes the developer take note? Maybe it was not ignorance on the developer’s part but a mistake that he would like to rectify. It is even better if the tester succeeds in convincing the developer that these issues are targeted toward reducing the software’s complexity.
I also encourage testers to dedicate some parts of their testing to nontechnical exercises. Testers are generally very comfortable writing functional test cases. But did any of us ever think of designing special test cases to catch appearance defects? Probably not. Minor defects in looks are mostly taken for granted in our trade. It’s misguided to believe that while performing functional testing, any look-oriented defect will be easily caught. If you have a small test case or even a checklist handy, you will realize what an amazing result it shows. For decent enough software, my appearance test cases are as small as half a page. But they cover some important issues like uniform looks, effective user communication, color combination, window placements, meaningful captions, tool tips, etc.
At least once during the testing process, you need to take off the tester’s hat and put on the user’s hat. Only then will you be able to understand how a small appearance issue may trouble a user. We don’t realize the effect of such deficiencies probably because we know their technical simplicity. But for a user, the front-end information carries more value than the back-end processing. For this reason, I always prefer a nontechnical tester in the test group. No one can track appearance problems better. As an alternative, you may have one efficient tester dedicated for such testing while others concentrate on functional testing. For large projects, you may even consider “scenario-based testing,” which is a very effective method of usability testing. For those who find this term unfamiliar, such testing involves presenting the application with the expected set of real-life usage patterns with the application. It is recommended to measure the human-computer-interaction characteristics of the system.
A tester’s primary concern is finding bugs, but that’s not the only job. Suggesting better alternatives is something a tester should try every now and then. Try suggesting better and more meaningful captions, better color schemes, and whatever else may make the product look appealing. When you cannot suggest corrections, think of enhancements. The nice thing about such enhancements is that—unlike the application construction where things have to be perfect at the first chance or you will never get a chance again—aesthetic enhancements can be introduced any time during the project lifecycle with very little risk. Most of the time, such efforts involve very few lines of code change but their effect will be drastic and marvelous.
Beauty can be beautifully confusing, as different users have different expectations. What looks beautiful to the tester may look nonappealing to the developer and ugly to the user. You can’t anticipate everyone’s expectations, and even if you could, you probably can’t satisfy everyone’s need without losing the program’s integrity. I suggest that aesthetic issues should be dealt with by a representative group (mostly testers, developers, and users) formulated by knowledgeable experts in consultation with system designers, experimenting on a separate copy of the application, and then finalized. Such representative groups are more productive because the group forms a consensus about aesthetic issues, which is better than a one-on-one debate between a tester and a developer.
So next time you are testing software, along with finding defects in the existing stuff, keep an eye out for things that can look better. All of us, who used to stay satisfied with usability testing, might add beauty testing to our schedules. And let the user feel as happy using the software as we do testing it.
About the Author
Yogita works as a QA/testing professional with Mindfire Solutions, and has written a number of articles on QA and testing strategies. Yogita is currently exploring thoughts of beauty as an area of testing and its relation to usability. Her role at Mindfire has been to implement Quality processes throughout the organization and build a dedicated testing team. The team recently published a White Paper “Porting projects: Test techniques,” downloadable from www.mindfiresolutions.com. Yogita can be reached at yogitas@mindfiresolutions.com.
Back to Top
|
