Posts Tagged tester

New: Bug Pain Plugin - No Pains!

We’ve got an interesting new tool in TargetProcess 2.18.1 — Bug Pain plugin. It emerged from our own “bug pains”  to empower decision making for QA team as they pull some bug to fix, with no Product Owner involved.

Disclaimer: QA Team are aware of product development strategy, they just needed some help with bugs prioritization when Product Owner is not available to talk.

Bug Pain value in TargetProcess depends on “Severity, “Visibility” and “Class” values as below:

bug-pain-severity-visibility

“Severity” indicates bug severity per se. This could be some grave error that ruins the whole release or a small UX flaw. We’ve got the following “Severity” values:

5 - Much anger & crying - No workaround
4 – Anger & swearing - Difficult workaround
3 – Annoyance & frustration - Easy workaround
2 – Confused
1 – Laugh if notice

“Visibility” indicates how many users are likely to spot bug and how soon. E.g. it takes 10 steps to reproduce bug (random not straightforward steps), in a browser used by 1% of people -  or this is an error on Login Page for 100% users as they attempt to login.  Our Visibility values are:

1 - ~5%
2 - <50%
3 - >50%
4 - ~100%

“Class” shows relevance of bug in the context of product development strategy.  This value can differ for each particular company/project/product.  Speaking of TargetProcess, improving usability is paramount for us at the moment.  So, a bug with usability related Class will be more important than a bug found by Trial User.  Here’re the Classes we’ve got:

1 – No customer, Security
2 – Free/Trial user, Cosmetic
3 – Paid Customer, Usability, Whoops

Bug Pain is calculated based on this formula:

[Bug Pain] = X * [Severity] + Y * [Visibility] + Z * [Class],

where X, Y, Z are specified in the plugin setup (8, 5 and 4 respectively).  These values have been identified experimentally based on common sense for a cloud of bugs and may vary for each particular company/project/product:

bug-pain-calculated-automatically

Next, bugs can be filtered by Bug Pain value.  The most important and urgent bugs will be on top of the list and should be fixed first:

pain

This plug-in is a helpful tool for Product Owners and QA Teams as they prioritize bug fixes.

Bug Pain plug-in comes out-of-the box with TargetProcess now.

, ,

Comments

TargetProcess Videos: Selenium Integration

Check the new Selenium integration video:

http://targetprocess.com/video/selenium/selenium.html

Selenium powers continuous integration. You can create a set of test cases in TargetProcess, map them to automated tests and have test results in TargetProcess real time.

Comments

TargetProcess Videos: TestTrackPro and Perforce Integration

Check the new TestTrackPro and Perforce integration videos:

http://targetprocess.com/video/testtrackpro/testtrackpro.html

http://targetprocess.com/video/perforce/perforce.html

Comments

Product Update: Fast Test Cases Execution in TargetProcess

In v.2.16.5 we’ve added some nice feature that simplifies test cases execution for a specific user story.

Basically, this is the fastest way to test a specific user story. You don’t need to create test plan and test run. Just navigate to user story view and open test cases tab. This tab provides all the required functionality:

  1. Expand test case to see details.
  2. Mark test case as passed or failed and open next test case in the list.
  3. Re-order test case using drag and drop.

The list is fully ajaxified, with no page reload on all actions.

testcases_userstory

Sometimes tester wants to correct test case name or steps. It can be done right there without page reload.

testcase_edit

, ,

Comments

Re-designing ToDo List: Scenarios

Today we spent several hours writing scenarios for Mary (she is a Tester). There are two types of scenarios. The first describes a typical working day. The other set of scenarios describes concrete goals that Mary wants to accomplish with the help of TargetProcess.

Sorry for a lengthy post, but we want to provide all the important details and show how we are trying to re-design TargetProcess. If you think that this persona is artificial, let us know. If you think you know similar girl, let us know. If you have any questions, just ask. Here we go.

Mary, 26 yo, Functional Tester

laptop_mary
Has 3 years of experience in testing web applications. Knows how to write test cases, works  with several bug tracking systems. Hates bad UI and constantly tries to convince developers to fix ugly areas.

Environment

  • 30 people development team, single project, 6 testers in the team.
  • Scrum process with 2-week iterations.
  • Uses laptop at work

Activities

  • Find and submit bugs, capture screenshots
  • Create test cases
  • Verify user stories (execute test cases)
  • Verify fixed bugs
  • Communicate with developers about stories and bugs
  • Participate in daily meetings, iteration planning, release planning meetings

Behavior

  • Smokes and drinks coffee
  • Likes to communicate with people around
  • Listens to music at work
  • Argues with developers about found bugs
  • Uses IMs quite often to chat with friends
  • Likes bright colors

Goals

  • Have fun at work
  • Good communication and social environment at work, money not so important

Typical Day Scenario

Mary’s working day (Tuesday).

Mary comes to the office at 9 am. She has daily meeting at 10 am, so she makes herself some coffee and checks email (20 mins). She looks at what she worked on yesterday, what’s new came today and what are her assignments (10 min). She forgot to add time yesterday, so she adds time right now for all the yesterday’s activities. She loads Skype and says “Hi” to friends.

Then daily meeting begins (20 min).
- I verified the UI improvement bug, then verified user story “As a admin I want to un-delete projects” and added 3 bugs on this user story (one is critical and 2 UI improvements). Today I am going to discuss a new user story with Pete, check specs and start writing Test Cases. Also I can’t setup Ubuntu to check several UI bugs on FireFox for Linux, so I need help.
- (Larry) Mary, we have one blocking bug to reproduce. It is very important.
- OK, I’ll take a look at it.
- (Ted) I can help you with Linux
- Oh, cool! Let’s do it this afternoon.

Meeting is over. After the meeting Mary has the following priorities: the blocking bug, Linux setup and bugs check, discussing the new user story.

Mary has coffee, smokes with friends, thinks about the blocking bug and discusses possible reasons with developers. (15 min).

Pete comes to ask about a meeting on the new user story.
- Hey, let’s discuss the  new story I have.
- I have a blocking bug, so I can’t attend right now, maybe you’ll help me to reproduce it?
- OK, let’s take a look.

They investigate the bug for 30 mins and reproduce it successfully. Mary submits steps to reproduce into the system and as a small reward takes a little break. Then they  discuss the new user story with Pete (30 min). They discuss specs, some unclear areas, etc.

After the meeting, she writes checklist for the user story (1 hr). Then goes for lunch.

After the lunch she comes back and checks if there are any new tasks. No new tasks, so she calls Ted to help her with Linux. She spends 1 hour with Ted setting everything up. Then Mary verifies several UI bugs on Linux. Suddenly during exploratory testing she finds a new nasty bug - null reference exception when clicking on Delete User button. She captures the screenshot and adds bug into the system. This bug blocks verification process and Mary notifies team lead about the problem. And goes to smoke one more cigarette.

It is 5 pm already, so for the rest of the day she chats with friends and reads some interesting blog posts and articles. Suddenly she remembers that Katy returned from vacation today, so she calls for her and talks about Florida and Miami. Then Mary checks email and goes home at 6:30 pm.

Goal-oriented Scenarios

Mary has her own goals.

What did I do yesterday?

Mary comes to the office  in the morning, logs in into the system and wants to see all her yesterday’s work before the daily meeting. She sees:

  • daily meeting attended (10:00 - 10:20)
  • for story “As an admin I want to un-delete projects”
    • Test Cases ran
    • Bug “Crash when click Un-delete in FireFox” added
    • Bug “Main label has strange color on Un-delete screen” added
    • Bug “Buttons overlap in Safari on Un-delete screen” added
  • comment added for the bug “Ugly button formatting in Add User page”
  • Read article “Kanban and Functional Testing” (done)
  • Personal task “Install new version of Skype” added

System reminds Mary that she forgot to add time for all yesterday’s tasks, so she adds time quickly without any redirects.

I want to plan my day

After yesterday’s work review, Mary wants to see today’s meetings, all tasks and focus on high priority tasks (bugs, stories, tasks) with estimates, new tasks. She sees:

  • daily meeting (10:00 - 10:20)
  • 3 UI bugs to verify
  • for user story “As a developer I want to find all usages of the method quickly”
    • meeting with developer (deadline today, highlighted)
    • create test cases
    • run test cases
  • create test cases for user story “As an admin I want to delete comments”
  • Smoke testing of new build on Thursday
  • Retrospective meeting on Friday (undefined time)
  • Demo meeting on Friday (15:00-16:00)
  • Read “Why FitNesse rocks” article

Mary wants to plan her day, so she marks tasks for today, and as a result she has 2 groups of tasks (Today, Later). Suddenly she remembers that she forgot to report a bug yesterday, so she adds this task for today quickly.

What’s new  today?

Mary comes back from diner and opens her dashboard. She wants to know which comments have been added to her items, which new meetings scheduled, new bugs added or bug states updated.  A blocking bug “Crash on user add” was added  and already fixed by Tom.  She sees that nobody is assigned as a verifier for this bug and she assigns this bug to herself to verify the fix asap. Also she sees that a new comment has been added for a bug in her todo list. She reads the comment and replies quickly. Also she notes that someone has added the UI bug that she forgot to add yesterday. So she closes the related task.

The next step is to gather scenarios for the other personas, combine them, analyze them and create wireframes for the new ToDo list. Something tells me it will be powerful. And we should keep it as simple as required, but not simpler ;)

, , , , ,

Comments