enadmin@gvsquare.comISTQB * GV²http://www.gvsquare.com/forums/f_23/ISTQB * GVsquare.com<![CDATA[Which Software Testing Career Path and Certif]]> http://www.gvsquare.com/forums/f_23/m473163.html By: SELA Canada

Which Software Testing Career Path and Certification is Right for You?

Are you wondering which ISTQB certification is right for you? The following is a short explanation of the various certifications and the way you might want to proceed based on your career goals. The tricky thing in our industry is the constant change. The skills of today may or may not be marketable tomorrow, so while you’re thinking about what you want to do, you should also consider what you need to do to be able to get or retain the job you want.
Foundation Level – This is where you need to start. This is the gateway certification for all the other ISTQB certifications. This level is designed for beginners all the way up to those who have been in the industry for awhile (or maybe a long while) and need to brush up their skills and update their terminology. One of the fastest ways to fail in an interview is to use the wrong terms for testing processes, documents and techniques. Organizations tend to adopt their own terminology and it helps to have a base of “standard” terminology, particularly before you venture out for an interview.
The Foundation Level is in the process of being expanded to include several extension modules. Right now, the agile extension is due to be available in early 2014 and work is starting on the model-based testing extension. These are separate certifications you can get that are “added on” to your Foundation Level certification.
Advanced Level – This is where you need to start making decisions. What do you like to do? What do you want to do? Where are the most opportunities?
Advanced Level – Test Analyst – If you are not very technically minded, and would rather work with the user, know the business application and apply your skills more for analysis than programming, you want to pursue the Advanced Test Analyst certification. This certification is designed for the strong tester who has a deep understanding of the business domain and the needs of the user. You’ll learn about designing good test documentation, conducting effective reviews, and participating in risk analysis sessions (particularly to help determine the impact of a realized risk to the business user). You’ll learn about how you can contribute the test information (input data, action, expected results) to the test automation effort and you’ll learn about usability testing. You’ll also build upon the test techniques you learned at the Foundation Level and will learn new techniques such as domain analysis and cause-effect graphing, as well as how to test using use cases and user stories. You’ll learn more about defect-based and experience-based techniques so you’ll know how to pick an appropriate defect taxonomy and how to implement traceable and reproducible exploratory and checklist-based testing. Let’s not forget process improvement as well. You’ll learn what to track in your defect management to be sure you have the information to figure out what could be improved in your process and how you can do it. This certification is designed for the person who wants to spend their time testing, not programming or delving into the code or troubleshooting technical issues.
The path for the Advanced Test Analyst at the Expert Level will include a further specialization in usability testing and further development of testing techniques. At this point, these new syllabi are being discussed but will not be available until at least 2015.
Advanced Level – Technical Test Analyst – OK, admit it, you really like to play in the code. You like to review it, program tests to test it and create test automation and tools. If this is describing you, you definitely need to be looking at the Advanced Technical Test Analyst certification. This certification is designed for the technically minded individual who wants to and is capable of programming, both in scripting languages (e.g., python) as well as standard programming languages (e.g., java). You’ll learn how to approach white-box testing to find the difficult problems that are often missed by the black-box testing that is usually done by the Test Analyst. You will learn strong testing techniques that will allow you to systematically test decision logic, APIs and code paths. You will also learn about static and dynamic analysis techniques and tools (stamp out those memory leaks!). You will learn about testing for the technical quality characteristics such as efficiency (performance), security, reliability, maintainability, and portability. You’ll learn how to do effective code and architectural reviews. And, you’ll learn about tools – using tools, making tools, and a little about selecting the right tools. After all, you wouldn't want to accidentally get a tool that creates code mutants (really, that’s a legitimate tool usage) when you really wanted a simulator. And did I mention automation? You will learn the basis for automation that will be built on at the Expert Level.
The Advanced Technical Test Analyst certification is the gateway to the Expert Level for Test Automation (Engineering) and Security. The Test Automation (Engineering) syllabus and the Security syllabus and their associated certifications are likely to be available in 2014 or early 2015.
Advanced Test Manager – Those who can, do, and those who can’t, manage? Well, that’s not usually a successful formula for a test manager. If you are a test manager or want to be one, and you are willing to learn all the necessary techniques and practices to be successful, then this certification is the one for you. You will learn all about test planning, monitoring and controlling for projects but you will also learn about establishing test strategies and policies that can change the course of testing for the organization. You will learn about how to effectively manage, both people and projects, and will learn the importance and application of metrics and estimation techniques. You will learn your role in reviews. You will learn how to effectively manage defects and how to focus on improving the test process. You will also learn the importance and proper usage of tools and be able to set realistic expectations regarding tool usage. So, if you like telling people what to do, and they tend to listen to you, this is probably the right certification for you. However, that said, remember that technical people respect technical people, so rather than just getting the Advanced Test Manager certification, you should think about also getting at least the Advanced Test Analyst certification as well.
The Advanced Test Manager certification is the gateway to the Expert Levels for Improving the Test Process and Test Management. The Expert Level Improving the Test Process certification focuses on various techniques and models that are used for test process improvement. This provides a good coverage of the most popular models and provides information regarding how to approach an improvement effort to net an effective result. The Expert Level Test Management certification focuses on honing those strategic, operational and personnel skills to make you the best test manager you can be. There is significant discussion in the syllabus about how to be sure your department is performing well and is receiving the accolades it deserves. There is also realistic information regarding managing people effectively and dealing with difficult situations.
The Advanced Test Manager certification is also a pre-requisite for the management part of the Expert Level Test Automation certification. This focuses on how to effectively manage an automation project, including getting the right tools, resources, budget and timeframe. This syllabus should be available in late 2014 or early 2015.
Which Way to Go?
It’s entirely up to you. As you can see, there are several ways you can go with the certification path. And remember, for example, you might not want to get the Advanced Technical Test Analyst certification if you are a test manager, but you can always read the free syllabus and learn something even without a big time investment. All the ISTQB syllabi are available for download. They make for interesting reading, even if you are not planning the particular career path that is indicated. Our industry is constantly changing and new syllabi are always in the works. If you plan to head for the Expert Level, it’s a good idea to start planning your path now as that may determine which Advanced certification(s) you will need. Keep an eye on the ISTQB web site for new additions to the syllabus family. And remember to train, not just for your current job, but for the next job you want to get. Right now, the job market is hot for those with the skills of the Advanced Technical Test Analyst. There is always a need for good test managers. Note the emphasis on the word “good”. And, many companies want Advanced Test Analyst’s as well because of the need for black-box testing and strong domain knowledge. Right now, the biggest growth in in the Advanced Technical Test Analyst area, but that can change quickly. Get your training now, so you’ll be ready.
It’s unlikely that we will run out of work anytime in the future because, as long as there are developers, there will be a need for testers. It’s built in job security! Plan and train for your future. It’s looking bright!
Gain Recognition for Your Company
Join companies such as Platinum Partner Blizzard Entertainment in the the ISTQB Partner Program. The ISTQB Partner Program recognizes organizations around the world that have supported the professional development of their software testing staff through ISTQB certification. The Program comprises four levels of partnership (Silver, Gold, Platinum and Global) and the partnership level of an organization is determined through the number of certification points it has accumulated, which relate to the ISTQB Certificates held by staff.
The major benefits of the ISTQB Partner Program include:
·  Permission to use the ISTQB Partnership Program logo (and other permitted marketing material) on your organization’s website
·  Recognition of your organization’s testing professionalism, both in the local and international market
·  Official Recognition Letter, indicating identity/location, validity and level
·  Listing of your organization on ISTQB website
·  Listing of your organization on the CSTB website
·  Special privileges in relation to ISTQB related events and conferences
·  Eligibility to receive the alpha version of new ISTQB Syllabi with the opportunity to contribute to their review
·  Honorary membership of the exclusive “ISTQB Partner Forum” which will allow Partners to receive news on the ISTQB Roadmap.
]]>
<![CDATA[Increasing productivity of SW projects ISTQB®]]> http://www.gvsquare.com/forums/f_23/m473151.html By: SELA Canada

Increasing productivity of SW projects ISTQB® certification can help

Software engineering and software project management are complex activities. Both software development and software management have dozens of methodologies and scores of tools available that are beneficial. In addition, there are quite a few methods and practices that have been shown to be harmful.
In order to evaluate the effectiveness or harm of various methods and practices Capers Jones has developed a scoring method. The data for the scoring comes from observations among about 150 Fortune 500 companies, some 400 smaller companies, and 30 government organizations. Negative scores also include data from 15 lawsuits. The rankings are based on about 20,000 projects that span 50 industries and 24 countries. The analysis is based on the author’s book Software Engineering Best Practices published by McGraw Hill in 2010. Some new data is taken from The Economics of Software Quality published by Addison Wesley in 2012. This version is current through mid-2014.
See the latest ISTQB® in a Nutshell presentation
]]>
<![CDATA[Keynote on "Testing in Agile Team Environment]]> http://www.gvsquare.com/forums/f_23/m351223.html By: SELA Canada

Keynote on "Testing in Agile Team Environment"



The Canadian ISTQB User Group is a totally volunteer-run organization that prides itself on bringing the most interesting topics for Software Testers across Canada. Upon request by the Director of Sela Canada Mr. Eran Barlev to be a keynote speaker. I was privileged and   honored and humbly agreed to do a presentation on the hot trend topic in the Software Testing field. I was excited to share my experience on Agile Testing in Agile team environment, for following reason:

"As more and more organizations are adopting to Agile approach from traditional Waterfall approach, it has become very important to understand how Agile team works and delivers together in a shorter sprint cycle with customer and quality in mind. The International Software Testing and Qualifications board (ISTQB) also understands the significance of the Agile approach and are working towards implementing Agile Examination to certify as Certified Agile Tester."
Registration: http://cstb.ca/istqb-user-group-meeting
There were about 70 software testing professionals attending my keynote session. The audience were active participants and were engaged with me throughout the session. I received great feedback and some requested to even organize another session on Advanced Agile.


]]>
<![CDATA[ISTQB User Group Meeting]]> http://www.gvsquare.com/forums/f_23/m347024.html By: SELA Canada

ISTQB User Group Meeting

Session Overview
Testing in Agile Team Environment
As a QA professional, I have worked in both traditional and Agile development team with a QA background. I understand my new responsibilities to deliver value to the customer sooner and with high quality and less difficulty. The core principle of the Agile team is to build quality in to the product. On other hand, to develop with test based approach. Agile team are highly cross functional, whole-team thinking approach and works in shorter sprint to build, test and integrate continuously, so that quality can be built in to the product.
Address/ Time:
Microsoft Canada Head Office
1950 Meadowvale Boulevard
Mississauga, ON L5N
Canada
Thursday, September 12, 2013 from 6:30 PM to 8:00 PM (EDT)
Register soon as seats are limited.
Why Should I Attend?
As more and more organizations are adopting to Agile approach from traditional Waterfall approach, it has become very important to understand how Agile team works and delivers together in a shorter sprint cycle with customer and quality in mind.
The International Software Testing and Qualifications board (ISTQB) also understands the significance of the Agile approach and are working towards implementing Agile Examination to certify as Certified Agile Tester.
Speaker Biography
Sammy Kolluru brings rich experience in Software Testing and Quality Assurance with proven track record of leadership and commitment to delivering quality software with his unique perspective: effectiveness, efficiency, measurement, visibility. SK1
Sammy joined CSTB as Executive Board Member in January 2010 and ISTQB as Agile Working Group member in 2012. He also provides his expertise as Sr. Analyst, Quality Assurance for Oracle Inc. Prior to this position, Sammy worked at Sitel Corporation and Dell Canada Inc.
Sammy holds PG Diploma certificate in Business Management from George Brown College and Bachelors degree in Engineering from Bangalore University. He also holds Diploma in Software Engineering and is certified as Certified Tester-Foundation level (CTFL).
Sammy publishes his blog “Software Quality Matters” at http://www.istqbcourses.ca/featured-blogs.html
]]>
<![CDATA[2000 software testers are now certified by th]]> http://www.gvsquare.com/forums/f_23/m315737.html By: SELA Canada

2000 software testers are now certified by the CSTB in Canada


The Canadian Software Testing Board (CSTB), a leader in software testing certification in Canada, is excited to announce that it has certified its 2000th software tester in Canada, including Certified Tester Foundation Level (CTFL), Certified Tester Advanced Level- Technical Test Analyst (CTAL-TTA), Certified Tester Advanced Level- Test Analyst (CTAL-TA) and Certified Tester Advanced Level- Test Manager (CTAL-TM).
CSTB certified software testers are being recognized as the most successful software testers in Canada because the practical certification scheme, focuses on the software testing knowledge and skills that software testers need every day.
The CSTB was founded on January 12, 2007 offering ISTQB certification exams in English. On January 15, 2008 the CSTB introduced certification exams in French. Since then, candidates have an option to register for certification exams in either English or French.
In a survey conducted by the ASTQB (American Software Testing Qualifications Board), 89% of the software testers that took the survey indicated that they are more valuable to their organization since receiving their first ISTQB software testing certification.  83% of the software testers also indicated they are more systematic in their testing.
]]>
<![CDATA[An evening with the Software Testing Experts]]> http://www.gvsquare.com/forums/f_23/m279241.html By: SELA Canada

An evening with the Software Testing Experts sponsored by Sela Canada and Microsoft Canada

Sela Canada, an ISTQB accredited training provider and Microsoft Canada sponsored an open event  at Microsoft headquarters in Mississauga, ON. This event  featured " Requirements-Based Testing including Cause-Effect Graphing" by Gary Mogyorodi, President of The Canadian Software Testing Board .
I, as an Executive CSTB Board Member and Raymond Rivest, Senior Advisor at CRIM were present in the Expert panel. I presented the benefits and importance of the ISTQB and CSTB certification and also introduced CSTB social media activities to about 100 audiences. This event was also telecasted live on www.istbbcourses.ca.
Eran Barlev, Director of Sela Canada and Jody Mooney, Executive CSTB Board Member also participated in this event.
This event covered following topics:
  • The 12 point Requirements-Based Testing (RBT) process.
  • How the RBT process stabilizes the completeness of the specifications early in the development    process.
  • The two components of RBT, Verification and Validation including a verification technique called Ambiguity Reviews to drive out ambiguities from requirements.
  • Tools to translate Cause-Effect Graphs into logical test cases and evaluate previously existing test libraries to cover the problem description. 
  • Gaining perspective of this calibre will help you be an indispensable resource in the software testing process

For more information and pictures, please visit  http://www.istqbcourses.ca/2012-mar.html


























]]>
<![CDATA[ISTQB® Software testing certifications exceed]]> http://www.gvsquare.com/forums/f_23/m279240.html By: SELA Canada

ISTQB® Software testing certifications exceed 200,000

ISTQB® announces that as of Dec 31, 2011 more than 200,000 software testing certifications have been issued world-wide.
ISTQB® would like to congratulate to all the stakeholders that have been involved in this achievement, making ISTQB® the world leader, with certifications issued in more than 70 countries.
The full press release can be found at http://www.istqb.org/newsevents/news/news-2012.html]]>
<![CDATA[An evening with the Software Testing Experts sponsored ]]> http://www.gvsquare.com/forums/f_23/m267410.html By: SELA Canada

An evening with the Software Testing Experts sponsored by Sela Canada and Microsoft Canada

Sela Canada, an ISTQB accredited training provider and Microsoft Canada sponsored an open event  at Microsoft headquarters in Mississauga, ON. This event  featured " Requirements-Based Testing including Cause-Effect Graphing" by Gary Mogyorodi, President of The Canadian Software Testing Board .
I, as an Executive CSTB Board Member and Raymond Rivest, Senior Advisor at CRIM were present in the Expert panel. I presented the benefits and importance of the ISTQB and CSTB certification and also introduced CSTB social media activities to about 100 audiences. This event was also telecasted live on www.istbbcourses.ca.
Eran Barlev, Director of Sela Canada and Jody Mooney, Executive CSTB Board Member also participated in this event.
This event covered following topics:
  • The 12 point Requirements-Based Testing (RBT) process.
  • How the RBT process stabilizes the completeness of the specifications early in the development    process.
  • The two components of RBT, Verification and Validation including a verification technique called Ambiguity Reviews to drive out ambiguities from requirements.
  • Tools to translate Cause-Effect Graphs into logical test cases and evaluate previously existing test libraries to cover the problem description. 
  • Gaining perspective of this calibre will help you be an indispensable resource in the software testing process

For more information and pictures, please visit  http://www.istqbcourses.ca/2012-mar.html


























]]>
<![CDATA[ISTQB® Software testing certifications exceed 200,000]]> http://www.gvsquare.com/forums/f_23/m267409.html By: SELA Canada

ISTQB® Software testing certifications exceed 200,000

ISTQB® announces that as of Dec 31, 2011 more than 200,000 software testing certifications have been issued world-wide.
ISTQB® would like to congratulate to all the stakeholders that have been involved in this achievement, making ISTQB® the world leader, with certifications issued in more than 70 countries.
The full press release can be found at http://www.istqb.org/newsevents/news/news-2012.html]]>
<![CDATA[Official CSTB banner has been launched]]> http://www.gvsquare.com/forums/f_23/m76883.html By: SELA Canada

Official CSTB banner has been launched

The Canadian Software Testing Board unveiled the official CSTB banner during the board of directors meeting held in March 2012. 
About the CSTB: The CSTB (Canadian Software Testing Board) is the Canadian national branch of the ISTQB (International Software Testing Qualifications Board). As such, it advocates education and examination as a practical means to excel in the software testing field. The CSTB is one of many national boards participating in the ISTQB. www.cstb.ca.]]>
<![CDATA[Requirements-Based Testing including Cause-Ef]]> http://www.gvsquare.com/forums/f_23/m65282.html By: SELA Canada

Requirements-Based Testing including Cause-Effect Graphing

In many organizations, testing is viewed as slowing down the delivery of the system, partly because it is the last step in the development process. Ironically, when testing is properly deployed, with heavy emphasis on Requirements-Based Testing, it can have a major impact on overall project productivity as well as product quality.                                           
Many organizations also have discovered that capture/playback tools require a significant investment in building and maintaining test scripts. They also discover that the scripts cannot keep up with rapidly changing specifications.
This presentation will address how a Requirements-Based Testing (RBT) process provides major productivity gains. The RBT process stabilizes the completeness of the specifications early in the development process. RBT is made up of two components that support Verification and Validation.  RBT uses a verification technique called Ambiguity Reviews to drive out ambiguities from requirements.  It also uses a test case design technique called Cause-Effect Graphing that derives an optimized set of test cases that covers 100% of the problem description. The results are fewer tests with greater functional coverage, shortened time to delivery, reduced costs of development, and significantly improved quality.
This is an open event, however space is limited so register now
Register now to discover:
  •  The 12 point Requirements-Based Testing (RBT) process
  •  How the RBT process stabilizes the completeness of the specifications early in the development process
  • The two components of RBT, Verification and Validation including a verification technique called Ambiguity Reviews to drive out ambiguities from requirements
  • Tools to translate Cause-Effect Graphs into logical test cases and evaluate previously existing test libraries to cover the problem description
  • Discussion with Expert Panel:
    • Gary Mogyorodi, President of CSTB
    • Sammy Kolluru, Executive CSTB Board Member 
    • TFS Expert 
Gaining perspective of this calibre will help you be an indispensable resource in the software testing process.
Hosted by SELA Canada and Microsoft Canada
Where:
Microsoft Office
1950 Meadowvale Blvd., Mississauga,
ON, L5N 8L9
Thursday, Mar 29, 2012,
from 6:00PM to 8:30PM


]]>
<![CDATA[istqb]]> http://www.gvsquare.com/forums/f_23/m52883.html By: Liat T*

ok great! I will do that (both).

Thank you very much. We're landing in February, I'll be glad to contact you upon arrival.

 

Thanks, 

Liat.

]]>
<![CDATA[ISTQB in Canada]]> http://www.gvsquare.com/forums/f_23/m52582.html By: SELA Canada

Hi Liat,

 

The CTFL certificate is recognized world-wide.

 

You can contact the ISTQB Canadian office to add your name to it so local employers can find you there to confirm your certififace. (http://www.cstb.ca/)

Re your finding job efforts, once you land feel free to contat SELA's Canadian office and we'll be glad to assist in any way we can.

Sela Canada Website

 

]]>
<![CDATA[Diploma Scope]]> http://www.gvsquare.com/forums/f_23/m52579.html By: Liat T*

Hi,

I took the test for the ISTQB foundation level abroad and passed it.

Soon we'll be moving to Toronto. Will the diploma be recognized?

Do you think it'll help me find a job?

]]>
<![CDATA[Origin of Alpha and Beta Test]]> http://www.gvsquare.com/forums/f_23/m52329.html By: SELA Canada

Origin of Alpha and Beta Test

The term beta test applied to software comes from an early IBM hardware product test convention dating back to punched card tabulating and sorting machines. Hardware first went through an alpha test for preliminary functionality and small scale manufacturing feasibility. Then came a beta test to verify that it actually correctly performed the functions it was supposed to and could be manufactured at scales necessary for the market, and then a c test to verify safety.

With the advent of programmable computers and the first shareable software programs, IBM used the same terminology for testing software. Beta tests were conducted by people or groups other than the developers. As other companies began developing software for their own use, and for distribution to others, the terminology stuck and now is part of our common vocabulary.

]]>
<![CDATA[Testing definition]]> http://www.gvsquare.com/forums/f_23/m52328.html By: SELA Canada

Testing definition

Testing is a process used to help identify the correctness, completeness and quality of developed computer software.
]]>
<![CDATA[Release Life Cycle]]> http://www.gvsquare.com/forums/f_23/m52330.html By: SELA Canada

Release Life Cycle

The term release candidate refers to a version with potential to be a final product, ready to release unless fatal bugs emerge. In this stage, the product features all designed functionalities and no known showstopper-class bugs. At this phase the product is usually code complete.

Microsoft Corporation often uses the term release candidate. During the 1990s, Apple Inc. used the term "golden master" for its release candidates, and the final golden master was the general availability release. Other terms include gamma (and occasionally also delta, and perhaps even more Greek letters) for versions that are substantially complete, but still under test, and omega for final testing of versions that are believed to be bug-free, and may go into production at any time. (Gamma, delta, and omega are, respectively, the third, fourth, and last letters of the Greek alphabet.) Some users disparagingly refer to release candidates and even final "point oh" releases as "gamma test" software, suggesting that the developer has chosen to use its customers to test software that is not truly ready for general release. Often, beta testers, if privately selected, will be billed for using the release candidate as though it were a finished product.

A release is called code complete when the development team agrees that no entirely new source code will be added to this release. There may still be source code changes to fix defects. There may still be changes to documentation and data files, and to the code for test cases or utilities. New code may be added in a future release.

]]>
<![CDATA[Top 10 strategic Technologies for 2010]]> http://www.gvsquare.com/forums/f_23/m52332.html By: SELA Canada

Top 10 strategic Technologies for 2010

Ever wondered which would be the strategic technologies that have the potential to significantly impact an organisation's growth in the next three years? The technologies that would be at the forefront of an organisation's long-term plans, programmes and initiatives.
Research firm Gartner has listed top 10 strategic technologies that will help organisations transform and grow.
However, according to David Cearley, vice president and distinguished analyst at Gartner, "This does not necessarily mean adoption and investment in all of the technologies. They should determine which technologies will help and transform their individual business initiatives.”
Here's over to the top 10 strategic technologies for 2010
Cloud computing
Cloud computing is a style of computing that characterizes a model in which providers deliver a variety of IT-enabled capabilities to consumers. Cloud-based services can be exploited in a variety of ways to develop an application or a solution. Using cloud resources does not eliminate the costs of IT solutions, but does re-arrange some and reduce others. In addition, consuming cloud services enterprises will increasingly act as cloud providers and deliver application, information or business process services to customers and business partners.
Advanced analytics
Optimization and simulation is using analytical tools and models to maximize business process and decision effectiveness by examining alternative outcomes and scenarios, before, during and after process implementation and execution. This can be viewed as a third step in supporting operational business decisions. Fixed rules and prepared policies gave way to more informed decisions powered by the right information delivered at the right time, whether through customer relationship management (CRM) or enterprise resource planning (ERP) or other applications.
The new step is to provide simulation, prediction, optimization and other analytics, not simply information, to empower even more decision flexibility at the time and place of every business process action. The new step looks into the future, predicting what can or will happen.
Client computing
Virtualization is bringing new ways of packaging client computing applications and capabilities. As a result, the choice of a particular PC hardware platform, and eventually the OS platform, becomes less critical. Enterprises should proactively build a five to eight year strategic client computing road-map outlining an approach to device standards, ownership and support; operating system and application selection, deployment and update; and management and security plans to manage diversity.
IT for green
IT can enable many green initiatives. The use of IT, particularly among the white collar staff, can greatly enhance an enterprise’s green credentials.
Common green initiatives include the use of e-documents, reducing travel and teleworking. IT can also provide the analytic tools that others in the enterprise may use to reduce energy consumption in the transportation of goods or other carbon management activities.
Reshaping the data center
In the past, design principles for data centers were simple: Figure out what you have, estimate growth for 15 to 20 years, then build to suit. Newly-built data centers often opened with huge areas of white floor space, fully powered and backed by a uninterruptible power supply (UPS), water-and air-cooled and mostly empty.
However, costs are actually lower if enterprises adopt a pod-based approach to data center construction and expansion. If 9,000 square feet is expected to be needed during the life of a data center, then design the site to support it, but only build what’s needed for five to seven years. Cutting operating expenses, which are a nontrivial part of the overall IT spend for most clients, frees up money to apply to other projects or investments either in IT or in the business itself.
Flash memory
Flash memory is not new, but it is moving up to a new tier in the storage echelon. Flash memory is a semiconductor memory device, familiar from its use in USB memory sticks and digital camera cards. It is much faster than rotating disk, but considerably more expensive, however this differential is shrinking. At the rate of price declines, the technology will enjoy more than a 100 percent compound annual growth rate during the new few years and become strategic in many IT areas including consumer devices, entertainment equipment and other embedded IT systems.
In addition, it offers a new layer of the storage hierarchy in servers and client computers that has key advantages including space, heat, performance and ruggedness.
Mobile applications
By year-end 2010, 1.2 billion people will carry handsets capable of rich, mobile commerce providing a rich environment for the convergence of mobility and the Web. There are already many thousands of applications for platforms such as the Apple i-Phone, in spite of the limited market and need for unique coding. It may take a newer version that is designed to flexibly operate on both full PC and miniature systems, but if the operating system interface and processor architecture were identical, that enabling factor would create a huge turn upwards in mobile application availability.
Courtesy: OnestopTesting.com]]>
<![CDATA[Test Data Management]]> http://www.gvsquare.com/forums/f_23/m52331.html By: SELA Canada

Test Data Management

Quality and reliability of software applications has been very vital due to increase in applications complexity and scalability. However, it is challenging for Testers to deliver reliability. Test team not only have to follow proper test process and methodologies, but also ensure accuracy of test data. Testers also need to ensure that test data correctly reflects production environment, both functionally and technically.
A well documented Test Data Management (TDM) can help to increase efficiencies and provide greater values. These test datas can be made available with in organization in secure, organized, consistent and controlled manner.
By documenting right test data and test data management strategy, QA teams can get one step closer to reliable testing.]]>
<![CDATA[CAPABILITY MATURITY MODEL (CMM)]]> http://www.gvsquare.com/forums/f_23/m52336.html By: SELA Canada

CAPABILITY MATURITY MODEL (CMM)

CMM describes software process management maturity relative to five levels:

ie., Initial, Repeatable, Defined, Managed, Optimizing

In the Initial level there is a lack of planning and the development of a clear-cut guide that software development teams can follow. Few details of a software process have been defined at this level. Good results are considered miraculous.

In the Second level ie., the CMM Repeatable Process is characterized by a commitment to discipline in carrying out a software development project. And is achieved by : Requirements management, software projects planning, software project tracking and oversight, software subcontract management, software quality assurance, software configuration management.

In the Third level ie., the CMM Defined Process is to guide the structuring and evaluation of a software project. And is achieved by : Organisational process focus and definition, training program, software product engineering, intergroup coordination, peer reviews.

In the Fourth level ie., the CMM Managed Process is for data gathering and analysis and managing software quality, and is achieved by : Quantitative process management, software quality management.

In the Fifth level ie., the CMM Optimizing Process is associated with defect prevention, automation of the software process wherever possible, and methods for improving software quality and team productivity and shortening development time.
]]>
<![CDATA[“Testing” and “Quality Assurance”]]> http://www.gvsquare.com/forums/f_23/m52335.html By: SELA Canada

“Testing” and “Quality Assurance”


Every company has their own functional and organizational uses for the terms, “Testing”, and “Quality Assurance”. To be fair, the actions that are done are more important than what they are called. It is common for Testing activities to be subsets of a larger Quality Assurance Life Cycle.

While Quality Assurance sets out the framework for the implementation of quality in the development and implementation of information technology projects, it is Testing that identifies the impact of Quality Assurance, or the lack of impact, prior to implementation. It is Testing all through the project life cycle that quickly identifies defects, allowing for appropriate timely corrective action.

Not long ago, ad hoc testing was believed to be sufficient and the most junior staff were assigned to test code. With the increased complexity of today’s systems and shorter timeframes to deliver results, the industry no longer believes that to be true. Today’s accepted approach is more formal, evaluating all requirements, considering the associated risks, and then creating a test plan that satisfies not only the project team but the business sponsor. These items of requirement evaluation, risk assessment, and test plan creation are all Testing components of a Quality Assurance Life Cycle.

Testing activities should start at the project kickoff meeting with an early assessment of testing needs. Technical requirements to be tested, such as system performance, must be understood to allow the design to meet those technical requirements, to allow the infrastructure to be sufficiently robust, and to allow test cases to be built to challenge the requirements. Business requirements need to be clearly stated in a manner that makes them “testable.” All constraints need to be stated so that test cases can be formed to examine the results of hitting and exceeding those constraints.

Testing at all phases of the project is critical. It is common knowledge that defects found and corrected early in the life cycle cost the organization far less to correct than those found later on. It also takes less time to correct a defect early in the project than it does as the project progresses. It only makes sense to have Testing be part of the project process right from the beginning.

In order to have the skills to design and execute a formal test plan, formal education and experience is required. The International Software Testing Qualification Board (ISTQB) provides an internationally acknowledged progressive set of examinations to prepare testers and test managers to meet the demands of today’s projects.

If there is one true statement in the Information Technology field, it is that we must always be learning and improving. Testing is no exception and is now a more respected and important part of the industry. A strong test organization made up of qualified staff has become a requirement for a successful Quality Assurance initiative and for project success.


Source: www.cstb.ca
]]>
<![CDATA[Firebug as a dedugging tool]]> http://www.gvsquare.com/forums/f_23/m52334.html By: SELA Canada

Firebug as a dedugging tool

Things that are inevitable in Software Development are bug, bugs, more bugs and Java Script is no exceptions to this rules.
QA/ Testers and developers need tools to help them locate these bugs, and such tool would be Firebug. In very short time, this has become popular among Testers/ QA's and Java Scripts development communities. Firebug is free, open source project and works as plug- ins for firefox browser. This tool was created by Joe Hewitt, co- founder of firefox browser.

Firebug is a debugger in the traditional sense. It lets you pause program execution, step through code line by line, and access the state of variables at any time. It can also examine entire DOM(HTML and CSS), view built-in browser details and easily inspect anything on the page simply by clicking on it. It also includes powerful tool to monitor network traffic. All these goodies are placed within this compact interface.
One of its functionality that amazes me is that, it can identify every single objects on the webpage with useful information like size of the objects and time to load each objects. It also displays the url's and previews of the objects.

Firebug not only lets find and fix the bug in the code, it is also a suitable tool for exploration of web applications. It can help to discove how development teams Java Script works. Exploring others application can be powerful educational experience.

Source: getfirebug.com
]]>
<![CDATA[Why entry-level programmers should not be pla]]> http://www.gvsquare.com/forums/f_23/m52333.html By: SELA Canada

Why entry-level programmers should not be placed in Test organization?

I don't like the idea of taking entry-level programmers and putting them into a test organization because:
(1) Loser Image.
Few universities offer undergraduate training in testing beyond "Be sure to test thoroughly." Entry-level people expect to get a job as a programmer and if they're offered a job in a test group, they'll often look upon it as a failure on their part: they believe that they didn't have what it takes to be a programmer in that organization. This unfortunate perception exists even in organizations that values testers highly.
(2) Credibility With Programmers.
Independent testers often have to deal with programmers far more senior than themselves. Unless they've been through a coop program as an undergraduate, all their programming experience is with academic toys: the novice often has no real idea of what programming in a professional, cooperative, programming environment is all about. As such, they have no credibility with their programming counterpart who can sluff off their concerns with "Look, kid. You just don't understand how programming is done here, or anywhere else, for that matter." It is setting up the novice tester for failure.]]>
<![CDATA[What makes a good Software tester?]]> http://www.gvsquare.com/forums/f_23/m52337.html By: SELA Canada

What makes a good Software tester?

Software Testers are known for their creativity but at the same time are known as sadistic who handles dull or repetitive work. They do share many qualities as developers, but there is important difference that groups them apart from developers.
The few qualities that define good Software testers from my point of views are:
1. Good to know programming.
This can be debated. As most would assume that testers can be staffed with people who have no technical or
programming knowledge. This is not recommended, even though this is common approach.
Here are my few reasons for this section.
Firstly, Software Testers are testing software’s. So without technical background, they can't have real insight
about the kinds of bugs in the applications and the likeliest place to explore them. As we all agree that testers
will never have enough time to completely test the applications, also they'll compromise with available resources and thoroughness. Therefore testers must optimize scare resources, which mean they should focus on where bugs could be likely found.
Secondly, Testing methods are tools and technology intensive. Testing tools as well as products under testing are all built using technical and programming knowledge. Therefore, testers could be in-capable of using most of the test techniques and will be restricted to ad-hoc techniques.
This doesn't mean that testers should have programming training or have worked as programmers, but understanding the logical techniques and experience will be the easiest way to meet the "know programming" requirements.
2. Know the software application.
This is another side of the knowledge coin. The ideal testers should have an insight into how users will interact and exploit the applications features, and also the kinds of errors users are most likely to make. In reality, it is not possible for testers to know both the applications under test and complete programming language, they should be a compromise between the application and the logical architecture.
For example, for testing demand generation software, testers should know how marketers would use the product to automate lead generation and calculate ROI or for online retail order software, testers should know how users could exploit the online security.
3. Practice Intelligence.
There are many researchers conducted to determine what would make ideal testers and the common conclusions made with these researches are that, there are no single bench marks to predict ideal testers. Good testers are also smart people; the single most important quality for ideal testers is raw intelligence.
4. Be Hyper-Sensitive to little things.
Good testers notice little things that others (including programmers) miss or ignore. Testers see symptoms, not just bugs. We know that a given bug can have many different symptoms, ranging from trivial to catastrophic. We know that the symptoms of a bug are in turn related in severity to the cause. Consequently, there is no such thing as a minor symptom-because a symptom isn't a bug. It is only after the symptom is fully explained that we have the right to say if the bug that caused that symptom is minor or major. Therefore, anything at all out of the ordinary is worth pursuing.
For example, the screen flickered this time, but not last time-this is a bug. The report generated is off by 0.01%-great bug. Good testers notice such little things and use them as an entree to finding a closely related set of inputs that will cause a catastrophic failure and therefore get the programmers' attention.
5. Be Tolerant for Chaos.
People react to chaos and uncertainty in different ways. Some cave in and give up while others try to create order out of chaos. If the tester waits for all issues to be fully resolved before starting test design or testing, he/ she won't get started until after the software has been shipped. Testers have to be flexible and be able to drop things when blocked and move on to another thing that's not blocked. Testers always have many unfinished tasks during SDLC. In this respect, good testers differ from programmers. The testers' world is inherently more chaotic than the programmers'.
6. Practice people Skills.
Here's another area in which testers and programmers can differ. You can be an effective programmer even if you are hostile and anti-social; that won't work for a tester. Testers can take a lot of abuse from outraged programmers. A sense of humor and a thick skin will help the testers to survive. Testers may have to be diplomatic when confronting a senior programmer with a fundamental goof. Diplomacy, tact and a ready smile, all works to the independent tester's advantage.
7. Tenacity.
An ability to reach compromises and consensus can be at the expense of tenacity. That's the other side of the
people skills. Being socially smart and diplomatic doesn't mean being indecisive or a limp rag that anyone can walk all over. The best testers are both-socially adept and tenacious where it matters. Good testers can't be
intimidated even by pulling his/her rank. They'll need high-level backing, of course, in order to sign-off the
quality software.
8. Be Organized.
I can't imagine a scatter-brained tester. There's just too much to keep track of to trust the memory. Good testers use files, data bases and all the other characters of an organized mind. They make up checklists to keep themselves on track. They recognize that they too can make mistakes, so they double-check their findings. They have the facts and figures to support their position. When they claim that there's a bug-believe it, because if the developers don't, the tester will flood them with well-organized, overwhelming evidence.
9. Be Skeptical.
That doesn't mean hostile, though. I mean skepticism in the sense that nothing is taken for granted and that all is fit to be questioned. Only tangible evidence in documents, specifications, code, and test results matter. While they may patiently listen to the reassuring, comfortable words from the programmers ("Trust me. I know where the bugs are."), and do it with a smile, they will ignore all such in-substantive assurances.
10. Be Self-Sufficient and Tough.
If testers need love, they don't expect to get it on the job. They can't be looking for the interaction between
them and programmers as a source of ego-gratification and/or nurturing. Their ego is gratified by finding bugs, with few misgivings about the pain (in the programmers) that such finding might engender. In this respect, they must practice very tough love.
11. Be Cunning.
Systematic test techniques such as syntax testing and automatic test generators have reduced the need for such cunning, but the need is still with us and undoubtedly always will be because it will never be possible to
systematize all aspects of testing. There will always be room for that offbeat kind of thinking that will lead to a
test case that exposes a really bad bug. But this can be taken to extremes and is certainly not a substitute for
the use of systematic test techniques. The cunning comes into play after all the automatically generated "sadistic" tests have been executed.
12. Be Technology hungry.
Good testers hate dull, repetitive work. They'll do it for a while if they have to, but not for long. The silliest
thing for a human to do, in their mind, is to pound on a keyboard when they're surrounded by computers. They have a clear notion of how error-prone manual testing is, and in order to improve the quality of their own work, they'll find ways to eliminate all such error-prone procedures.
I've yet to meet a tester who wasn't hungry for applicable technology. When asked why didn't they automate
such and such-the answer was never "I like to do it by hand." It was always one of the following:
(1) "I didn't know that it could be automated"
(2) "I didn't know that such tools existed"
(3) or worst of all, "Management wouldn't give me the time to learn how to use the tool."
13. Be Honest.
Testers are fundamentally honest and incorruptible. They'll compromise if they have to, but they'll righteously
agonize over it. This fundamental honesty extends to a brutally realistic understanding of their own limitations as a human being. They accept the idea that they are no better and no worse, and therefore no less error-prone than their programming counterparts. So they apply the same kind of self-assessment procedures that good programmers will. They'll do test inspections just like programmers do code inspections. The greatest possible crime in a tester's eye is to fake test results.
Reference: onestoptesting.com]]>
<![CDATA[Is there enough time to do through testing?]]> http://www.gvsquare.com/forums/f_23/m52338.html By: SELA Canada

Is there enough time to do through testing?


It is rarely possible to test every possible aspect of an application, every possible combination of events, every dependency or everything that could go wrong in the software application. I believe Risk Analysis is appropriate to most software development projects. This requires judgement skills, common sense and experience. 
I recommend to use  risk analysis, along with discussion with project stakeholders to determine where testing should be focused.
Here are some of the aspects that might require close attention:

  1. Which functionality is most important to the project's intended purpose?
  2. Which functionality is most visible to the user?
  3. What functionality has the largest safety impact?
  4. Which functionality has the largest financial impact on users?
  5. Which aspects of the application are most important to the customer?
  6. Which aspects of the application can be tested early in the development cycle?
  7. Which parts of the code are most complex, and thus most subject to errors?
  8. Which parts of the application were developed in rush or panic mode?
  9. Which aspects of similar/related previous projects caused problems?
  10. Which aspects of similar/related previous projects had large maintenance expenses?
  11. Which parts of the requirements and design are unclear or poorly thought out?
  12. What do the developers think are the highest-risk aspects of the application?
  13. What kinds of problems would cause the worst publicity?
  14. What kinds of problems would cause the most customer service complaints?
  15. What kinds of tests could easily cover multiple functionalities?
  16. Which tests will have the best high-risk-coverage to time-required ratio?

]]>
<![CDATA[What can testers do if the application has a ]]> http://www.gvsquare.com/forums/f_23/m52341.html By: SELA Canada

What can testers do if the application has a functionality that wasn't in the requirement?

I believe, if the application under test has functionalities that was not described in requirement documents, it  indicates deeper problems in software development process. All testers agree that it takes tremendous efforts  to determine the unexpected behaviors of an application under test. It will take serious efforts by testers to identify any hidden functionalities which will result in losing precious time and resources.
As per my experience, if the functionality isn't necessary for the purpose of the application, it should be removed, as it may have unknown impacts or dependencies on the application which were not taken in to consideration by the stakeholders.
If alien functionality (as I call because it was not described in requirement documents) is not removed for what ever reasons it might be, it should be documented in the test plan to determine the added testing needs, resources and additional regression testing needs. Stakeholders and managements should be made aware of any significant risks that might arise as a result of this alien functionality.
On the other hand, if this alien functionality has to be included for minor improvements in the user interface and  its effects on the overall applications functionality ranges from trivial to minor and does not pose a significant risks, it may be accommodated  in the testing cycle with or with out minor changes in the test plan.]]>
<![CDATA[My top 5 common problems in software/ web dev]]> http://www.gvsquare.com/forums/f_23/m52340.html By: SELA Canada

My top 5 common problems in software/ web development process

Software or Web development has many risks associated with it. Some of them may be planning risks, which becomes responsibilities of all stakeholders involved in the project, some may be software risks, which are more closely connected to the day-to-day development process. Other risks may be inherent from general software development or may be specific to the software environment.

Here are the top 5 common problems in web development process.
  1. Poor Requirements: If the functional requirements of the features are unclear, incomplete, too general or requirements that are not testable, there might be a problem in the development process.
  2. Unrealistic schedule: If too much features are to be developed and tested in too little time, problems are inevitable.
  3. Inadequate Testing: If the software is released or published with out adequate testing, no one will know whether or not the software is any good until the customer complains or system crashes, which will guarantee a bad reputation for the organizations and its process.
  4. Additional Feature Requests: Request to add new features during or after the development process is underway is very common practice. This would add tremendous pressure on developers and testers, and the software quality will be compensated if this is not taken in to account during project scheduling process. 
  5. Miscommunication: If customers have erroneous expectations, project managers don't know whats is required, developers don't know what is needed or testers don't have sufficient functional requirements, problems are guaranteed.
]]>
<![CDATA[Why is Usability testing so important?]]> http://www.gvsquare.com/forums/f_23/m52339.html By: SELA Canada

Why is Usability testing so important?


Usability testing is carried out in order to find out if there is any change needs to be carried out in the developed system (may it be design or any specific procedural or programmatic change) in order to make it more and more user friendly so that the intended/end user who is ultimately going to buy and use it receives the system which he can understand and use it with utmost ease.
Any changes suggested by the tester at the time of usability testing, are the most crucial points that can change the stand of the system in intended/end user’s view.  Developers/Designer of the system need to incorporate the feedbacks (here feedback can be a very simple change in look and feel or any complex change in the logic and functionality of the system) of usability testing into the design and developed code of the system (the word system may be a single object or an entire package consisting more than one objects) in order to make system more and more presentable to the intended/end user.
Developer often try to make the system as good looking as possible and also tries to fit the required functionality, in this endeavor he may have forgotten some error prone conditions which are uncovered only when the end user is using the system in real time.
Usability testing helps developer in studying the practical situations where the system will be used in real time. Developer also gets to know the areas that are error prone and the area of improvement.
In simple words, usability testing is an in-house dummy-release of the system before the actual release to the end users, where testers can find loop holes and developer can fix the possible loop holes.
]]>
<![CDATA[What is the Requirements stability metrics?]]> http://www.gvsquare.com/forums/f_23/m52344.html By: SELA Canada

What is the Requirements stability metrics?

Metrics can be very helpful, but only if the value of them is worth the value of the time put in to track them. And keep in mind, metrics are designed to be used for analysis and improvement, not necessarily for management 'on the fly' of current projects. 
                                          
So, while I see the need to track the kind of information one is looking for, I think it would be difficult to get useful metrics if the requirements are not stabilized.
More importantly, what is it you are trying to analyze about the requirements? For what purpose?
If you want to be able to better analyze the requirements and how to go about testing them, then try to implement some sort of weighting practice. Have the business side prioritize requirements based on how critical they are to have in a particular (or first) release of the application. Have the technical people estimate the amount of effort required to implement, and it should be easier to plan development and testing based on that sort of matrix.
If you're concerned about change, consider using a requirements management tool- there are commercial apps, or do something as simple as keeping a spreadsheet of the current requirements at a high level, and tracking changes to each requirement. Try to implement some level of change management or change control through your defect tracking system - defects can be written do documentation as well, and can track change requests as easily as actual errors. ]]>
<![CDATA[What is the purpose of good test case?]]> http://www.gvsquare.com/forums/f_23/m52343.html By: SELA Canada

What is the purpose of good test case?


Test cases are the bread and butter of software testers. Test cases created either manually or automated, has many objectives. Writing a effective test cases is arts which are acquired by skills and experiences. The topic for the effective test cases will depends on the types of project you are handling and the depth of functional requirement to be captured. 
See full size image

Writing a kind of test cases falls in to many categories. Each categories provides respective values to the organization in many different ways.  In order for the test case to provide better values for an organization, it should be essentially functional to reduce risks and address the testing efforts and also it should provide some measurable values to the organization.

There are various categories for writing an effective test cases. Following are some of the categories, most of the test cases would fall under:
  • To verify the expected results versus actual results during testing cycle.
  • To verify if the application under test is in conformance with the standards and guidelines as requested by the stakeholders.
  • To increase the functional test matrix coverage.
  • To increase the data flow coverage.
  • To increase the logical flow coverage.
  • To verify and execute end user scenarios.
  • To report any errors or defects to developers before it impacts the end users.
]]>
<![CDATA[Have you heard about Monkey Testing?]]> http://www.gvsquare.com/forums/f_23/m52342.html By: SELA Canada

Have you heard about Monkey Testing?

Monkey Testing, interesting terminology, but valuable testing in software industry.
Monkey Testing is nothing but random testing of software application or system on the fly, with out the working knowledge of the application. The goal of the monkey testing is to identify any show stoppers or criticals in the software application under test.
Monkey testings are best performed by the automated testing tools. These automated testing tools will be called as 'monkeys' if they work randomly identifying crash or break in the software code.
Monkey testings are inexpensive to perform some basic random testing which will result in finding very few bugs, where as it could be very expensive for load or performance testing, which can result in number of bugs.
Monkey testing can be valuable for software application to identify rather embarrassing show stoppers, but this should not be only testing performed.]]>
<![CDATA[Why I am a tester? Wrong Reasons]]> http://www.gvsquare.com/forums/f_23/m52348.html By: SELA Canada

Why I am a tester? Wrong Reasons

We have seen many discussions on why people came into software testing and why they still love to work as a tester. People have interesting reasons, for some people its creativity, for some people its challenges of automation, for some its relation to system thinking, domain expertise etc. All of these are good reasons to be in testing field and if you are in testing because of similar reasons, probably you are enjoying your work and may be exciting people around you about testing.
Unfortunately, over the years I have seen many people staying as tester because of wrong reasons as well. Following list is the collection of wrong reasons / motivation to be in software testing field and work as a tester. If you are in testing because one of these reasons, probably you need to find a good mentor, understand testing properly or change your field. 


Well that is a strange reason, but true nevertheless. Many testers memorize two responses - did not follow best practices and process was not followed correctly for every failed project. It is always possible to find at-least one process which did not work and one best practice which was not followed in every failed project. You can always give same response to most of the failures in testing project.
 
Good testers do not believe in best practices and finds the best way to work in a given context. Even if the project on which they are working is failed, they will retrospect and find opportunities to improve next time rather than opening a process book.
 
I hope you are not working as a tester because of these, and if you are probably you'll start thinking about it. 

1. Software Testers can be Lazy

Software testing could be the perfect job for lazy people. There are so many things you need before start testing the product. You can happily wait for documentation, changed documentation and final documentation and documents describing some more changes after the final documentation. You can also wait for software to be delivered in test environment, defect tracking system to be setup and configured properly, Finalize the process which needs to be followed, testable system and list can just go on. As a tester, you can find thousands of things which can prevent you from testing the system.
 
Some of these things are important, really important. What you need to do is think about them and see are they really blocking you or becoming an excuse for you? Good testers will always find ways to start testing as soon as they can. They'll work with analysts, developers, infrastructure etc. to make sure they can test the system. Even if they are not testing, they will probably think about data, users, automation or anything which will make them more efficient rather than waiting. 

2. Software Testers can preserve grey cells

Some testers feel that grey cells are precious and they make all the effort to ensure that mind is not exercised / challenged. Following test scripts manually is perfect way to preserve these precious grey cells. I remember someone telling me - I'll happily follow written scripts and not apply my brain as long as I am getting paid. Surely you are getting paid, but are you enjoying the process? Does it not become boring for you? Do you feel good and proud about the work you are doing? Also, even if you are following the script, are you not observing things which are not part of the scripts?
 
For real testers, constant exercise and challenges to the mind is one of the main reasons to be in testing field. They continuously ask questions, make observations, write note, talks to people about the product. They don't preserve, but enhance their mind by continuously exercising and challenging it.

3. Software Testers can blame anyone

As a testers, there is always opportunity to blame someone for your failures. You can blame BAs for changing requirements, infrastructure for not providing test environment, developers for not writing unit tests, introducing regression defects and delivering late and management for not giving enough importance to testing and cutting time for testing.
 
Now I am not saying that these are not problems. Some of these could be real problems but good testers will highlight these problems and find ways to work rather than finger pointing and finding ways to avoid work. 

4. Software Testers can fake

It is very easy for testers to get away without actually working on anything. In most of the cases, management does not have right appreciation or tools to check your progress as a tester. It is extremely easy to say that you have tested this feature without testing it. In many organizations progress is checked with yes / no questions along with some numbers and it is extremely difficult for anyone to make sense from these answers.
 
Good testers on the other hand, make sure that progress is traceable. They do not answer in yes / no but explains what part is tested, how it is tested and what is not tested. They provide information rather than data and maintain integrity of their profession.

5. Software Testers do not need to learn

Developers need to learn new things constantly. This could be new languages, frameworks, platforms, algorithms and so on. Testing on the other hand is relatively static. You can argue that you do not need to be technical so wont learn new technologies. Definitions and techniques of testing are very old and hardly used so you do not need to learn that. You can also leave domain knowledge to the business analysts and not learn about domain and so effectively you do not need to learn anything to survive in the testing field.
 
Testers who love their job though have appreciation for the technologies and platforms. Even if they are not technical, they will find out how this program was built, what made them choose this platform, language etc. Similarly, they will try to understand domain to find out how a typical user would use this system. They will make themselves familiar with many tools to increase their efficiency. Constantly learning new thing is one the main motivation for them to work as a tester.

6. Software Testers can become expert easily

Becoming an expert is extremely easy in testing. There are so many certifications which claim to make you an expert probably in a month. You can always claim your supremacy by flaunting various certifications you have acquired by memorizing all the definitions. In many organizations, management will promote you for becoming experts (by acquiring certifications) without actually working.
 
Good testers usually do not consider themselves expert. They do not rely on certification agencies to certify their excellence. They are just good learner and learns few new things every day and are on the journey to become an experts. They are probably involved in or have appreciation for movement like weekend testing rather than syllabus of any certification program. 

7. Software Testers can confuse people

If you love to confuse people, you can do so very easily if you are a tester. There are different definitions and interpretation of almost every term we use in testing. You can find completely different definitions for ad-hoc, exploratory, v-model etc. and probably most of them are wrong anyways. You can have endless discussion on why priority and severity are different and needed. You can argue endlessly about defect life cycle, best processes on version control, environment control and so on. In most of the cases, irrespective of what people are doing, how they are doing testers can find out at-least one thing which should be changed in-order to improve quality.
 
Some testers prefer to work though and it doesn't matter what names you give to the techniques they are following. Their focus is on the improving quality, but not by talking about it but working for it. They do suggest change, but by showing the real value of why it should be changed rather then where a specific process is being followed.

8. Software Testers get paid without adding real value

As a tester, it is extremely easy to do whatever you are instructed to do. Now there is nothing wrong with that but often the person who is instructing you to perform testing does not understand testing. If you do not think hard and continuously, it is very easy to test as instructed but without testing as a good tester. In situation like this, you are testing as good as the person who is instructing you / have written scripts for you.
 
Real tester, even under instruction will not stop thinking about the problems and ways in which product can be tested. There will always be questions which needs investigations or new ideas which analysts have not covered or missing data set you need to test. They always find ways to add value in the project of every size and in every stage.

9. Software Testers can Play with numbers

Playing with numbers could be another favourite activity for many testers. Number of test cases, number of automated test cases, number of defects, number of defects in every status, developer tester ratio, unit test coverage and list can go on and on. It is always possible to answer most of the testing questions in numbers without giving any additional information. Testing is 50% complete or 70% of the test cases are automated can have different meanings to different people. Numbers doesn't give any useful information in itself.
 
Good testers on the other hand give sensible and useful information rather than random numbers. I am not saying that good testers do not prepare any matrix, they do that but they also explain what these numbers are telling. 


 


Re-published from reliable source.]]>
<![CDATA[What's Web-Enabled Application Measurement Te]]> http://www.gvsquare.com/forums/f_23/m52347.html By: SELA Canada

What's Web-Enabled Application Measurement Tests?

  1. Meantime between failures in seconds
  2. Amount of time in seconds for each user session, sometimes know as transaction
  3. Application availability and peak usage periods.
  4. Which media elements are most used ( for example, HTML vs. Flash, JavaScript vs. HTML forms, Real vs Media Player vs. QuickTime)
]]>
<![CDATA[What testers can do if there is not enough in]]> http://www.gvsquare.com/forums/f_23/m52346.html By: SELA Canada

What testers can do if there is not enough information for creating requirement matrix?

If testers are not getting requirements in a way that it is usable to create requirement traceability matrix, and assuming that they have the time, I recommend taking the knowledge of the system that they have and writing their own test requirement matrix. These kinds of matrix should be used internally for traceability. This method has worked for me in the past. 


The best outcome was that, as the word of these requirement matrix got out to other groups in the company, they began to see the value of them and made our testing efforts more efficient and they wanted to see what it could do for them, resulting in requirements adoption.]]>
<![CDATA[What would it take to make software testing e]]> http://www.gvsquare.com/forums/f_23/m52345.html By: SELA Canada

What would it take to make software testing effective?

I think that following qualities are essential to make software testing effective:
  •  Successful testing efforts are determined by the quality of the testing process.
  •  Deploy early testing life cycle techniques to prevent defect migration.
  •  To improve testing process, real person must own their responsibilities.
  •  Testing is a professional discipline. It requires continuous training and skills improvements.
]]>
<![CDATA[Best Practices For Regression Testing]]> http://www.gvsquare.com/forums/f_23/m52351.html By: SELA Canada

Best Practices For Regression Testing

SDLC defines that when a defect is fixed, two forms of testing are to be done on the fixed code. The first is confirmation testing to verify that the fix has actually fixed the defect and the second is a regression test to ensure that the fix itself, hasn't broken any existing functionality. It is important to note that the same principle applies when a new feature or functionality is added to the existing application. In the case of new functionality being added, tests can verify that the new features work as per the requirement and design specifications while regression testing can show that the new code hasn't broken any existing functionality.
It is possible that a new version of the application will have fixed previously reported defects as well as having new functionality. For the 'fixes' we would normally have a set of  Test Scripts (Test cases) which are run to confirm the fixes, while for the new functionalities we would have a set of  Functionality test cases.
Overtime, as the software application becomes bigger and bigger in terms of new functionality and more components are added, a regression pack, which is a bank of test cases, is developed to be run on new version of the application which is to be released.
Selecting tests for regression packs
As explained earlier, for each new release of software application, three sets of test suites are executed; Regression Tests, Release Specific Tests and Defect Test Scripts. Choosing test cases for regression packs is not a trivial exercise. Careful thoughts and attention need to be paid on choosing the sets of tests to include in the regression packs.
One would expect that as each new test case written for Release Specific Tests, they will become part of the regression pack to be executed after the next version of the code is arrived. So, in other words, the regression pack becomes bigger and bigger as more and more new versions of the code is developed. If we automate regression testing, this should not be a problem, but for a manual execution of large regression packs, this can cause time constraints and the new functionalities may not be tested due to lack of time.
These regression packs often contain tests that cover the core functionality that will stay the same throughout the evolution of the application. Having said that, some of the old test cases may not be applicable anymore as those functionalities may have been removed and replaced by new functionality. Therefore, the regression test packs need to be updated regularly to reflect changes to the application.
The regression packs are a combination of scripted tests that have been derived from the requirement specifications for previous versions of the software as well as random or ad-hoc tests. A regression test pack should, at a minimum, cover the basic workflow of typical use case scenarios. "Most Important Tests" i.e. tests which are important to the application domain should always be included in the regression packs. Successful test cases, i.e. tests which have revealed defects in the previous versions of the application are also a good candidate to be included in the regression packs.]]>
<![CDATA[Shout out by Joe Payne, CEO and President, El]]> http://www.gvsquare.com/forums/f_23/m52350.html By: SELA Canada

Shout out by Joe Payne, CEO and President, Eloqua

On March 24, 2010, I reluctantly woke up as I normally do and got ready to work. Took the transit to work  and reached my desk little late. Made my breakfast, Quakers Instant oatmeal and office coffee. So far this is my daily routine. No change and no surprises.
A card enclosed in a envelope was placed on my desk by Executive Assistant for CEO. I curiously opened the card. I was expecting new years greeting card. To my surprise, it was hand written note from CEO and President of Eloqua,  Joe Payne. This is what Joe has to write about me.
"March 24, 2010


Sammy- Just a quick note to say, thanks for all the efforts you have been putting in on the testing of Eloqua 10. Abe and Andre tell me that you have gone out of your way to help the team get up to speed.

WELL DONE- JOE"
I was extremely happy and greatfull for the recognition.]]>
<![CDATA[Functional vs non-functional testing]]> http://www.gvsquare.com/forums/f_23/m52349.html By: SELA Canada

Functional vs non-functional testing

Functional Testing:
Testing the application against business requirements. Functional testing is done using the functional specifications provided by the client or by using the design specifications like use cases provided by the design team.


Functional Testing covers:
  • Unit Testing
  • Smoke testing / Sanity testing
  • Integration Testing 
  • Interface & Usability Testing
  • System Testing
  • Regression Testing
  • Pre User Acceptance Testing(Alpha & Beta)
  • User Acceptance Testing
  • White Box & Black Box Testing
  • Globalization & LocalizationTesting
Non-Functional Testing:
Testing the application against client's and performance requirement. Non-Functioning testing is done based on the requirements and test scenarios defined by the client.

Non-Functional Testing covers:
  • Load and Performance Testing
  • Stress & Volume Testing
  • Compatibility & Migration Testing
  •  Data conversion Testing
  • Security / Penetration Testing
  • Operational Readiness Testing
  • Installation Testing
  •  Security Testing (Application, Network and System security)
]]>
<![CDATA[Training by ISTQB Leaders]]> http://www.gvsquare.com/forums/f_23/m52352.html By: SELA Canada

Training by ISTQB Leaders

2012 Course Calendar
Training by the President of the CSTB

Training by ISTQB LeadersGary Mogyorodi, President of CSTB


SELA Canada is excited to have Mr. Gary Mogyorodi, the President of the CSTB teach the following classes:
1) ISTQB Certified Tester Foundation Level
Dates: January 11-13, 2012 | 9am - 5pm
Course Overview:
This course provides test engineers and test team leaders with the main ideas, processes, tools and skills they need in order to set themselves on a path for true testing professionalism. This hands-on course covers the major test design techniques with lecture and exercises.

2) ISTQB Certified Tester Advanced Level Test Manager
Dates: January 23 - 27, 2011 | 9am - 5pm
Course Overview:
Being a technical manager is hard enough, but managing the testing process is a unique challenge, requiring judgment, agility, and organization. The course covers the essential tools, critical processes, significant considerations, and fundamental management skills for people who lead or manage development and maintenance test efforts.

3) ISTQB Certified Tester Advanced Level Test Analyst
Dates: February 27 - March 2, 2011 | 9am - 5pm
Course Overview:
This training course gives detailed information on the specifics of different testing techniques: specification based techniques; defect and experience based test techniques, their characteristics, their boundaries – all is done while extending the range of their usage.



]]>
<![CDATA[1000 software testers certified by the CSTB]]> http://www.gvsquare.com/forums/f_23/m1206.html By: SELA Canada

 

The Canadian Software Testing Board (CSTB), a leader in software testing certification in Canada, is excited to announce that it has certified its 1000th software tester in Canada, including Certified Tester Foundational Level (CTFL), Certified Tester Advanced Level- Technical Test Analyst (CTAL-TTA), Certified Tester Advanced Level- Test Analyst (CTAL-TA) and Certified Tester Advanced Level- Test Manager (CTAL-TM).

CSTB certified software testers are being recognized as the most successful software testers in Canada because the practical certification scheme, focuses on the software testing knowledge and skills that software testers need every day.

The CSTB was founded on January 12, 2007 offering ISTQB certification exams in English. On January 15, 2008 the CSTB introduced certification exams in French. Since then, candidates have an option to register for certification exams in either English or French.

In a recent survey conducted by the ASTQB (American Software Testing Qualifications Board), 89% of the software testers that took the survey indicated that they are more valuable to their organization since receiving their first ISTQB software testing certification.  83% of the software testers also indicated they are more systematic in their testing.

A message from CSTB president Gary Mogyorodi about this important milestone.

 “This is a momentous occasion for the CSTB.  We are pleased with our results to date, but will continue to strive to improve the profession of software testing in Canada.”

For more information about the CSTB and the list of certified testers, please visit www.cstb.ca or email cstb@cstb.ca This e-mail address is being protected from spam bots, you need JavaScript enabled to view it or call 416-538-1650.

About the CSTB: The CSTB (Canadian Software Testing Board) is the Canadian national branch of the ISTQB (International Software Testing Qualifications Board). As such, it advocates education and examination as a practical means to excel in the software testing field. The CSTB is one of more than 40 national boards participating in the ISTQB. www.cstb.ca.

About the ISTQB: It is the ISTQB's role to support a single, universally accepted, international certification scheme, aimed at software and system testing professionals, by providing the core syllabi and by setting guidelines for accreditation and examination for member boards. www.istqb.org.

]]>
<![CDATA[Greetings for the new forum!]]> http://www.gvsquare.com/forums/f_23/m1201.html By: GV²
New forum created!

We wish you an enjoyable use of the system.]]>