You don't wait for a sprint to start before doing test work. You should have been present during the planning of the ticket and given feedback on the feature. Were all possible scenarios spec'd out? Could something be added to improve the testability of the feature? Do you need to create additional work items for yourself to set up an environment or generate ...
We have spent a couple of days to try and test the Atlassian way of running tests in Jira from their confluence pages. After evaluation of others tools we decided to use a commercial tool that integrated with Jira.
Create new Testcase issue type (with custom fields and status Passed/Failed)
Create subtask of the issue (add version)
www.slideshare.net/ErolSelitektay/test-link-jira-soap-integration and http://blogs.fcoos.net/integrate-testlink-with-jira/
give steps on how to configure JIRA on your Teslink.
Before you start, ensure you have Testlink 1.9.5 or above and JIRA 5.2 or above.
Test Link Screens involved:
The steps in the second link are:
Install and configure Testlink as per ...
Jira is a very flexible tool. You can use it as a workflow management tool for managing any software life-cycle.
It does not really need to know any knowledge of what kind of application you are developing. You can define any number of custom fields and or workflow steps you might need to differentiate between platform and or workflows.
I have used Jira ...
You need to triage submitted request to develop automated tests, exactly like your developers triage (are they?) bugs and feature requests. Automated test is code, and should be handled exactly like any other code: version control, code review, bugs/enhancement request with prioritization, documenting, whole enchilada.
Depending how sophisticated is your ...
Jira, like Trello, VSTS, Pivotal Tracker and others are story ticket management systems. I've used them all and prefer Jira the most due to its UI, usability and integrations with both other Atlassian tools and other vendor tools. However I don't consider these tools at all suitable to actually details the steps to go through to execute a given test, that ...
Where I've seen External ID used before is with importing tickets, migrating from systems or tools other than the current Jira instance, or relations between multiple systems when more than Jira is being used.
Just as an example, I worked in an environment that tracked their planned, prioritized development work in Jira but used Bugzilla for incoming bugs ...
That is because the field name you are looking for is likely "priority" and not "severity". Here is the query I use to find any blockers in QA:
status = "Ready for QA" AND priority = Blocker ORDER BY created ASC, updatedDate ASC
"Priority" can equal "Blocker", "Severe", "Major", "Minor", or "Trivial".
Check out the official documentation on how to use ...
Documenting everything in Jira is a possible waste. Everyone in the team should already understand what is expected to get the user story DoneDone, this includes all testing. If you do not know what and how to test I would question your current proces, not the level of documentation.
Agilish teams should focus on testing before or in parallel and not at the ...
In the response ideally we should verify below details:
Defect status: Resolved/Rejected/Won't Fix/Ready To Test
Comments[ of Developer]: What he/she has exactly fixed/changed and if particular condition he/she wants to specify to test thoroughly
Version: Commit version[Fixed under]
Then you can easily proceed to bake new build & use to test !
Testing a user story according to its requirements
Report any bugs you find
Retest fixed bugs
When there is no more bugs, demonstrate it to stake holders (depends on the size of this user story, you may not need to do this.
If everyone is happy, mark it as done.
If there is adequate documentation of the work the dev team has done in a another tool, then I would try to get access to that tool and work off of that. However, if you still aren't able to gain the needed information, you should standardize what is included when a task is moved to Ready to Test. This could be a note in the Jira, link to notes from ...
Having done some further investigation myself, it appears there are multiple ways to extract parts of the tests from Zephyr.
If you use the 'Search' function to locate a test and then choose to Export via the Export button in the test case frame itself then you get a summary of the test information but WITHOUT the test steps. If you use the 'Search' ...
Keeping issues open in Jira also means you cannot use most reporting tools optimal. The control-chart (to measure cycle-time) will show very high values. While you want to try to fix and close defects faster and faster.
I would create another project "Test Automation" and clone the issues there, link them and close the original issues. The benefits of ...
You have two main options.
A quick web search about JIRA TFS integration returns several connectors, most requiring payment. If your version of TFS is supported by the connectors, that would be your best option, because you would automatically get the MTM integration.
If your version of TFS is not supported, or your organization is not willing to purchase ...
You can consider TestRail. Please take a look at testrail site.
Here you can maintain the Testcases, Create milestone for each execution and also you can run the test execution and also share the results to the client. Herewith you can integrate with JiRA and other softwares via API.
"So, will it the iOS and Android issues will be merged on 1 Jira version?"
This is probably your core question. The answer would depend on many factors:
Do you care (will you do it) if Android and iOS release features at different times?
Do you semantic versioning, i.e. 2.0, 2.1, 2.1.1 and do you share sub version numbers for fixes?
How frequently do you ...
If I understand correctly, you used the software version to name the Jira project?
My answer would be that No, this is not how I would manage it. I would not use Jira that way. I would either have one project that covers both systems or two projects, one for each. Which will be right for you will depend on additional details within your organization such ...
If You company bought ZAPI (Zephyr API) along with Zephyr, You always can write migration scripts for e.g. in python. In my recent jobs I test both Zephyr and Test Rail, and I must said that, Test Rail is fantastic and has REST API more friendly than Zephyr.
Unfortunately we must choose Zephyr due to lower price (company has its own servers, don't want ...
Most common path is: Ready for QA -> In testing -> Done (or reopened). I can hardly see a need to add any additional stages here. Maybe you could need them when testing a big part of functionality. Then, for example, you could use such steps as: "Under Smoke testing", "Under load testing" etc. If there is a bunch of test cases and some of them are automated, ...
"Definition of done" should include that every "done" bug has a test plan.
Such test plan could include the steps to replicate original bug, and any other steps to test any other functionality which might be affected by the changes.
If test plan is missing, bug is not done yet.
Presumably one cannot comment on a ticket without having access rights to the project, so the question boils down to, "Is it possible to filter out issues in JIRA that do not have any comments?".
No, it is not possible without installing additional Jira plugs. See for example this StackOverflow answer, which recommends using the Jira Toolkit Plugin to ...
I am not 100% sure what you are trying to achieve, but I think you should have a look at Atlassian Bamboo as a continuous integration server as it integrations pretty good with Jira.
A ci-server should be able to work with any testing tools, I would not worry to much about what tools to pick or not. Select the ones that best suit your needs.
Bamboo can run ...
I don't think that orchestrating testing process from Jira is the best option.
Testing process should go hand-by-hand with the development and driven by Continuous Integration and Delivery so in the ideal world the process from developer's commit to publishing new release into production should be completely unattended and automated.
As a strong believer ...
This is what I had implemented for one of my clients.
This was developed using QTP and HP Load Runner.
Test Management Tool:
HP QC was used for test management, test case repository, Single Point of Reporting, Release management and Defect Management.
Integration between Jira and HP QC:
There are several bridge apps/servers ...
Not really.. You could always:
Write your own history tab.
Amend your email templates for better
formatting (I have to agree with you on that one - the default emails
are useful to get as a note that something has changed, but I don't
know anyone who really reads them because the formatting is not
Use a Kanban board instead of the Sprints version. Just create a new board in your project and choose Kanban.
The difference is that the Kanban board shows all project issues in the first todo column. This first column is then your backlog. You are still free to rank the issues with drag-and-drop.
This removes the need to drag issues into a Sprint, but you ...
I don't think you can do this without calling out each project with an OR or something.
You could add a label to each issue on these projects then just search by label. You can group edit a query if you want to label everything with the same label.