I have the next structure:
Bug
Dev task
Test Result with the failed test case
Tested by
For retest the bug I have created a RETEST task and link it to the bug. When I rerun the testcase I would like to add the passed test result to the RETEST task. How can I do? Or what is the best workflow?
You don't need to create a retest task for this case.
You could directly customize a workflow using States and Reasons for the Bug work item. Such as adding a state "Ready to Retest" for a Bug. And then assign this work item to the tester or tester group. Suggest you to use the Process Editor, available with the download of TFS Power Tools. The Process Template Editor provides a graphical user interface for customizing work items (field, workflow and the form) and process templates.
More ways for customize the workflow for a process please refer the tutorial from MSDN:
Customize the workflow for a process
Add or modify a work item type
Then you just need to directly link test result to the bug workitem. And in a Bug work item, you can click the HISTORY--ALL CAHNGES to track the history and process.
Related
Let's say I use Background feature which has the below steps:
Background: My pre-requisites
Given Step one
When Step Two
Then Step Three
....
Then Step Fifteen
So basically my Background has 15 common steps that is required for a set of scenario to run.
My question is : Is it possible to use the Background title My pre-requisites in other feature files, instead of writing down all the 15 steps as Background? Or is there any other way to handle this more gracefully.
You can create a before hook to code the background logic and reuse it across any feature file. Even tag the hook so u can filter out scenarios where u do not want the before hook to run.
Alongside the existing answer, you could also write a new step that compresses the functionality of the 15 steps into one or two steps that express what you are setting up.
The questions revolving around it are these:
Does the business need to know how the user will interact with the site to get to the point where you are ready to begin the test?
Can you bypass how the user will interact with the site to get there without information surrounding the test getting lost in translation between the dev team and the business?
For the former, I would go with a Background. The latter, I would go with a Hook.
For example:
I need to register a user in order to log in as them in my test. The Givens will start at me logging in, so I'll register the user through an API in a Hook.
I need to register a user in order to test the functionality of a new user on exiting the form, and various items surrounding registration, so I'll register the user, starting with some Background steps.
I have a requirement to send email to particular group when Teamcity's build goes green and red.
Does anyone has any idea about it ?
It is possible to configure user group and setup email notifications for this group inside TeamCity.
There are a few TeamCity plugins that you can leverage out of the box but the buildstatusnotifier
looks the most promising. You can also setup a job that gets triggerred upon completion of every build for the project you are tracking. This build will do the following:
Make a call for last status of the build project. See TeamCity REST documentation here for context. Replace "insert-base-url-here" with your teamcity base url & "btXXX" with your build id.
http://{insert-base-url-here}/app/rest/builds/buildType:(id:btXXX)/statusIcon
Save the result of this call in a DB or in a txt file
For every subsequent call, check to see if the new value is the same as the previous; if they are do not send an email. If the values do not match then proceed to step four
Send an email to the recipient/distribution list informing them of a change of status in the build status.
My personal preference will be to do all of these in an nant script but those are the steps to take.
You can also look at the Build-status tool (build-status.appspot.com) which can be setup and displayed in a highly visible place that your team will not miss should it turn red.
How is it possible to edit trac so a new ticket with component X follows workflow X and component Y follows workflow Y
Trac doesn't give you a way to do that at the moment. It assumes that your project has a single workflow.
There are some plugins that will give you additional workflow capabilities, however. The AdvancedTicketWorkflow Plugin gives you some advanced commands to use when designing your workflow. See the documentation for the "triage" command for an example of how to route two types of tickets through two slightly different workflows.
The TypedTicketWorkflow Plugin also adds additional workflow capabilities, by allowing you to create actions that are only applicable to certain ticket types.
There are a number of additional workflow-related plugins that you might want to test out. Some of them look like they haven't been updated in a while, though, so be aware that you may run into compatibility issues.
For Tasks assigned to me, I see how I can do
curl -u <api_key>: "https://app.asana.com/api/1.0/tasks?workspace=14916&assignee=me"
I am trying to make a quick page that breaks down my current tasks and links to Asana for me, so I can have my own quick dashboard.
I have my API Key
It lists all Workspaces I am a part of.
If I click a Workspace it shows all Projects inside of that space
If I click a Project I want to see only the Tasks that have been assigned to me inside of that Project.
If I add the Project ID to that above call, it sends me back every item in the Project, not just those assigned to me.
If I leave the Project ID out, it returns all tasks assigned to me, even those outside of the project.
Did I miss something?
Thanks for any help!
Note: I would add the Asana tag, but it doesn't appear to exist yet.
It seems that in the current version of the API the assignee parameter is ignored when specified for projects. Regardless of what I put below, I get the same result: all tasks.
curl -u <api-key>: "https://app.asana.com/api/1.0/projects/<pid>/tasks?assignee=here-it-can-be-anything"
I'm having trouble with this too - it seems you can't expand projects when querying tasks - and you can't get tasks by project... The former is actually preferred since you could provide a task list by project if you could expand on project.
As it is, you can get a list of tasks, then loop through and get the full task by task-id, but that takes a while...
I'm looking for some clarity with regards to the use of Windows Workflow 4 in an integrated solution - specifically with regards to rehosting the designer and executing workflows created by eg. a business user.
Is the intention that the required custom activities are created and compiled into a dll, which is then deployed with the rehosted designer, allowing the business user to create/configure workflows that make use of these activities - the business user would then save the workflow as XAML, which can be stored in a location known to the application (database, filesystem etc.), and then when it is necessary for the application to execute a workflow, it can use XamlServices.Load to load the workflow from the specific location and execute it as a DynamicActivity?
How is the workflow saved so that it can later be reserialized with properties and other configuration values? I've tried deserializing a Xaml file saved out of the designer, and also using XamlServices.save().
Are there any potential issues here with using bookmarks/persistence?
As a related question, is there any easy way to "Go back" in a workflow, without defining return branches on every flowchart element? I'm looking at integrating a workflow with a UI for a user to enter responses, which the wf will process, and make decisions based on the input. Through the UI, the user should be able to "Go Back" to a previous input.
You can use the ActivityXamlServices.Load(path) to load a XAML file. It will return an Activity, actually a DynamicActivity, and you can use a WorkflowApplication to run it.
See my blog post for an exmple.