The discussion feature of Rally is very limited. It does not support attachments or discussion threads. These are required for my teams. So is there a solution that integrates a better discussion solution with Rally? If not, what would it take to find a third party dicussion/forum solution and integrate it into Rally, in such a way as to have the information displayed as part of the correct user story/defect/task and be able to support attachments and discussion threads?
Jonathan,
At the moment, it will likely be hard to incorporate 3rd party discussion functionality into the Rally UI. We are working towards a more configurable and extensible UI with more accessible discussions. I see that you also posted this request on our ideas.rallydev.com site which will help us prioritize increasing the visibility and functionality of discussions.
Mark
Related
The company I work for is starting a new web application, and I have requested that front end developers make this application Automation Friendly.
The previous application was using the react framework, very few elements had unique ID's (or any unique identifier at all). This time around, I have asked the developers to include a custom data attribute, specifically for automation.
I am looking for anyone who may have experience in this kind of situation.
What have you asked your developers to do to assist in automation?
Are there any standards, or guidelines for naming elements in an application to suit Selenium automation?
are custom data attributes the best way to go? are there other options?
Any advice/guidance would be greatly appreciated!
Web Applications can be difficult to test if they aren’t made with testing in mind. This is especially true for Single Page Applications (SPAs). SPAs support heavy interaction without incurring additional page loads (e.g. Facebook, Gmail). Instead of page loads, these SPAs use AJAX requests to relay data back and forth from the server.
As per #ChrisChua from ThousandEyes these are some of the best practices to keep in mind as you develop your web application to make testing easier:
Add classes that are meaningful.
Classes should indicate the element’s functionality and state.
Use functional names in IDs and classes for action elements.
Dynamically generated classes and IDs are not helpful for testing.
Add targetable DOM feedback to indicate application state.
Never hard-code content in test code!
Conclusion
It's true some of these are not easy changes, as the developer may have to think harder about using test-friendly designs rather than "something that just works". However, it will definitely help with maintainability of the testing, which would reduce costs in the long run.
tl; dr
A couple of references:
Nicolas Gallagher’s article on HTML Semantics and Front-end Architecture
Yandex’s Block Element Modifier
W3C’s recommendation on good class names
Pamela Fox’s article on Frontend Architectures
Test Driven Development makes it easier to automate. In my opinion, testers should be developers, or ex-developers who are good at finding and preventing mistakes. Write the tests in the same project that the solution is being developed in. Developers can also put in ids, even though they don’t want to sometimes, and if the “testers” are good they can even submit pull requests (in GitHub for example) for code improvements that will allow them to test better. Think of testers as a piece of your development team, where everyone is allowed to contribute code. It helps with accountability and improves autonomy. Everyone is there to help each other and if all the code is in the same project, and all code is reviewed and approved before merging to master, everyone is a potential developer if everyone is IT. The old days of manual testing are dying. Separating Dev from Testing is a brick wall. Tear it down.
FastLink looks good stand-alone and in an 800x600 iFrame in the desktop browser, but I'm hoping there are some more mobile-friendly configurations that I just missed in the docs.
I see the access_type and displayMode parameters here, which would imply that what I'm hoping for is at least a possibility:
http://developer.yodlee.com/Aggregation_API/Aggregation_Services_Guide/FastLink_for_Aggregation/Yodlee_FastLink_Integration_Guide
I've been unable to find any other reference to those parameters in the docs, however, or more detail with regard to layout options.
Are there some other valid values for those parameters other than what's listed there in the Integration Guide, and/or some more detailed docs besides the integration guide and product guide?
FastLink looks like it has the potential to save significant unanticipated work on account setup, especially MFA -- I'm hoping we can get the FastLink UX to gel nicely enough with our own UX to not have to invest in rolling our own.
Currently there is no Fastlink available for Mobile/responsive one, although its in works and will be available in near future(no specific ETA right now).
Rally obviously has some Defect Tracking capabilities.
My question is; it is good/flexible enough to serve as the sole Defect Tracker of an organization? Or is it more common that general defect tracking is done in another tool like Bugzilla or JIRA? (Possibly using a Rally Connector to integrate them).
We are currently on Bugzilla but are ramping up Rally usage. If Rally can do Bugzilla's job, I'd happily get rid of Bugzilla and have one less system to worry about. Has anybody done that?
Stack Overflow is usually used to ask and answer questions regarding programming and code. So this is probably not the best forum to get an accurate answer to your question. That being said...
I have been a Rally engineer for a number of years. Internally we use Rally to manage our defects and I personally think it is a painless solution. The way that Rally can roll up defects and the work they represent from a task level all the way to the portfolio level is useful and I personally hate to waste my time trying to keep multiple systems in sync.
I know plenty of customers still use other defect tracking solutions in conjunction with Rally using our connectors and they seem pretty satisfied with that hybrid solution. I was on the team that maintained those connectors last year and we had plenty of happy customers. I actually was one of the pair that wrote the initial Bugzilla connector and it worked well to keep the systems in sync.
Probably not the most impartial answer but I would at least check into just using Rally and if it seems to be missing something you loved in your old system take the time to let us know through Rally Ideas.
We have been using ReqPro to a great extent by taking the advantage of the API DLLs. We basically develop .NET application and used the DLLs to store data to the ReqPro projects with great ease.
Now, we are looking at possible ways to move to RRC. For this, we need to know how we can achieve the same features.
As RRC is web based, it might have some services that can be used for such things.
The basic requirements are inserting requirements, traceabilities, history etc to RRC and retrieving the same.
Back to top
Please take a look at OSLC - this is a REST-based interface to RRC that will allow you to access and write to RRC. It may not cover all the capabilities you require - but should be a good start. http://open-services.net/ - and then look at the RM specification.
Hope that helps
anthony
p.s Another good place to cross-post this question is the forums on jazz.net - there is a specific forum for RRC.
we're developing a web app to cover all aspects of a printing company from finances, to payroll, to job costing. Its important to be able to control who can access what parts of these applications. Don't want a line employee giving himself a raise, etc...
I've heard of the concept of ACL & ACO, but haven't found a good example that we could adapt to our project.
Anyone know where I can find good information to work from?
A brief rundown on ACLs, where they should be used and how they should be structured and implemented for various applications and user levels can be found here:
LINK
I've had to implement that type of security a couple of times. Unfortunately I don't know of any really good articles that provide examples. My implementations were mainly piecing together the parts through trial and error.
However, I did come across this link on MSDN:
http://msdn.microsoft.com/en-us/library/52kd59t0(VS.71).aspx
It has some of the concepts.
After my original post, I did some more research. I found this article:
http://www.aspfree.com/c/a/C-Sharp/Implementing-Role-Based-Security-using-CSharp/
it seems pretty promising, I didn't go through all the details, but it at least guides you through the high-level topics.
If you're using .NET/Windows you might want to look into Windows Authorization Manager (AzMan). There are support for AzMan in Enterprise Library but there are other ways of using it as well.
http://msdn.microsoft.com/en-us/library/ms998336.aspx
http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/WhatIsAuthorizationManager.html