Avoid trying to direct people to change as it often backfires
Instead, use some or all of the following techniques:
Ensure there is a healthy and robust discussion of testing during the initial ticket sprint planning sessions.
Initiative '3 amigos' discussions when requirements / testing is not clear
Share knowledge and best practices through giving ...
What would you do?
I'd most likely hand in my notice working in such an environment.
Is there any reason why this has to be overengineered? Not in my opinion.
I'd simply create one test case and trust my coworkers. They should be able to communicate when it's needed.
Of course getting access to all three systems is a priority (it is really necessary in fact)...
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 ...
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)
What about the three of you sit down and... work together? You can simply plug one computer in a screen and you all test it together.
(No sarcasm, seriously)
Two of the tags you posted are "HP-ALM" and "Jira".
It can be a guess, but I feel that you may be limiting you way of working because of how these tools are setup.
From the Agile ...
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 ...
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 ...
This sounds like developers and testers are missing requirements. This doesn't mean you need a huge formal requirements document, but in the very least each product enhancement needs acceptance criteria. Each defect report needs steps to reproduce.
Developers should not be writing acceptance criteria. Someone on the product side needs to do this. If a ...
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 ...
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 !
We've succesfully integrated TestLink 1.9.10 with Jira in the Cloud. My configuration for the issue tracker record in TestLink is:
<!-- Template jirarestInterface -->
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.
I think you answered your question well, there's little to add on the side of what should be done. However, it might be useful to see what not to do when facing such a situation:
hope the problem will eventually go away. It won't, people don't like to change and there even might be more reasonable causes of the problem like programmers being under too much ...
TL;DR: Jenkins supports pipelines from code. Make your build, test and deploy pipeline in code and you are not dependent on a specific CD tool. If you can do it from the command line and with API's you can combine and chain any tool or test-step. Use Pipelines as Code!
Is it possible to automate this complete process?
Probably, but not out of the box with ...
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.
What Xray provides is the ability to create Sub Test Executions as sub-tasks of a Story, for example. More info here: https://confluence.xpand-it.com/display/XRAY/Sub-Test+Execution
Since a Test is somehow like a test case template reusable, even for later version, maybe it makes more sense to have the "execution" related task as a sub-task instead.