Explore topic-wise InterviewSolutions in .

• Use strings_english.txt as the BASIS for the NEW localisation FILE.
• CONSIDER using UTF8 ENCODING.
• Submit an issue into the Mantis Bug Tracker and attach a compressed version of the file.

• If you are about to implement a major feature, it is strongly RECOMMENDED to get in touch with the developers. Such interaction will make it much more likely that your mods be applied to MantisBT distribution.
• Patches should be attached to a Mantis Bug Tracker issue.
• A patch should be attached as a single zip or .tar.gz file.
• A patch should include a copy of all new files / modified files as well as a diff (patch) file (if possible).
• A patch should only contain one feature. If a patch has a mixed bag of features, it makes it harder to understand and apply.
• If you require feedback from developers relating to the patch, then post a message to mantisbt-dev at lists dot sourceforge dot net which refers to the issue including your patch. Ideally, the feedback will be added to the issue as notes. If not, then the patch OWNER should summarise the feedback as notes.
• Fixes and updates to the patch should be attached to the same issue as should be marked clearly. With every attachment there should be a note that refers to the file name and specifies the updates done.
• JOIN MantisBT IRC CHANNEL for realtime discussions with developers.
• Patches should following MantisBT coding style.
• Keep your patches up-to-date as new MantisBT versions are released.

• Use MantisBT FORUMS or mantisbt-help at lists dot sourceforge dot NET for posting questions. Our preference goes to the forums.
• Use mantisbt-dev at lists dot sourceforge dot net for DEVELOPMENT related DISCUSSIONS.
• Use Mantis Bug Tracker for reporting feature requests and bugs.
• Use MantisBT Manual comments to identify a problem with the documentation or to contribute hints that are ought to be PART of the documentation.
• Use mantisbt-lang at lists dot sourceforge dot net for discussions relating to localisation to a specific language.

Scmbug is a system that integrates software configuration MANAGEMENT (SCM) with bug-tracking. It aims to be a universal tool that will glue any SOURCE code version control system (such as CVS, Subversion, and Arch) with any bug-tracking system (such as Bugzilla, MantisBT, and Request Tracker).

Scmbug is a system that integrates software configuration management (SCM) with bug-tracking. It aims to be a universal tool that will glue any source code version control system (such as CVS, Subversion, and Arch) with any bug-tracking system (such as Bugzilla, MantisBT, and Request Tracker).

• Go to MANAGE CUSTOM Fields
• Enter Field Name
• Click BUTTON 'New Custom Field'
• SELECT Field Type
• Enter Field Specific Data
• HIT Update Custom Field

Now the custom field got created. Click the Custom Field Again and Link Custom Field to your Project. After that in Report Issue section, the new custom field will be reflected.

Now the custom field got created. Click the Custom Field Again and Link Custom Field to your Project. After that in Report Issue section, the new custom field will be reflected.

Go to Manage > Manage USERS and Click on 'Create New Account' and update below fields:

• USERNAME
• Real NAME
• Email
• Access LEVEL
• Click Create User

In the next screen assign user to the desired project.Update Email and other Account PREFERENCES as desired. After that the login credentials are sent to the user on their email.

Go to Manage > Manage Users and Click on 'Create New Account' and update below fields:

In the next screen assign user to the desired project.Update Email and other Account Preferences as desired. After that the login credentials are sent to the user on their email.

Under Manage Tab, GO to Manage Projects:

• Enter Project NAME
• Select Status
• Enter Description
• CLICK ADD Project

Under Manage Tab, go to Manage Projects:

YES, MantisWAP provides a very light weight INTERFACE for Mantis ACCESS through a SMART phone or PDA. It is optimize for speed and MINIMIZATION of consumed bandwidth.

Yes, MantisWAP provides a very light weight interface for Mantis access through a smart phone or PDA. It is optimize for speed and minimization of consumed bandwidth.

No, but it PROVIDES a SOAP WEBSERVICE INTERFACE.

No, but it provides a SOAP webservice interface.

1) To report a new issue, click on 'Report Issue' in the main menu bar (shown below.)

2) A form will open titled “ENTER Report Details”. You must fill in every field that it contains. The following steps describe how to do this

3) First, you must always select 'All projects – general' in the *Category drop-down menu.

4) Select the reproducibility from the second dropdown. Keep in mind that as much as you can, you should find the bug’s circumstances before logging it. Ideally, you should be able to reproduce it 100% of the time. But sometimes it is impossible. In these rare cases, you can use 'sometimes' if the bug occurs sporadically or 'random' if you REALLY are UNABLE to reproduce it.

5) Select a severity for the bug:

minor if the bug is important but not detrimental to the proper functioning of a feature

major if the bug is important and compromises the user’s experience

critical if the bug completely prevents the user from continuing what he was doing, or if the bug crashes or freezes the site/app/game

6) Select a priority for the bug:

'low' if the bug has very little impact on the user’s experience

'normal' if it needs FIXING soon but it is not urgent

'high' if it needs fixing relatively soon

'urgent' if it is a top priority and should be quickly

'immediate' if it needs fixing right now

7) Fill in the 3 forms under “Select Profile”. These are:

Select a Platform: the device you used for your tests

Select an Operating System: the operating system of the device

Select an OS version: the version number of the operating system

8) Leave the 'Assign to' drop-down blank unless told otherwise.

9) In the summary field, enter a title for your bug. The title should begin with the name of the section of the app/website/game in which the bug happens between brackets [], followed by a brief description of the bug.

10) Update the description field the detailed info abt the bug.

11) The 'Steps to reproduce' section should contain the steps that a developer or other tester unfamiliar with the project should follow to reproduce the issue

12) The 'Additional information' field must be used to inform the developer of what device/browser and on what device/browser version the bug was found

13) Use 'Upload File' to upload your screenshot or video

14) View status should be left public and the ‘report stay’ checkbox should be left unchecked unless you have ANOTHER issue to enter immediately.

1) To report a new issue, click on 'Report Issue' in the main menu bar (shown below.)

2) A form will open titled “Enter Report Details”. You must fill in every field that it contains. The following steps describe how to do this

3) First, you must always select 'All projects – general' in the *Category drop-down menu.

4) Select the reproducibility from the second dropdown. Keep in mind that as much as you can, you should find the bug’s circumstances before logging it. Ideally, you should be able to reproduce it 100% of the time. But sometimes it is impossible. In these rare cases, you can use 'sometimes' if the bug occurs sporadically or 'random' if you really are unable to reproduce it.

5) Select a severity for the bug:

minor if the bug is important but not detrimental to the proper functioning of a feature

major if the bug is important and compromises the user’s experience

critical if the bug completely prevents the user from continuing what he was doing, or if the bug crashes or freezes the site/app/game

6) Select a priority for the bug:

'low' if the bug has very little impact on the user’s experience

'normal' if it needs fixing soon but it is not urgent

'high' if it needs fixing relatively soon

'urgent' if it is a top priority and should be quickly

'immediate' if it needs fixing right now

7) Fill in the 3 forms under “Select Profile”. These are:

Select a Platform: the device you used for your tests

Select an Operating System: the operating system of the device

Select an OS version: the version number of the operating system

8) Leave the 'Assign to' drop-down blank unless told otherwise.

9) In the summary field, enter a title for your bug. The title should begin with the name of the section of the app/website/game in which the bug happens between brackets [], followed by a brief description of the bug.

10) Update the description field the detailed info abt the bug.

11) The 'Steps to reproduce' section should contain the steps that a developer or other tester unfamiliar with the project should follow to reproduce the issue

12) The 'Additional information' field must be used to inform the developer of what device/browser and on what device/browser version the bug was found

13) Use 'Upload File' to upload your screenshot or video

14) View status should be left public and the ‘report stay’ checkbox should be left unchecked unless you have another issue to enter immediately.

• Log in with your username and PASSWORD. If you’ve FORGOTTEN your credentials, you can reset your password using your email address from the link on the login page.
• To SEE your project’s main page, you must SELECT its name in the drop-down menu displayed in the upper RIGHT corner of the screen. Once the page loads, click on the tab 'See issues' to see all the previous entry bugs for this project.

• A bug when found by the tester is marked as NEW.
• This bug is checked for its VALIDITY by the TEST lead to mark it as OPEN.
• The bug is then ASSIGNED to the developer.
• The developer on fixing the bug GIVES it to the tester for regression testing.
• The tester may either REOPEN or CLOSE the bug.

The following STEPS involved in the bug cycle process:

Bug investigation:when the tester FIND the bug

Bug ASSIGNMENT:when the tester assigns the bug to the developer

Bug fixing: when the bug is FIXED by the developer

Bug retesting:when the developer fixes the bug and given to the tester

Bug closing and REOPENING:when the tester retested and the status is changed to ‘closed’.

The following steps involved in the bug cycle process:

Bug investigation:when the tester find the bug

Bug assignment:when the tester assigns the bug to the developer

Bug fixing: when the bug is fixed by the developer

Bug retesting:when the developer fixes the bug and given to the tester

Bug closing and reopening:when the tester retested and the status is changed to ‘closed’.

Title should be clear: A good title is a must, which the ESSENCE of the bug report be well grasped by the developer.

One but per report: A bug report should have only one bug and not more or no LESS. In case more bugs are placed, some of the bugs may be overlooked.

Minimum, quantifiable steps to reproduce the problem: This is a very IMPORTANT tip. Developers need to get the problem in the shortest possible time. So the tester needs to help them for doing just that task. Testers need to have few rounds of testing and be able to PRODUCE the problems using minimum steps.

Expected and observed results: A bug report should always contain the expected and the observed result. The developer does not think that the bug is a real bug. Testers should take the responsibility to EXPLAIN the developers that went wrong.

The build that the problem occurs: It is common the daily builds. If the exact problematic build is not specified by the tester, it is hard for developers to resolve an already-solved problem.

Pictures: ‘A picture is worth a thousand words’! Certain times, the words do not flow. If such situations, it is better to have a clear picture that perfectly illustrates the problem.

Title should be clear: A good title is a must, which the essence of the bug report be well grasped by the developer.

One but per report: A bug report should have only one bug and not more or no less. In case more bugs are placed, some of the bugs may be overlooked.

Minimum, quantifiable steps to reproduce the problem: This is a very important tip. Developers need to get the problem in the shortest possible time. So the tester needs to help them for doing just that task. Testers need to have few rounds of testing and be able to produce the problems using minimum steps.

Expected and observed results: A bug report should always contain the expected and the observed result. The developer does not think that the bug is a real bug. Testers should take the responsibility to explain the developers that went wrong.

The build that the problem occurs: It is common the daily builds. If the exact problematic build is not specified by the tester, it is hard for developers to resolve an already-solved problem.

Pictures: ‘A picture is worth a thousand words’! Certain times, the words do not flow. If such situations, it is better to have a clear picture that perfectly illustrates the problem.

• If any bug found is confusing, it should be discussed with the developer.
• The BUGS should follow a PROPER CYCLE until CLOSED.
• If any bug closed by developer is not fixed, it should be REOPENED.
• Never assume while tracking a bug.

The DIFFERENT bugs are:

Show-stopper / CRITICAL bugs: The core dumps, PRODUCTS abnormally shuts down and no work around will be found out, like OS automatic freezing.

Major Bugs: The work around is found, but the implementation can be DONE, like performance degradency.

Medium Bugs: These bugs include database errors, link errors, low RESPONSE time

Low/minor Bugs: These bugs are typos, simple GUI errors.

The different bugs are:

Show-stopper / critical bugs: The core dumps, products abnormally shuts down and no work around will be found out, like OS automatic freezing.

Major Bugs: The work around is found, but the implementation can be done, like performance degradency.

Medium Bugs: These bugs include database errors, link errors, low response time

Low/minor Bugs: These bugs are typos, simple GUI errors.

New: In finding an issue in testing, all relevant checks are PERFORMED, like whether is was occurring in the previous release. If the issue is so, reopening the bug and creating new defect is DONE by changing the status of that defect to ‘new’.

Open: When a new bug is opened, development or project manager revises it, followed by assigning the TASK to the developer, and changes the status from ‘new’ to ‘open’.

When the bug is found by the tester, the status is marked as NEW. Once this bug is verified by the test lead for its VALIDITY, the status is changed to OPEN.

New: In finding an issue in testing, all relevant checks are performed, like whether is was occurring in the previous release. If the issue is so, reopening the bug and creating new defect is done by changing the status of that defect to ‘new’.

Open: When a new bug is opened, development or project manager revises it, followed by assigning the task to the developer, and changes the status from ‘new’ to ‘open’.

When the bug is found by the tester, the status is marked as NEW. Once this bug is verified by the test lead for its validity, the status is changed to OPEN.

Some salient features of Mantis are:

Email NOTIFICATIONS: It sends out emails of UPDATES, comments, RESOLUTIONS to the concerned stake holders.

Access Control: You can control user access at project level

Customize: You can easily customize Mantis as per your requirements.

Mobile SUPPORT: Mantis supports iPhone, Android and Windows Phone Platforms.

Plugins: An ever-expanding library of plugins to add custom FUNCTIONALITY to Mantis.

Some salient features of Mantis are:

Email notifications: It sends out emails of updates, comments, resolutions to the concerned stake holders.

Access Control: You can control user access at project level

Customize: You can easily customize Mantis as per your requirements.

Mobile Support: Mantis supports iPhone, Android and Windows Phone Platforms.

Plugins: An ever-expanding library of plugins to add custom functionality to Mantis.

MANTIS is a free, open SOURCE bug tracking software. It can be used to track bug for various software PROJECTS. You can easily download and install the Mantis for your USE. Mantis now also provides a hosted VERSION of the software.

MANTIS is a free, open source bug tracking software. It can be used to track bug for various software projects. You can easily download and install the Mantis for your use. Mantis now also provides a hosted version of the software.