We are using JIRA to work with a team of Developers and a QA team. Currently the 'Dev Team Leader' creates a 'Task' ticket, assigns it to the development member, who work on that ticket and then informs the JIRA ticket number to the QA team, who create a separate QA ticket for testing it. And of the test is pass or failed they inform the DEV team, who either fix it or change the ticket status to 'In Deploy'.
My question is as follows:
Should they create single ticket and use that to do the Development and Testing ? (ie. shift the ticket between the DEV Team and QA Team)
Should the DEV team create a Parent TASK ticket for Development and then assign it to the QA team, who will create a Sub-Task for the Testing and link it to the Parent Development ticket?
Issues:
We need to identify which team member worked on the development
task?
Which team member worked on the Testing ?
How much of tie spent on Development as a whole?
How much of time spent on Testing as a whole?
What is the best way of doing this ?
You only need one ticket or an Issue in JIRA context. Your Project should have a workflow with, for example, the following Statuses: To Do -> In development -> In testing -> from here, the Issue can go in two directions, back to In development if the QA is not satisfied or Done.
When the Issue is moved to the next step, it will/should be assigned to the proper person, i.e. in To Do it's assigned to your project lead or whoever distributes the tasks, In Development it's the developer, In testing the QA, etc.
This is the most widely-accepted way to use JIRA as a ticket tracker. Each transition will be recorded in the Issue Activity Log with the corresponding datetimes, Assignees, etc. You will have access to all the information you've asked for.
It sounds to me like the workflow is in need of granular tracking of development work and testing, where a single ticket (suggested idea) doesn't satisfy.
I found the following design useful:
1. Create a USER STORY that has a set of criteria that needs to be met.
2. Sub TASKS can be created as children of the STORY especially if they need to be worked on by different people.
3. Once all tasks are completed, the USER STORY can be moved to TESTING / IN TESTING (whatever the workflow defines).
4. The QA/QE Engineer then can create TESTS / TEST CASES (children) for the User Stories and and execute them accordingly. Similarly, defects can be filed as BUGS as children of the story.
Ultimately in this workflow the story must meet a set of criteria and level of quality (based on what is acceptable to pass the story for the business) in order to be considered "completed" or ready for release.
Related
Let’s assume the following simple test case which is testing the functionality of a Banking system maintaining the balance of bank accounts:
Check Account #1234 Balance, which become the reference point (Ex: 1000 $)
Perform Deposit of 600 $
Perform Withdraw of 400 $
Check Account #1234 Balance, expecting the balance to be 200 $ over the reference point (Ex: 1200 $)
Given project pressures you and your colleague are ask to run the test suite in a concurrent fashion (could be using different browser version), given that both of you are manipulating the same account your test is sporadically failing.
In the IP sprint you are task to come up with a solution to bring consistency to the test results regardless of the number of members executing the suite in a concurrent fashion, what are the options you would consider.
There are different ways to approach your case, I would like to list some:
1 - If the concurrency is a must and if your Check Account changes something in a Database, then would be necessary to use different accounts, one per thread of execution, this way each test can run with no concerns on what the other tests are doing.
2 - If you can push for a non-concurrent solution, then you only need to run your tests serialized and at the end of each test revert back the check account to the reference point.
3 - Another way to solve this problem is to use mock data. This solution could be a little bit more complex, and it could requiere more work. But if still you want to know more about it contact your development team and let them know about your problem so that you can find a solution together.
You can read more about mocking data here:
Cypress Interceptor
Mockserver
Wiremock
Mockoon
Hope it helps!
In TFS 2015 using the Agile process template, the board for the "Stories" backlog shows only stories, and the board for the current iteration shows all tasks under stories. This makes sense for most teams.
We are breaking down our work into smaller than usual stories and thus avoiding task breakdown, so very few of our stories have tasks. Is there a way to show stories on the current iteration board instead of tasks, so that it looks similar to the higher-level stories board but with only the stories in the iteration?
In the end, I want to avoid a useless board like this:
Have you considered just using the Kanban/Backlog board?
My team don't use tasks at all, all our work is tracked on the Kanban board, we never use the Sprint Board.
Some teams add a "Sprint Backlog" column to show what is planned for the current sprint. Then you can collapse the "New" column until the next planning session.
I want to perform rigrous testing on Payment Gateway(2checkout) and Pay Pal. For testing, I need to simulate a large number of successful, failed and halted transactions (transaction stopped due to system crash/reboot). But I don't want to make actual payments.
1. Is there any way I can make a test transaction on payment gateway, using fake card numbers or something else.
2. What are the possible advance testing scenarios for Payment Gateway testing?
For example:
Changing the amount, unmask CVV or card from Inspect
element.
List item
There are two options :
Using the PayPal Sandbox (Application Testing), or
Using Dependancy Injection (Unit Testing).
Both would work but I would suggest a Dependancy Injection approach. Assuming you have a separate object that only interacts with PayPal and then other objects that do your actual application logic (and error handling, etc) then you can just create a dummy version of the PayPal interaction object (that always returns true, or conditionally returns false, whatever) and then test your various application classes in detail.
I would suggest you only one solution, look at this Git PayPal-Android SDK and go through the README.md file. Last link tells you how to create a sandbox PayPal account to create dummy transactions across your sandboxed account developer account.
If you have doubts, you can refer Part 1 and Part 2 of AndroidHive tutorial for this.
I've just started working on osTicket. I'm digging this ticket system to understand more of it. I read a lot about its feature from official website as well as some forums but still I could not figure out the purpose of teams. Can you explain - with some practical example, use of this teams feature and how I may help me in making it work for an education institute with multiple campuses?
Team feature gives you the ability to group staff members together (e.g across different departments) for the purpose of ticket assignment (manual or auto).
For example -- you might want a "Data management" team to handle tickets request dealing with data request.
i'm new with "Trac" and i need to start managing a project with it, but i don't how and where to begin.
What i need is to understand the way to approach "Trac", any suggestions?
milestones----> assign ticket to users----> users process tickets----> milestone----> project done!
Is this passages correct?
Thanks a lot ;)
I based my Trac system off of the system that the open-source project Haiku OS uses. See http://dev.haiku-os.org/wiki/TicketLife for a well-written description of the ticket process.
As for my system, I have a milestone named "unscheduled" that all tickets default to. When they get reviewed by a triager, they get re-assigned to a particular milestone or to a pseudo-milestone ("wishlist", "decision pending", etc). When all of the tickets for a milestone are closed, we declare that milestone complete and start putting together a release.
The best way to manage a Trac system is to first be a Trac user. Find a public Trac system (like Trac's homepage, trac-hacks.org, etc), make yourself an account, and start using it. Discover what works and what doesn't and adapt your own methods accordingly.