TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPass
Home  >  Detail: The Innovative Tester



A StickyMinds.com Original

The Innovative Tester

By Gunasekaran Veerapillai

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

Summary: Historically, the development team considers themselves the creators of the system and the QA community is considered as a necessary evil, more so when there is an independent testing group. Since test engineers sometimes work in a hostile atmosphere, they need to equip themselves with more knowledge in both functional and testing skills. This article discusses the importance of developing those skills.


Borland
"After becoming a QA professional, you started finding fault in everything." This was my wife's response when I pointed out the excess salt in my dinner. I then told her the story of the testing company that lost its business when the representative of the company claimed that they only "test to pass the system." 
 
Initially the testing was a sub-set of the Software Development Lifecycle (SDLC) and the developers performed the validation in the software programs coded by them. They then released them to the users for verification of the critical business flaws before starting production. The volume of business losses due to the inherent bugs in the systems has lead businesses to get independent verification and validation.  
 
Stand Over the Developers 
While the developers concentrate on the allocated programs and modules, the testers need to see the overall perspective of the application. If a programmer understands the functional and design specifications of the functions allotted to him, he can do a better job. But testers should broaden their vision to understand the entire functionality of the application. Testers should be comfortable with inputs, expected results, and data flows between modules and interfaces.  
 
Unless you have a thorough knowledge on the functionality of the system, it is difficult to gain overall insight into the application. So, before you involve yourself in testing an application, make sure you spend enough time understanding the complexities of the functionality of the application under testing. Knowledge of the system will help you: suggest valid improvements to the system, perform a complete meaningful test on the system, improve your leadership capabilities by extending help to other testers, and substantiate your arguments while defending the defects found in the system. 
 
Plan to Crack the System 
Perhaps you may have read the 70:30 Project Management story in circulation on two different types of Project Managers. Structural Planning is the basis for sound testing. Instead of tardy, unstructured planning, you should spend 70 percent of your time in systematic planning and preparation of the test strategy, testware, and test execution methodologies. By doing that, you can execute the test unblemished within the scheduled timelines. Always remember to:
  • Plan the execution schedule.
  • Review all the test documents.
  • Add traceability to ensure coverage.
  • Prepare the test cases and scripts.
  • Plan the data requirements and availability.
  • Decide on the proper strategy depending upon the types of testing required.
Crack the System 
Change yourselves. Crack the system. Create implicit test conditions and cases. See the system from the user's perspective. The role of QA is gaining more importance since the various systems in production are still inflicted with bugs. These defects lead to unexpected down time to the business. The financial loss caused due to bugs and downtime is higher. Bugs in mission critical applications may be catastrophic. And the board is becoming responsible for the unexpected business loss due to bugs. 
 
As a test engineer you perform your role. Verify and validate the system for the business user requirements. Even if you detect hundreds of bugs nobody will appreciate it because you are performing your job. But when one unknown defect is unearthed in production it will fire back on the entire QA team. Your role is ensuring that no known bugs exist in the system.  
 
Identify and Improve Processes 
Although test engineers need to work within the defined boundaries of the processes and procedures established within their work environment, there is always room for continuous process improvement. Expect the unexpected. Identify the loose ends in the process and bridge the gaps with innovative quality improvement processes. Analyze the pattern in the defects identified in the previous releases of the application. Tighten the test cases to capture the hidden defects. Perform a complete review for ambiguous statements in the requirements documents, which may give rise to different interpretations and ultimately to bugs in the system. 
 
Develop a Killer Instinct 
Follow this list to help you develop a killer instinct.  
  • Deliver quality.
  • Avoid repetition.
  • Test to destroy.
  • Improve the process.
  • Create knowledge base.
  • Analyze the test results.
  • Verify the test environment.
  • Help others to learn more for you.
  • Do not hesitate to take help from others.
  • Read between the lines in the base line documents.
  • Generate required data to execute all the test cases.
  • Emancipate lateral thinking in developing test cases.
  • Arrive at the gap between various base line documents.
  • Learn the new testing technologies and tools around you.
  • Continue updating your business knowledge. It is because of that business we survive.
  • Improve proper communication. Improper presentation has sent several testers home.
You cannot have your cake and eat it too. Unless the system is put through rigorous testing, the credibility of the QA team will be undermined. Place yourself in the shoes of the business users. Your interaction with others may give rise to different perspectives, which will fine-tune your test cases and help you unearth a hidden bug.


About the Author
Gunasekaran Veerapillai has fifteen years in the banking industry in India with eight years of IT experience with three years of that experience in software testing. He also executed SIT UAT Projects for Citi Bank, Morgan Stanley, and Discover Financial.

Back to Top
 
 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by N S Rajput 10/29/2003

A "Must Read" article for every QA Professional.

 
 
Comment:    
by Raja Kaliyannan 10/27/2003

Really its a good article , How the tester supposed to be and what are all the capabilities a Tester shoud have.

 
 
Comment:    
by Krishna Rajan 10/11/2003

I congratulate the author on his neat presentations of the qualities of an innovative tester and what QA is today. Can nnovativeness be encapsulated to increase tester productivity? If the planning is thorough then ideally "free form" defects should not be encountered during testing. Do all plans really work when you begin to execute as per the execution plan? The tester should also have the capability to "think on his feet", "have his ear to the ground", "not miss the wood for the trees", "find an order in chaos" and above all accept that "change is the only thing that is constant" Good luck and keep writing........

 
 
Comment:    
by Krishna Suri 10/7/2003

This article would open the eyes of the people who are indecisive about testing as their career and for testing folks gives lot of information on their carreer improvement. If one improve his skills on the points listed on the killer instinct, then no doubt he is the innovative tester.

 
 
Comment:    
by Bill Lewis 10/6/2003

Finally someone has written an article about the software testing as a creative endeavor. Most people do no like to test software. On the other hand, there is a special type of individual who does like to test software and has an Engineering perspective. The author has described the professional characteristics I would expect from a good Software Test Engineer. From - Bill Lewis, author of "Software Testing and Continuous Quality Improvement" and the inventor or "SmarTest", a new innovative 3rd generation testing tool. (see www.smartwaretechnologies.com) The author of this article describes the role of a good tester - I will even be...Read On

 
 
Comment:    
by venkatesan kalingamurthy 10/6/2003

Very good article. I agree with author's point on the functionality. Unless otherwise you know the functionality, you can not break the system. But at the same time, person with domain/functionality knowledge alone can not become a good tester. He should be innovative, analytically skillful, able to grasp points immediately and always proactive for information. My strong opinion is that testers should be involved in the initial functional design and specifications drafting to get first hand information. In most of the situations, specs do not reflect the user requirements correctly, which in turn lead to all the problems during User...Read On

 
 
Comment:    
by John smith 10/3/2003

Good piece of article. The QA is gaining importance and this gives some excellent approach to the beginners. Written simply carries content. The activities are to be ordered

 
 
Comment:    
by Jayaraman Vasudevan 10/2/2003

This article has provoked my thoughts on how the species called Homosapient Tester be viewed by other species: -Enjoys breaking things > An attitude of "must get job ecstasy" from finding problems -Ruthless > Compromise is last word -Creative > New and different ways to break "it" -Persistent > Won't give up and always find more bugs without getting bugged ! -Diplomatic > Always be in perfect control & an assertive team player

 
 
Comment:    
by Jayatheerthan Sundararajan 9/26/2003

Good and tidy article on quality tester. I would like to add one more point is that current generation tester is expected not only to cover the incidents in the system under test but also on the requirements or baselines. The challenges are more for the tester to cover the incidents in the document. This is because the testers are expected to know the domain, business analysis, current business practices of the customer/user, environment and culture. Moreover, tester is expected analyse the requirements with the proposed system. In my viewpoint, cracking the requirements, design will yield better returns on investments rather cracking at...Read On

 
Back to Top


Marketplace
Subscribe to Better Software Magazine
Subscribe to Better Software Magazine

First Name:

Last Name:

Email Address:


Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2009 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


Borland

HP



STAREAST 2009