Connecting Practice

The following are another free Quality Assurance and Software Testing tools for best, good, or emerging free Quality Assurance and Software Testing tool identification and evaluation. Enjoy the list below.

Tracking System

1. f2w Helpdesk - f2w Helpdesk is a helpdesk support system based on requests (some people call them tickets), with a simple web interface. Requests can be classified into categories and assigned a priority… read more | New

Test Automation

1. BuildBot - The BuildBot is a system to automate the compile/test cycle required by most software projects to validate code changes. By automatically rebuilding and testing the tree each time something has changed, build problems are pinpointed quickly… read more | New

Unit Testing

1. C Unit Tester - C Unit Tester (CUT) is designed to aid the C (or C-derived language) programmer in implementing unit or programmer tests, primarily to facilitate test-driven development practices… read more | New

2. jf-unittest - jf-unittest is a C++ unit test framework modeled after the way the Python unittest module is used in the Confix test suites. It was written out of frustration with the existing unittest frameworks… read more | New

Memory Usage Tracker and Leak Finder

1. MemCheck Deluxe - MemCheck Deluxe is a memory usage tracker and leak finder. It allows developers to find memory leaks quickly, as well as providing some memory usage information… read more | New

2. Memwatch - Memwatch is a fault tolerant (can repair its own data structures) memory leak and corruption detection tool. You add a header file to your souce code files, and compile with MEMWATCH defined or not… read more | New

3. diapergluforth - diapergluforth lets you access functions in shared object libraries without having to recompile against the library’s header files. It also tracks buffer allocations and automatically frees them when you exit… read more | New

4. memcheck - memcheck provides the ability to fault on pointer overrun (read or write) or freed pointer deference (read or write), logs double free and realloc of already freed pointers and memory not freed on exit, checks for pointer underrun on free and realloc… read more | New

PNG, JNG, and MNG Testing

1. pngcheck - pngcheck verifies the integrity of PNG, JNG and MNG files (by checking the internal 32-bit CRCs [checksums] and decompressing the image data); it can optionally dump almost all of the chunk-level info in the image in human-readable form… read more | New

In developing a software organization’s policy and strategy, one can manage their Tracking System tools to support and improve their operation and total life cycle performance. And in the light of the impact on business, society, customer and people, the following are free Tracking System tools for best, good, or emerging Tracking System tool identification and evaluation.

Tracking System

1. Bosco - Bosco is a rewrite of the popular Bugzilla defect tracking software in PHP. It is database-independent, and aims to be easy to maintain and modify. It also has an API to allow external applications to work with its data… read more

2. Bug-A-Boo - Bug-A-Boo is a bug reporting and tracking system that runs on any Web server that supports CGI. It can handle any number of projects, users, and bug classifications, and is really flexible in their setup… read more

3. Bugdar - Bugdar is a free, fast, and powerful bug tracker just took another large leap in terms of features and speed. Bugdar 1.2 hosts a series of new features, but fixes, speed enhancements, and minor tinkering… read more

4. Bugtrack - Bugtrack is a Web-based bug tracking system written in Perl. It supports multiple users and projects with multiple components and versions, provides e-mail notification, and should work with any DBI compliant database… read more

5. Bugzilla - Bugzilla is the leading open-source/free software bug tracking system. It is server software designed to help you manage software development… read more

6. Double Choco Latte - Double Choco Latte is a system for tracking bugs, changes and enhancements to software, and requests for software. It is suitable for multiple products and multiple accounts (clients)… read more

7. EnterTrack - EnterTrack is an open source web-based artifact tracking/management system written in PHP. EnterTrack is derived from Issue-Tracker v4.0.1 (www.issue-tracker.com) and adds a number of features particularly useful to larger groups… read more

8. Eventum - Eventum is a user-friendly and flexible issue tracking system that can be used by a support department to track incoming technical support requests, or by a software development team to quickly organize tasks and bugs… read more

9. GNU GNATS - GNU GNATS is a set of tools for tracking bugs reported by users to a central site. It allows problem report management and communication with users via various means… read more

10. Mantis - Mantis is a free popular web-based bugtracking system. It is written in the PHP scripting language and works with MySQL, MS SQL, and PostgreSQL databases and a webserver. Mantis has been installed on Windows, Linux, Mac OS, OS/2, and others… read more

11. OTRS - OTRS is an Open source Ticket Request System with many features to manage customer telephone calls and e-mails. It allows your support, sales, pre-sales, billing, internal IT, helpdesk, etc. department to react quickly to inbound inquiries… read more

12. RT: Request Tracker - RT is an enterprise-grade ticketing system which enables a group of people to intelligently and efficiently manage tasks, issues, and requests submitted by a community of users… read more

13. Roundup - Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry “Track” design competition… read more

14. gwyple - gwyple is a GUI, implemented in Perl and Perl/Tk, for handling bug reports. These reports usually arrive by email, are stored by helper scripts called from procmail, and can then be organized by gwyple independently from the used BTS… read more

15. pg Request Tracker 2/3 Report - pg Request Tracker 2/3 Report is a set of tools for generating reports for Request Tracker 2/3 (RT 2/3). Currently, it only supports the Postgres (”pg”) and MySQL backends… read more

16. phpBugTracker - phpBugTracker is a web-based bug tracker with functionality similar to other issue tracking systems, such as Bugzilla. Design focuses on separating the presentation, application, and database layers… read more

17. phpSupport 5.0 - phpSupport 5.0 is your customer friendly trouble ticket system. With 5.0 you allow users to register to open trouble tickets and keep track of their tickets… read more

And what are the inputs, guidelines, and outputs to bear in mind in obtaining estimates for testing phase of a software project?

Inputs

• Defined statement of project scope for clear goals and focus work
• Defined user requirements - use cases and functional specs for delivering the required functionality
• Defined technical requirements
• Other supporting documents

Guidelines to create a detailed estimates

• Determine all the effort (lists of tasks the testing work entails) to be performed. This includes getting all the next actions visible.
• Determine complexity of the system.
• Form initial estimate for each task. This includes involving the individuals who will be doing the tasks to figure out how long a task will take based on their experience implementing similar things.
• Assign each task a ‘risk.’ Assign ‘High‘ risk to tasks that you lack knowledge and/or experience; assign ‘Medium‘ risk to tasks that you are familiar with and can complete the tasks; and assign ‘Low‘ risk to tasks that you are confident about and/or have been done many times before.
• Document any other risks that might affect the test work deliverables to address and bring test work in on time.
• Document assumptions made. Note that each task figure should be accompanied by a note on the assumption(s) that you’ve made in coming to this figure and/or interpreting the task requirements.
• Apply adjustments and reserve allowances to account for external factors that the project will depend upon. External factor examples: Tasks that require approval; incomplete component from another project - here document the effect of the dependency if task is not being met; and failure from delivering the required component to a satisfactory standard that cause development delays.
• Include contingency in the estimate. The contingency should be listed separately. If tasks need to use some of the contingency for certain reasons then the Lead should ask the PM for a portion of the contingency. The reasons for needing to use some of the contingency will be discussed and the impact on the test work timelines will be shown in the test plan and shared with the team.

Guidelines to schedule the test work

• Work out how many people will be needed on the team in order to complete the test work in the required time.
• Add test work milestones. Note that every test work task listed in the estimate should become a task in the schedule.
• Assign test work tasks to people who have the skills needed to do the task. There should be some gaps between tasks to represent risk.
• Add dummy tasks to represent known outages, such as: Public holidays, annual leave, training courses, and so on.
• Try to move high risk tasks as near to the beginning of the schedule as possible so that there is as much time as possible to deal with problems.
  Ensure that dependencies between tasks are respected - reorganise the schedule if necessary.
• Keep the schedule up-to-date with latest progress and changes regularly.

Outputs

• A project schedule with allowances for risk, internal dependencies, and known outages
• A list of other assumptions made during the estimation
• A list of the project’s external dependencies
• A list of other risks to the project schedule

Join QAST Practitioner Group, download the attached sample detailed estimate template file in MS Excel version, and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=60.0

The attached sample detailed estimate template file is meant to be used to create detailed estimates for testing phase (support and regression testing) of a software project.

In “How Can You Develop A Test Specification Documents?” topic, it describes the specific activities to perform and achieve the development of test specification documents. In this piece, it describes the typical contents of test specification template for documenting test cases characteristically below.

Template Header
1. Project number - It should describe the project number accurately.

2. Test Specification name - It should describe the test specification name clearly.

Template Details
1. Test No. - It should describe the test number to ensure every test cases in a project has a unique number for traceability. Note: To ensure every test case in a project has a unique number for traceability, this number should start with the Use Case number (for example Use Case 3 Search, numbering will be 3.1, 3.1.1, 3.2, etc.) - 3.1, 3.2, etc will be section headings and not have tests associated with them, while 3.1.1…., 3.2.1 will contain the test cases. If a test does not have a Use Case associated with it, the test number must start with 0. There must be no blank rows in the “Test No.” column (Column A).

2. Tracking No. - It should describe the associated defect tracking number reference with the particular test case for traceability.

3. Found in Build - It should be the date of the build when the test case was run.

4. Use Case No. - It is important for traceability of every test case that this number matches the use case number.

5. Subject, Object, or Function Name - It should be the subject, object, or function Name where the test case was run.

6. Test Case Description - It should be clear, concise, and accurately describe the test case. It should have some mandatory fields like:

• Objective - General objective of the test case that clearly and accurately describe it.
• Pre-Test Condition - Optional, Pre-requisite for testing the feature
• Verification - Optional, Need to verify against the pre-condition or requirement
• Steps to Reproduce - It should be the clear step by step instructions on how to reproduce the test case. It should provide a verbatim transcript of the session and show what commands you typed and what output in response. It should be minimized and easy-to-follow steps.
• Expected Behavior - It should be the description of the correct or expected results where the defect is not present.
• Actual Result - It should be the clear and detailed description of what happens after the step by step instruction are followed. If you saw test failures then describe the errors, carefully and precisely, what they were. The developers need to know what has gone wrong. If available, include the error message number to get information or search for clues.

Important:

• All scenarios must be considered including negative testing.
• Boundary Analysis must be performed.
• It is not simply a case of sticking verify in front of each requirement - analysis must be carried out for completeness, effectiveness and efficiency.
• If something is not clear in the use case, now is the time to raise questions and ensure the answers form part of this document - it’s too late in the test execution phase.
• Consider information and/or things you will need to support testing, again now is the time to request for these information and/or things.

7. Test Data - Test Data to support every single test scenario must be included

8. Run - It is used to indicate which test are to be run for re-testing and regression testing. Setting the field to 1 indicates that the test case must be executed for re-testing.

9. Pass/Fail

• Pass - Test Passed
• Fail - Test failed if the actual results differ significantly from the test expectations.
• Can’t Test (CT) - A bug in another piece of functionality is restricting you from running this test
• Functionality Not available (FNA) - Functional no longer available or will be available in further phases
• Not Tested - Leave the pass/fail cell blank if you decide not to test the test case.

10. Comment - It should be any additional comments - keep them as consise as possible.

11. Tested By - It should be the tester’s name for traceability and accountability.

12. Tested Date - It should be the date when the test case was run.

13. Test Time (Hours)

• Estimated - Time estimated to execute test case
• Actual - Actual time spent executing test case (include time logging Defects, etc.)

14. Guidelines

a. The layout / format must not be changed from the original template.
b. There must be no blank rows in the “Test No.” column (Column A).
c. To insert further rows to allow you add more defects, highlight a row and click insert row (standard excel). Do not highlight row 5 when inserting rows!
d. If you need to add more test cycles, highlight the last eight columns and copy, then highlight the next eight columns and paste. Don’t forget to change the test cycle number. If you follow this instruction the formulas will also be copied and work!
e. Remember, you must keep the revision history sheet updated. If you update something - put a comment in the revision history. All test cycles must be tracked in the revision history. This number should match the SI revision number - this makes rolling back easier if needed.
f. To group test cases for convenience:

• Click on Data
• Then Settings
• Select “Summary Columns to right of detail” only
• Steps 2 and 3 will only need to be done once
• Select rows beneath your heading that you wish to group (heading should not be selected)
• Click Group and select Rows (Data/Group and Outline/Group)

Join QAST Practitioner Group, download the material in MS Excel version, and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=56.0

As I downloaded the latest stable version of Mantis, I am blogging about it.

Mantis is a free popular web-based bug tracking system. It is written in the PHP scripting language and works with MySQL, MS SQL, and PostgreSQL databases and a webserver. Mantis has been installed on Windows, Linux, Mac OS, OS/2, and others. Almost any web browser should be able to function as a client. It is released under the terms of the GNU General Public License (GPL).

The main features include:

1. Free (GPL License)
2. Easy to Install (both internally and in hosted environments).
3. Easy to evaluate:

• Demo
• InstantMantis - Be up and running in 2 minutes (not recommended for production use)

4. Simple User Experience
5. Web Based
6. Supports any platform that runs PHP (Windows, Linux, Mac, Solaris, AS400/i5, etc)
7. Available in 68 localizations.
8. Simple/Advanced Issue Pages
9. Multiple Projects per instance
10. Support for Projects, Sub-Projects, and Categories.
11. Users can have a different access level per project
12. Changelog Support
13. Roadmap
14. My View Page
15. Search and Filter

• Full Text Search
• Simple/Advanced Filters
• Shared Filters (across users / projects)

16. Built-in Reporting (reports / graphs)
17. Custom Fields
18. Email notifications
19. Users can monitor specific issues
20. Attachments (can be saved on webserver or in database - can also backup to an FTP account)
21. Issue Change History
22. RSS Feeds (news, issues matching saved filters, issues matching a specific project)
23. Customizable issue workflow
24. Sponsorships Support - users are able to place bounties or sponsorships for specific issues, also developers can track such sponsorships / payments.
25. Anonymous Access
26. Signup with Captcha and Email Confirmation.
27. Self-Service Reset Password Support
28. Export to csv, Microsoft Excel, Microsoft Word
29. Ability to extended functionality through hook (custom) functions.
30. Reporting issues via Email (available as a patch - currently being integrated)
31. Reporting Issues via a custom form on your website (Anonymantis).
32. Source Control Integration (SVN and CVS).
33. No limit on the number of users, issues, or projects.
34. Wiki Integration (optional)
35. Time Tracking
36. Ability to send messages to messages to other users in regards to a specific issue.
37. Public / Private Projects - Public project accessible to all users, private are only accessible to those explicitly added.
38. Public / Private Notes - Private notes are accessible to users with a specific access level to the relevant project.
39. Public / Private Issues - Private issues are accessible to users with a specific access level to the relevant project.
40. Issue Relationships
41. Issue Relationship Graphs (uses “dot” library).
42. Attachment Auto-Preview
43. Public / Private News (news can be associated with a specific project, or with all projects).
44. Sticky Issues (always appear on the top of the issues list).
45. Group Actions: actions can be applied on multiple issues.
46. Easy hyperlinks to issues and issue notes (e.g. #123 hyper links to issue number 123).
47. Ability to view recently visited issues (the last 5 visited issues are visible by default at the top right corner).
48. Authentication

• Default Mantis Authentication (recommended)
• LDAP Integration
• HTTP Basic Authentication Support
• Active Directory Integration (patches available)

49. Chat Integration (optional)
50. Multi-DBMS Support - Mantis uses ADODB as an abstraction library to support multiple DBMSes.

• MySQL
• MS SQL
• PostgreSQL
• Oracle (experimental)
• DB2 (in progress)

51. Webservice (SOAP) interface (MantisConnect)

• A SOAP web service that is implemented in PHP and can be consumed from any language that supports SOAP web services.
• .NET Client Library
• Java Client Library
• Cocoa Client Library
• Eclipse Plugin
• NAnt Task
• Mantis Notifier

52. Support for mobile devices (MantisWAP).
53. Online Chat (optional integration)
54. There are community projects that integrate it with content management and project management too
55. Twitter Integration allowing users to monitor updates (Added in release 1.1.0a4)

Join QAST Practitioner Group and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=59.0

In “How to Report Bugs Effectively?” topic, one can identify the twofold strategy below to provide defect information effectively to developers.

1. Show the defects to the developers personally; Or
2. Provide all the information that the developers need; give them careful and detailed instructions on how to make it fail in the same way; and/or find pattern, symptoms, and/or answers to their own defects that concern them to know the cause. More information is almost always better than less - Simon Tatham. The intention is to enable them to reproduce the defects.

Moreover, reporting defects are task of showing or documenting the defects so that the developers responsible for repairing the defects can reproduce the failures and fix the defects.

Further, one can document the defects using a template for reporting defects, tracking defect status, and generating test summary report. The typical contents of the template for documenting defects includes:

Template Header

1. Project number - It should describe the project number accurately.

2. Test Specification name - It should describe the project test specification name clearly.

Template Details

1. Defect No. - It should describe the defect number to ensure every defects in a project has a unique number for traceability.

2. Tracking No. - It should describe the associated defect tracking number reference with the particular defect for traceability.

3. Priority - It should correspond to how urgent it is that the defect be fixed. If the defect needs to be fixed immediately, it should have its priority set to P1 (P1 being the highest priority and P5 being the lowest). Most serious bugs should have their priority set to P2.

P1 - Very High
P2 - High
P3 - Medium
P4 - Low
P5 - Very Low

Moreover, priority should be based on the failed functionality importance and the risk of failure to the business. Where possible the priority should be assigned based on discussions between QA group, Project Manager, BA, and Software Development Lead.

4. Dev Assigned - It should be the assigned developer for fixing a bug.

5. Reported By - It should be the tester’s name for traceability and accountability.

6. Reported Date - It should be the date when the defect was recorded.

7. Found in Build - It should be the date of the build when the defect was found.

8. State - It should be New, Open, or Closed.

9. Status - It should be:

• Disregarded - Defects that were disregarded in the bug report.
• NTReview - Defects that were New in the bug report for review.
• CNNWE - Defects that were Closed-NeverFix as not worth the effort.
• CWAD - Defects that were closed-Withdrawn as designed.
• CWCR - Defects that were closed-Withdrawn as cannot reproduce.
• CWD - Defects that were closed-Withdrawn as duplicate.
• CWNAB - Defects that were closed-Withdrawn as not a bug.
• CWTP - Defects that were closed-Withdrawn as third party.
• CWUE - Defects that were closed-Withdrawn as user error.
• CDLI - Defects that were closed-Deferred as Low Impact.
• Withdrawn - Defects that were closed-Withdrawn.
• OTClosing - Opened Defects that were found for closing.
• Fixed - Defects that were closed as fixed.
• ToTest - Defects that were opened to test.
• ToFix - Defects that were opened to fix.
• ToDefer - Defects that were opened to defer. It will be addressed in a later release.
• OTNMI - Defects that need more information.
• OTCR - Defects that can’t reproduce, functionality no longer available, or will be available in further phases. It is returned when the person assigned cannot replicate the incident.
• OTHNI - Defects that have new information.
• OTHD - “Defects that have dependency or a bug in another piece of functionality is restricting you from running this test.
• OTFNMI - Opened ToFix Defects that need more information.
• OTFHNI - Opened ToFix Defects that have new information.
• NNMI - New Defects that need more information.
• NCR - New Defects that can’t reproduce.

10. Bug Severity - It should correspond to the seriousness of the defect. it should be set to Critical, Major, Minor, or Low severity type. Severity Types are scheme to assist the project team in identifying the severity of the defect and managing the defect log.

Moreover, the number and severity level of open defects may affect timely completion of a project, so it is important to a have a consistent approach to assign severity level to errors; and critical that everyone know how to identify the severity of defects, and how severity levels affect the delivery of the system.

The following are definition of severity levels for defects. Notice that in addition to identifying what the severity levels are, we also present some example of what types of defects qualify for each severity. This helps the project team subjectively in deciding the severity of an error.

Critical: Business process and system functionality are SEVERELY affected - software HALTS. In most cases, they are defects in which will not allow the tester to proceed with the tests - a system inoperable or showstopper issue. Critical defects must be corrected before the code is released to production. Examples are as follows:

• Endless loop - A sequence of instructions in a computer program that are constantly repeated. In most cases, you get an incomplete page displays, or are unable to control the status of the mouse.
• Fatal errors - A condition that halts processing due to program bugs, read errors, or other anomalies. In most cases, generally you cannot recover from it.
• Program Hangs - A condition that software stops responding.

Major: Business process and system functionality are seriously affected; system and/or data is exposed to potential loss or interruption. It is a severe error that causes a program not to perform properly or to produce unreliable results. Normally, the user cannot find an appropriate “workaround” for this type of error. Also it needs immediate attention. It must be corrected before the code is released to the production. Near-term system workaround is required. Examples are as follows:

• Computation errors - Incorrect/Inaccurate calculation - a great deal. Sign errors are surely the most common errors of all. Causes: Loss of invisible parentheses, belief that a minus sign means a negative number, or out of formula/carelessness.
• Incorrect functionality - Fails to satisfy the target specifications or requirements.
• Erroneously displayed/unexpected display of error messages
• Database/table errors

Minor: Business process and system functionality are moderately affected - software is not at risk. Critical system(s) and/or data are not at risk. It needs to be resolved as soon as possible but not a showstopper. Also it is an error in which a “workaround” solution can be found or available for the user. These defects do not significantly impact the execution or performance of the software and need not necessarily be corrected before the code is released to production. Examples are as follows:

• If you click the button, the code does not work, but if you choose the command from the menu, it works fine.
• Incorrect display - In most cases, it is a condition wherein the display contains inconsistencies with the specification or requirement documents.
• Incorrect location - In most cases, it is a condition wherein the display contains inconsistencies with the specification or requirement documents.
• Data was excluded from display - In most cases, it is a condition wherein the specified or required data is not displayed.
• Unexpected behavior of link - In most cases, link is broken and goes not to the correct/intended page.
• Unexpected display of alert message - In some cases, the system responds with an alert message to the user.
• Major grammatical errors in warning/error messages
• Incorrect value for essential fields in the logs
• Obvious cosmetic errors in screens
• Incorrect default values

Low: Business process and system functionality are marginally affected or unaffected. System(s) and/or data are not at risk. In most cases, they are defects in which minimal error, a cosmetic change, or an enhancement is needed. Low level defects do not need to be corrected before release to production. Examples are as follows:

• Incorrect format
• Undeleted line space
• No line space
• No space between character
• Undeleted character
• Undeleted text
• Wrong alignment
• Wrong caption
• Wrong spelling
• Minor grammatical errors
• Wrong text position on screen
• Wrong data position on screen
• Wrong window position on screen

11. DC No. - It should be the defect category Number for analysis.

12. Subject, Object, or Function Name - It should be the subject, object, or function Name where the defect was found.

13. Defect Description - It should be clear, concise, and accurately describe the defect with actual facts so that developer doesn’t have to come looking for tester to get them. and it should have some mandatory fields like:

• Title - General description of the defect that clearly and accurately describe the defect.
• Steps to Reproduce The Bug - It should be the clear step by step instructions on how to reproduce the bug. It should provide a verbatim transcript of the session and show what commands you typed and what output in response. From Development point of view, it is very important. It should be minimized and easy-to-follow steps.
• Actual Result - It should be the clear and detailed description of what happens after the step by step instruction are followed. If you saw test failures then describe the errors, carefully and precisely, what they were. The developers need to know what has gone wrong. If available, include the error message number to get information or search for clues.
• Expected Behavior - It should be the description of the correct or expected results where the bug is not present.

14. Remarks - It should be any additional comments - keep them as consise as possible.

15. Screen Dump - It should be the captured image that could help in motivating developers to fix bugs that are hard to recreate.

16. Test Time - It should be the estimated (Time estimated to re-test the bug) and actual (Actual time spent re-testing the bug) in hours.

Join QAST Practitioner Group, download the material in MS Excel version, and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=58.0

Beginnings are important in a company that your quality assurance and software testing work is just started. It is then that expectations are formed. These early stages involve:

1. Gaining access to the developers at the outset; and
2. Forming effective relationships with the developers, and maintaining it. This includes developing and concentrating on the most important aspects of your relationship with the developers, such as:

• Rapport - Rapport is that state of interaction where you and the developers are “in tune.” The initial step in building rapport is to give all your attention to the developers.
• Assertiveness - It is when you engage to prove that you can look after yourself to commit, promote, and contribute quality change.

Moreover, in ensuring that you and developers have the sort of relationship that can weather any project issues, use your influencing styles to influence them in any actions and/or events. In this, you may consider any of the guidelines below:

1. Expressing values - Here your values about what is good or bad and important or unimportant features in a project touch a chord in developers and you capture interest. You invoke respect and admiration. You attract developers by strengthening what is good and important project features to achieve results.

2. Getting ready with the undertaking - Here you utilize and review general requirements and supporting documents. You think about what needs to be done, develop ideas, and collaborate with developers for assistance and information. You attract developers by understanding the project facts.

3. Ensuring that quality goals and objectives are clearly understood by developers - Here you provide coordinated plans. By setting plan, you manage situations and channel efforts. You attract developers by providing and bringing direction into their thinking.

4. Creating “pictures” of a desirable results - Here you are able to communicate what needs to be done to create a better results; bring developers to a quality review; expose them to the complexities and potential quality problems, technical issues, concerns, exceptions, assumptions, and/or risks; and give them understanding of what could happen. You attract developers by expressing readiness, practicality, and awareness.

5. Developing schedule - Here you negotiate work loads and time for project planning and estimation. You enable developers to identify needs, evaluate options, formulate action programs, and take initiatives for themselves. You attract developers by collaborating with them for agreement and decision making.

6. Presenting information - Here you collect data, evaluate information, built a logical case, make valid points, and appeal to reason to develop test specifications. You work closely with the developers to review use cases; describe the test cases clearly, concisely, and unambiguously with actual facts; and develop correct and accurate test data. You attract developers by demonstrating logically sound artifacts.

7. Finding defects - Here you identify developer’s defects, supply all the information, and show how these can be fulfilled to get the fix faster. You work at being a useful and helpful resource to them in providing all the information that they need, giving them careful and detailed instructions on how to make it fail in the same way, and/or finding answers to their own defects that concern them to know the cause. You attract developers by reporting defects effectively.

8. Finding issues - Here you identify specific project issues from inception, design, development, product rollout, product updates, and support in daily work. You record, analyze the risk, communicate, and join in the conversation with them. You attract developers by reporting issues effectively.

9. Meeting schedule - Here you deliver quality products. You meet the functional specifications that have been defined and ensure that defects are captured and fixed in the project before reaching our client’s environment. You attract developers by achieving specified quality goals and objectives within specified time and resource constraints.

10. Identifying and recommending improvements to quality process - Here you cause developers to discover that the current quality process is, in some ways, inadequate. You establishing quality standards, templates, checklists, criteria, guidelines, procedures, tools, and metrics in the framework of the quality initiative. This includes giving them quality process training. You attract developers by causing them to re-evaluate their works around them and learn new ways of thinking.

This piece is a quality material file which supports quality guidelines.

Join QAST Practitioner Group and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=57.0

The following specific activities could be performed to achieve the development of test specification documents:

1. Develop task satisfying activities and progress tracking system.

2. Identify specific issues or choices outside and inside the situation that should be addressed, confronted, and reinforced in assessing readiness to engage in the undertaking. This usually involves various driving forces, or major influences, that might effect in getting ready to engage in the process. Example: Shortcomings to subject knowledge, experience, and expertise on this area; support; time; etc.

3. Obtain and examine what resources available to engage and devote in the undertaking, such as project objectives, requirements, use cases, etc. Note: Ensure the most effective use of available resources by focusing on the key priorities.

4. Review/Verify objectives, requirements, and/or use cases for correctness and completeness. Use the reasoning process to identify and eliminate incomplete, unclear, incorrect, and ambigious words, phrases, and constructs. Ask “What” most of the time. The intention is to understand the objectives, requirements, and/or use cases and improve their quality for better test design, execution, and results. Note: Arrange meetings at regular intervals with the users for issue clarifications - Issues must be precise and only relevant points should be discussed. Must be very particular in asking inquiries/questions.

5. If appropriate, validate requirements and/or use cases against objectives - Compare requirements and/or use cases to the objectives, if requirements and/or use cases do not belong in the process scope. This includes applying use cases against requirements - Use cases must satisfy requirements. Otherwise, use cases are incomplete.

6. Design, develop, refine, and further the list of functionalities and test cases to fill the gaps in test coverage by:

• reviewing the list of functionalities and test cases by working closely with the requirement’s author - A problem with the list of functionalities and test cases must be redesigned;
• working closely with the user to validate the list of functionalities and test cases - Let users obtain a better understanding of what the deliverable system will be like; and
• reviewing the list of functionalities and test cases by working closely with the developers - Developers understand what they are going to be tested on, and obtain a better understanding of what they are to deliver so they can deliver for success.

This includes:

• developing the full and complete list of functionalities that have to be tested;
• describing the displaying the page(s), navigating on the page(s), and inserting/updating/deleting event actions test cases clearly, concisely, and unambiguously; and developing correct and accurate test data;
• facilitating the team meeting for the list of functionalities and test cases review; and
• Updating the list of functionalities and test cases after review.

7. Use the list of functionalities and test cases for testing.

Join QAST Practitioner Group and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=56.0

I would like to assume that the quality manager had already established his quality management group separately from software development group for overcoming the challenges comes from quality problems mentioned in the first post.

Moreover, in a company that faces a problem of continuous steady growth and in need of quality improvement methods and/or programs to strengthen their software team and help them to improve the quality of their deliverable, the quality manager needs to:

PHASE I: Define and incorporate the quality plan with the project team in parallel work with his/her facilitation in the implementation of the support group’s test works and other groups focusing on developing the project test specifications; finding bugs using regression testing and other forms or types of testing; reporting bugs; and identifying specific project issues. This includes:

• defining clearly the desirable project quality goals and targets with the project sponsor and client;
• defining and integrating an effective and efficient quality process for the entire software development process to reach those goals and targets;
• defining the various roles and responsibilities of an organization-wide quality system;
• communicating readiness, recommendations, technical issues, concerns, exceptions, assumptions, and/or risks;
• Establishing a visible staging, test live (used in user acceptance testing), and live environment;
• Establishing a visible defect or issue tracking and reporting system; and
• Defining and integrating a visible project planning and tracking where each stage of SDLC within project is analyzed to identify the possible risks that a project faces. This includes creating testing strategies (planning and estimate) based on identified risks.

PHASE II: Establish a visible change management that focuses on release (a number of changes are collected together into a release) and configuration (defines baseline and control changes) management.

PHASE III: Measure the effectiveness of the quality process. This includes:

• Monitoring the quality process; and
• changing the quality process as needed to keep it effective.

Join QAST Practitioner Group and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=10.0

Experience the power of the world class SQE Training courses’ Free.

See first hand why many Fortune 500 companies from varying industries take SQE Training courses. This two-hour seminar is full of practical advice for your test team members at no charge to you.

Read more…

Join QAST Practitioner Group and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=51.0

A new version of a system is made as fix to some faults or response to changes in its required specifications. In this case, regression testing must rerun as a partial operational requirements after completing the first round of testing.

Moreover, regression testing is time consuming. To limit this, consider the following activities:

1. Generate traceability matrix for optimized test coverage during the requirement phase.
2. Review the test documents and base lining based on impact analysis report. This includes updating traceability matrix.
3. Generate the test repository of test condition, test cases, and/or test scripts for the new requirements. This includes reviewing and removing obsolete test condition, test cases, and/or test scripts from the test repository.
4. Add new test condition, test cases, and/or test scripts to the test repository for enhancing test coverage.
5. Ensure that the incorporation and/or modification of program works properly to promote minimal retesting before the execution.
6. Execute the test repository of test condition, test cases, and/or test scripts. Note any of the techniques below need to be rerun during the undertaking:

• only test case does execute any of the modified parts of the program to establish that the modified parts of the program preserves the desired functionality of the old program;
• only test case has effect on the program output to verify that the new or modified program produces correct output on them;
• only test case has effect on the program output when it is evaluated differently; and
• only test case does execute any of the unmodified parts of the program to verify that its behavior is unchanged and ensure that the fixes made to the program do not cause new errors to occur.

7. Update traceability matrix based on analysis report.
8. Update the test repository of test condition, test cases, and/or test scripts.
9. Continue performing regression testing until all the defects fixed and test cycles are over.

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=50.0

Thanks to ohskylab of myBlogLog for finding this.

The “How to Report Bugs Effectively” by Simon Tatham, professional and free-software programmer describes a general procedures on how to report bugs effectively on the site and only key tips are listed here as follows:

• It doesn’t work.
• Show me.
• Show me how to show myself.
• Works for me. So what goes wrong?
• So then I tried . . .
• I think the tachyon modulation must be wrongly polarised.
• That’s funny, it did it a moment ago.
• So I loaded the disk on to my Windows . . .

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=49.0

Given the topic, I feel a need to acknowledge that I have to thank adel shehadeh the owner of testSQUAD blog for finding this software testing tools. The owner’s post (Selenium - a Mozilla firefox Add-ons last May 02, 2007) influences my thinking to share more details about the topic.

Moreover, Selenium IDE is an integrated development environment for Selenium tests. It was made by the folks over at OpenQA.org; it is implemented as a Firefox extension and a very easy to use and powerful tool for controlling, automating or testing web sites that allows you to record, edit, and debug tests; and it includes the entire Selenium Core, allowing you to easily and quickly record and play back tests in the actual environment that they will run.

The following are the features:

• Easy record and playback
• Intelligent field selection will use IDs, names, or XPath as needed
• Auto-complete for all common Selenium commands
• Walk through tests
• Debug and set breakpoints
• Save tests as HTML, Ruby scripts, or any other format
• Support for Selenium user-extensions.js file
• Option to automatically assert the title of every page

Further, some people say that Selenium IDE is awesome and a handy way to test web applications in Firefox. They recommended it.

To know more about Selenium IDE, you may visit:
http://www.dynamitemap.com/selenium

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=48.0

Given the topic, I feel a need to acknowledge that I have to thank the owner of Here for software Testers!!!!!!!!!!! - All about Testing and Quality blog at for finding this guide materials, a good information in choosing a bug tracking system. The owner’s post (Saturday, January 6, 2007) influences my thinking to share more details about the topic.

A Bug Tracking System is constructed as a database. Usually it is designed to make bug tracking activities easy for project team to manage their specific bugs, generate reports, and assess the product (under test) situation on a build-by-build basis.

Moreover, a bug tracking system is evaluated usually by the manager for its viability and the results is reviewed by project sponsor or management for adoption. What could strike, inspire, and/or interest the management as positive about the bug tracking system are its features. The “what’s in it for us” reality could lead the management to approve or reject it.

Furthermore, the quality manager must identify and understand the requirements of the system needed to solve their certain problems and/or concerns before s/he can start to evaluate the bug tracking systems. Identifying and understanding these requirements will help him/her to build a list of features that s/he can use to guide his/her evaluations.

The following observation questions could help the quality manager to identify his/her bug tracking requirements:

• What are the different roles and responsibilities of the people who will use the system?
• What is your workflow for managing and resolving bugs? Identify the steps in the process,
  and determine who is responsible for each step.
• What information do you need to track for each bug?
• What reports and metrics do you need?
• Do you need to provide different levels of access to different users?

Further, the identified requirements for the system can be translated into a feature list. the feature list is the standard attributes or criteria of the system against which the quality of the bug tracking system to be measured or rated.

Below provides an example of a feature list that could be used to evaluate a bug tracking solution based on the identified requirements to achieve:

• Adaptability
• Change history
• Version control integration
• Customizable fields
• Ease of use
• E-mail notifications
• Reports
• Security
• Web-based client
• Workflow

The A Guide To Evaluating a Bug Tracking System By Stephen Blair, MetaQuest Software. The rest of this document provides tips and guidelines for evaluating these features. Hopefully these guidelines will help the quality manager choose a bug tracking system that meets his/her requirements.

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=47.0

Quality Manager is accountable for quality on a project. That is, s/he determines, designs, defines, Develops, organizes, manages, implements, and maintains quality assurance and control mechanisms. This includes:

• observing the disciplines in quality management;
• identifying which Quality Standards are relevant to the project and determines how can they be satisfied;
• identifying the quality materials, procedures, tools, training, organization, and metrics to be used on the project;
• providing support to the organization and ensure compliance with audit and process standards;
• facilitating quality and continuous improvement programs and targets in the organization;
• increasing client satisfaction and ensuring timely and consistent implementation of internal control procedures, deliver quality products, enhance processes, and improve services;
• achieving maximum client satisfaction at the lowest overall cost to the organization while continuing to improve the work, product, service, and/or process;
• helping the project team to solve quality problems;
• promoting and achieving high quality.

Moreover, quality manager must involve the team members in planning for quality. S/he must communicate quality goals and the results of measurements to team members to help them keep quality efforts on track and identify quality improvements. S/he must not relieve team members of their responsibility for quality.

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=17.0

Some of detection methods that can be used to examine the quality of products are as follows:

• Reviews - Personal, peer, pair, management, QA, independent;
• Testing - Structural, functional, integration, stress/performance, regression, field, acceptance;
• Simulations - Prototypes, models;
• Field Trials - Prototypes, beta testing; and
• Mathematical - Proofs of correctness.

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=46.0

Some of the common signs (problems) that show up due to poor quality assurance are as follows:

• deficient document and it’s difficult to interpret;
• fails to meet the business and technical needs;
• unscalable;
• unstable; and
• expensive.

Moreover, some things that can help to solve the problems above are as follows:

• Organization and team structure;
• Practice toolbox selection;
• Professional development;
• Checklists & Templates;
• Reviews and Audits;
• Quality criteria;
• Right Culture; and
• Quality improvement.

Further, two things must be ensured for quality assurance to be effective:

First, the quality plan must be sufficient to achieve the required quality standards expected of the organization. In this regard the plan must not only be specific and detailed listing all quality requirements and standards, but also include all the steps taken to ensure that those requirements and standards are met.

Secondly, quality assurance should be independent of the project itself (as well as the project manager). This comes down from the project management guidelines for effective quality assurance, and builds on a broad-based, organizational approach to standards-based product testing.

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=45.0

In this context, the measurements to track progress toward achieving the quality goals generally fall into two categories:

1. Perception Measures - These measures are of the customers’ perceptions of the organization (obtained, for example, from customer surveys, focus groups, vendor ratings, compliments and complaints).
2. Performance Indicators - These measures are the internal ones used by the organization in order to monitor, understand, predict and improve the performance of the organization and to predict perceptions of its external customers.

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=44.0

A workflow can usually be described using formal or informal flow diagramming techniques, showing directed flows between processing steps. Single processing steps or components of a workflow can basically be defined by three parameters:

1. input description: the information, material and energy required to complete the step
2. transformation rules, algorithms, which may be carried out by associated human roles or machines, or a combination
3. output description: the information, material and energy produced by the step and provided as input to downstream steps.

Components can only be plugged together if the output of one previous (set of) component(s) is equal to the mandatory input requirements of the following component. Thus, the essential description of a component actually comprises only in- and output that are described fully in terms of data types and their meaning (semantics). The algorithms’ or rules’ description need only be included when there are several alternative ways to transform one type of input into one type of output - possibly with different accuracy, speed, etc..

Especially when the components are non-local services that are invoked remotely via a computer network, like Web services, additional descriptors like QoS, availability, etc. have to be considered, too.

Source: Wikipedia, the free encyclopedia

Join QAST Practitioner Group and give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=42.0

Below are some lists of quality reviews that typically are used to help build, measure quality, and prevent defects of work, product, service, and/or process deliverables.

Expert Review. Work, product, service, and/or process deliverables are reviewed by QA member who is considered have expert knowledge in the area to check the accuracy of content. This includes finding and correcting defects in the development of the process. Example: To ensure the information is accurate and well constructed prior to submission to project sponsor and client, the QA member needs to deliver Preliminary Business Case by performing Expert Review using the Template for Business Case and Approved Business Case for the Project.

Self-Checking Review. A self-checking review is usually the initial quality inspection for a task, and it may be the only one. The QA member who performs the task checks correctness, completeness, consistency, and conformance to quality standards and fulfillment of quality criteria.

Peer review. Co-workers carry out the peer review of work, product, service, and/or process structure to check quality, spread experience, and communicate ideas and approaches. They check the output of the task, make constructive suggestions, and take the opportunity to learn. Example: To review the final draft for completeness and construction, one needs to perform Peer Review of final draft.

Multi-person Review. A review carried out independently by several QA members to gain agreement between different stakeholders. Meeting or workshop is carried out to resolve differences and reach agreement.

Walk-through - A useful technique to validate both the content and structure of a deliverable, identify potential problems, uncover inconsistencies, find defects, and educate the audience. It encourages critical analysis and is therefore effective for design reviews. Thus, material should be circulated in advance. If particular participants have not done their homework, they should be excluded from this activity. Example: To review early draft for completeness, QA member needs to deliver Project Definition by performing Walk-through of early draft using the Template for Project Definition.

Workshop. Workshop brings stakeholders together with key developers and a professional facilitator to collectively define, analyze, or review solutions. They can be an effective way to build in and verify quality.

Formal review. The project manager or project team holds formal reviews with the project sponsor and client to obtain agreement on an issue or acceptance of work, product, service, and/or process. The contract sometimes specifies the scheduling and content of formal reviews. Typically, they are held on completion of a milestone. Example: To ensure the Business Case is in a fit state to be submitted to the Finance Review Committee, QA member needs to deliver Final Business Case by performing the Formal Inspection using the Template for Business Case.

Standard Audit. Carried out by QA member who is only focused on ensuring the deliverable meets a particular standard(s) and specification(s). That is, it focuses on compliance with the standard(s) and specification(s). It should be planned and implemented during each phase of the project.

Formal Inspection. A review of a deliverable by an inspector who would typically be external to the project team. The inspector captures statistics on suspected defects. It is a useful technique for use with documentation.

Process Review. A review of existing quality Processes in an organization that determines whether the existing quality processes are being followed and achieving the desired results, all necessary procedures and actions are being undertaken, and information is being recorded. Process Review is usually conducted by Project Office or Internal Audit who are independent from the project team. Moreover, it is appropriate to have processes reviewed for quality once the project is initially established. This may be useful to give the project sponsor and client a level of confidence in the team.

Join QAST Practitioner Group and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=27.0