LOGIN
התחברות או הרשמה
Avatar
להמשך הרשמה ידנית – לחץ על כפתור ההרשמה, להרשמה/כניסה מהירה בעזרת חשבון רשת חברתית – לחץ על הלוגו בכותרת

אפס סיסמה - שכחתי את שם המשתמש

שם משתמש
סיסמה
זכור אותי

he icon   en icon

בכדי להוסיף פוסט בבלוג יש להרשם או להתחבר - ההרשמה/כניסה מתבצעת מכותרת האתר.

כיצד לפתח מערכת שליחת דוחות אוטומטית ל Bugzilla

נכתב על ידי 
חמישי, 03 אוקטובר 2013 06:33
דרגו כתבה זו
(2 הצבעות)

 

 

 

 

 

How to develop you own Bugzilla report server

 

As part of Q.A manager tasks you are required to send various reports on your project quality.

If doing it the right way these reports can give you a lot of information on you projects for example:

Which module has the most critical bugs, how may bugs you team produces, what is the reopen bugs rate , bugs trends and a lot of other KPI which can give your managers information how to improve the quality of your projects.

There is a lot of knowledge in the Bugzilla Data base and you as a Team leader should use it to reflect this in formation correctly.

Several months ago I was asked to setup an automatic solution for generating Bugzilla reports based on several KPIs which our managers defined.

After searching the web I could not find a simple solution which suite our needs (at least not a simple one).

All of you probably familiar with a simple program called “excel” J.

Wouldn’t it be nice to get every day an excel report to you mail which reflect your products status, trends etc..

So…. Let’s start.

Bugzilla is using MySql DB, you can download mysql connector

http://dev.mysql.com/downloads/connector/odbc/5.1.html

And set up an ODBC connection

http://dev.mysql.com/doc/refman/5.1/en/connector-odbc-examples-tools-with-wordexcel.html

(you will need the correct privileges for connecting directly to the Bugzilla DB like username , password and port, ask you IT guys for that)

Now that you have the connection you can easily import data from Bugzilla DB to your excel file, perform all kind of calculations, generate graphs and use all of excel features as you like.

I have setup a windows schedule task for rendering the excel file on a daily bases and sending it to several managers.

Now I had to deal with another problem, our managers liked it so much that they started to ask me for additional reports which were very hard or even impossible to extract form Bugzilla the way the DB structure is.

So to overcome this I have setup additional MySql DB which saves snapshots from the original Bugzilla DB (it is very simple to install MySql DB , generate tables using HeidiSQL client).

You can export MySql queries from the original Bugzilla DB and import it to you snapshots DB.

Once again generate your reports from the snapshots DB.

All of the reports can be on the same excel file connecting to both MySql DB (see example)

I am sure that there are other ways achieving this task but I needed a free simple and flexible solution which everyone knows. 

Enjoy

 

 

 

 

שונה לאחרונה ב שישי, 04 אוקטובר 2013 11:31

חובה להיות משתמש רשום במערכת בכדי להגיב - ההרשמה/כניסה בכותרת האתר

חדשות מעולם הבדיקות

  • Five Blogs – 18 October 2018

    The (best) five blogs I read today. Check them out. What Is Data Democratization? A Super Simple Explanation And The Key Pros And Cons Written by: Bernard Marr What’s getting Agile down? Written by: Gary Watts Future of AI in Testing (Will You Be Replaced?) Written by: Joe Colantonio Jeff Hawkins Is Finally Ready to Explain His Brain Research Written by: Cade Metz Lower level Automation and testing? Be more precise! The Automation triangle revisited…again! Written by: Toyer Mamoojee Quote of the day: “When you’re young, being different is not cool. But when you’re older, it absolutely is.” -Lane Moore You can follow this page on Twitter

    17.10.2018 | 11:36 קרא עוד...
  • The Automated Regression Suite. Part 2 of 3. When to run the tests.

    Once you have your automated regression suite in place, you can create a scheduler to run them periodically, without any manual intervention. Mostly you will use Jenkins jobs (or some similar CI tool) to trigger them and have them running on an environment of your choice. Just because they are called “regression tests” it does not mean they are only meant to be run once before a release. They are in place to help validate your system, so you can run them as often as you want. But how often do you want to run them? That really depends on some factors like: how often are you releasing, how often are you committing, how many other services is your software dependent on, how often are those services also released, and so on. How often you are releasing determines the amount of new or changed code that needs to reach production. If you are releasing once a year, the amount of such code will be huge. If you release every two weeks you will have less such code, and in case a failure would occur in the software, it would be much easier to pinpoint the root of the problem (as compared to the one-year release cycle). If you are releasing rarely, with large amounts of time between releases, you really should run your tests at least once a week. From my experience, this test run frequency makes running these tests worth it, since you have a good amount of changed[…]

    17.10.2018 | 11:17 קרא עוד...
  • Let’s stop talking about testing, let’s start thinking about value

    Let’s stop talking about testing, let’s start thinking about value This year Alex Schladebeck and I did two keynotes titled “Let’s stop talking about testing, let’s start thinking about value” at QA Expo in Spain and TestNet in the Netherlands. This blogpost has the most important points we made in our talk. The keynote was inspired by some of our frustrations: “Testing is under appreciated” (Alex) and “Most testers are unable to explain what we do” (Huib). I wrote about my frustration back in 2016 already. This blogpost is about my frustration that most testers cannot come up with a decent definition of testing. And even worse: a big majority of the people who call themselves professional testers are not able to explain what testing is and how it works! They have trouble explaining what they are testing and why they are doing specifically the thing they are doing! How can anybody take a tester seriously who cannot explain what he is doing all day? Alex’s frustration is that testing is not valued by others. Developers are seen as the rockstars of the project because they create the software that adds value. But why are testers often not valued? Lowered expectations for testing expertise by stuff like ISO standards and ISTQB: I wrote about certification and standards before. ISTQB and standards put too much emphasis on process and documentation, rather than the real testing. By assuming there can be a standard, you say that there is one best way to organize and document your testing. But isn’t your test strategy[…]

    17.10.2018 | 5:05 קרא עוד...

טיפים

לרשימה המלאה >>