Connecting Practice

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 “Template Content For Documenting Defects” topic, it describes how one can document the defects using a template for reporting defects, tracking defect status, and generating test summary report. This piece describes the defect workflow used in the template.

Note the defect workflow describes the repeatable pattern of activities, steps, and information in the defect reporting process and determines who is responsible for each activity or step to make the changes. It should be systematic and adaptable for managing and resolving defects.

Join QAST Practitioner Group, download the template and defect workflow material in MS Excel and Word version, and/or give comment(s) at:
http://daniloalsonado.com/qastforum/index.php?topic=58.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

A QA member can carry out the quality review process with a method that cut complex work, product, service, and/or process condition apart characteristically with the following steps:

1. Identify the subject(s) of work, product, service, and/or process condition. The subject serves to tell us what function(s) to review.
2. Identify the end (effect) of the work, product, service, and/or process condition. The end serves to tell us what to be accomplished.
3. Identify the necessary means (causes) of the work, product, service, and/or process condition. The necessary means server to tell us how many ways of acting to accomplish the end cited in the second step.
4. Develop the conclusion (improve work, product, service, and/or process condition). The conclusion serves to tell us that the function(s) cited in the first step is carried out the way mentioned in third step to achieve the end cited in the second step. If appropriate, identify the unexpressed end or necessary means to justify the conclusion.

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

“Quality review is a framework for thought.” This is how I would like to start this piece. It raises and suggests solution to shortcomings to arrive a well-justified conclusion about a given work, product, service, and/or process condition. It is a process that examines work, product, service, and/or process standards and specifications against their intended purpose. Typically what need to be reviewed are the work, product, service, and/or process deliverable.

By any large, the task in reviewing work, product, service, and/or process deliverable cannot be taken for granted. It must be systematic and specific to achieve the validity of the quality results, but the shortcomings to arrive a well-justified conclusion about work, product, service, and/or process condition could fail (satisfy not) the standards and specifications. The premise is that, the lack of understanding on a certain form about work, product, service, and/or process condition affecting or influencing the project team decision-making due to ignorance. The lack of understanding due to ignorance could explain why one behavior behaves disorderly.

Moreover, the question, how can we ensure the validity of the quality results, however, remain unanswered. Thus, the intention of combating these shortcomings is the key factors why this piece is made into existence.

Further, a good knowledge on quality review process could help a person ensure the validity of the quality results. By adopting quality review process for achieving the validity of quality results, one may assume that the validity of his/her quality results will lead him/her to improve his/her performance.

A further, quality review process is sequential (one at a time) in nature. The essentials of quality review process are described as follows:

Initially, the QA member must have a certain form to follow if he needs to assess a work, product, service, and/or process condition. This includes:

1. Identifying what type of reviews you will use. This includes keeping in mind the purpose of reviews when you are deciding on what to use.
2. Identifying who will responsible for the reviews.
3. Describing any quality review checklists that will be used.

Then, the QA member must verify (confirm) the justifiable of the work, product, service, and/or process condition based on his knowledge and/or understanding of this form to validate (execution) the work, product, service, and/or process condition and achieve the quality results. Otherwise, the QA member must evaluate (comparison) the work, product, service, and/or process condition with this form.

In the evaluation, if the evaluation is stronger, that is, their comparison has a greater number of significant points in common, the QA member is suggested to validate the work, product, service, and/or process condition and achieve the quality results. Otherwise, when their comparison has a greater number of significant points of difference, the QA member is suggested to log the work, product, service, and/or process condition as an issue for clarifications.

The diagrammatic representation of the quality review process below shows the general assessment flow between components.

The sample arithmetic condition below is presented to understand more how this quality review process operates:

A.) 23 + 18 = 41
B.) 23 + 18 = 341011

Here we see a single test case (23+18) with two quite different answers. They are the results of two different processes with two different forms. In the left-hand example, we are justified in believing that the test case A is correct because our understanding confirms that it follows the real pattern that the addition process must follow (adding vertical rows, carrying the extra digits). Thus, when we validate it, we get correct results - the answer is 41. In the right-hand example, we are not justified in believing that the test case B is correct because our understanding confirms that it led to the incorrect process, that is, the sum is put down in order from right to left - the result is 341011. As a result, we evaluate test case B with test case A (or other test case) and find that they are not similar in forms and processes. Thus, the test case B’s form and/or process is an issue for clarifications.

The idea of the method with the quality review process can benefit us to speed up, achieve, and bring gains the desirable outcome.

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

Quality program is an operational activities that refer to the existing quality materials, procedures, tools, training, organization, and metrics that can be defined and used within an organization in achieving best practices characteristically with the following components:

1. Quality Materials - An artifacts used within an organization that detail how a particular aspect of the project must be undertaken to assist a QA team apply and improve quality in the project. Usually they are gathered and established in the framework of the quality initiative and lead to QA team activities improvement, such as:

• Adherence to relevant design, programming, documentation, security, and naming standards - there can be no deviation from Standards unless a formal variation process is undertaken, and approval granted;
• policies;
• templates;
• checklists;
• criteria; and
• guidelines.

Note it is also useful to have some representation from the receivers of these quality materials in order to ensure the QA team are not using jargon that makes it clear to the producers, but unclear to the receivers. This includes consulting any applicable client quality standards, templates, checklists, criteria, and guidelines; and incorporating them into the definition of quality materials.

2. Procedures - An outlined quality and/or design Control activities undertaken to help review and achieve quality of the project. Describe and establish how the project team will build these quality procedures into works, products, services, and processes. Use of best practice methods, techniques, and/or know-how steps for development, such as:

• document Control to control Project Documents at each Project Phase;
• define conditions and availability of required documentation;
• defining quality standards for the deliverables;
• design Waivers of requirements;
• configuration change control;
• change or problem reporting;
• define responsibilities;
• corrective actions;
• Quality Records;
• design changes;
• Nonconformance;
• risk management;
• Quality review;
• design review;
• sign-off; and
• others.

3. Training - The following activities may be necessary:

• Identifying skill needs;
• Specifying and designing any training requirements and strategies for the project team;
• Developing or identifying course materials;
• Integrating skill development, quality concepts, and motivational training; and
• Recording training needs as notes for training plan.

4. Tools - Support tools, such as:

• performance modeling;
• project planning;
• tracking; and
• others.

5. Organization - Clearly describe and assign the quality roles and responsibilities of all stakeholders for executing each element of the quality process, such as: Responsibility for gathering; and interpreting and reporting on measurements of effectiveness.

6. Metrics - Statistics or any status assessment in the project definition that demonstrate measurements and indicators of evidence are captured and established during the various activities undertaken as part of “Quality Assurance” to measure the progress and effectiveness of quality improvement activities. This includes identifying areas where quality improvements can be made. It is used to establish the baseline.

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