JIRA Query to find the list of issues updated in a month

As a process, we need to make an effort variance report every month for all the applications tested b y our team.  We use JIRA to log the efforts for each item.

Effort Variance = (Planned Efforts-Actual Efforts)/100

Following query may be used in JIRA to help:

project = TEST AND assignee in (“abc@xyz.com”,”pqr@xyz.com”,”ijk@xyz.com”) AND updated >= “2014/06/01” and updated < “2014/07/01”

The above query would list all issues for the project ‘TEST’ having assignee among ‘abc’, ‘pqr’ or ‘ijk’ which were updated in the month of June-2014.

The query can also be modified as per needs…:)

Find the RSS Feed URL for a web page

Well, it’s nothing new, but still, below are the steps to find the RSS feed URL of a webpage (website, blog, or any particular post/page).

1. Navigate to the website

2. Right click anywhere on the page
3. Click View Source
4. Type Control + F
5. Type “rss”in the search text box and click Next 

6. The URL highlighted in black rectangle is the rss feed URL.
7. Click on the URL or copy and paste it anywhere required.

Smoke Testing and Sanity Testing

Apart from similar names, Smoke Test and Sanity Test, both aims at reducing testing efforts. No doubt they are confused for each other.

Smoke Testing
Smoke Testing is the very basic and initial testing activity that verifies if the application/deliverable is testable or not. I read somewhere that “Smoke testing is like General Health Check Up”. It is generally applicable during Integration Testing, System Testing and Acceptance Testing.
Only positive scenarios are validated in Smoke Testing.

Scope – The set of test cases which verifies the functionality on a high level. Some basic scenarios may include:
1. Tester is able to access the application/deliverable.
2.  Tester is able to navigate through the application.
3. The user is able to interact with user interface.

Example– Following may be the test cases for a login page:
1. ‘OK’ button is logging in the user on entering some data in user name and password.
2. Cancel button is responding entering some data in user name and password and user remains on the same page.
 Type anything in the username and password field and press the OK button, the page should change and the request should have gone to the database to confirm if it is a valid request or not.

Advantages of Smoke testing:
1. Issues that arise due to integration of modules can be found.
2. Issues are found in the early phase of testing.
3. Induces confidence to tester that fixes in the previous builds have not broken major features.

Sanity Testing
Sanity Testing is a part of Regression Testing and it is performed when we do not have enough time for doing testing. I read somewhere that “specialized health check-up”.
Sanity Testing covers both positive and negative scenarios.

Scope – The set of test cases from regression test suite which quickly verified status of the product after they have done changes in the code or there is some controlled code change in a feature to fix any critical issue. Care must be taken care to:
1. Include only critical test cases in BVT.
2. Only stable test scenarios should be included
3. Test cases included should be sufficient for application test coverage.
Example Following may be the test cases for a login page:
1. ‘OK’ button is logging in the user on entering valid data in user name and password.
2. ‘OK’ button is not logging in the user on entering invalid data in user name and password.
2. Cancel button is responding entering some data in user name and password and user remains on the same page.
Some of the Test cases for Text editor may be:
1) Creating text file.

2) Writing something into text editor
3) Copy, cut, paste functionality of text editor
4) Opening, saving, deleting text file.

Advantages of Sanity testing:
1. Makes sure that developers have not defined conflicting or multiple functions or global variable definitions.
2. Helps to identify the dependent missing objects.
To conclude, consider purchasing a vehicle – Car or Bike.
We take it for a test ride and check basic functionalities– Smoke Test
We bring it home, ride it more and check detailed information (Mileage etc) – Sanity Testing

Regression Testing and Retesting

Difference between Regression Testing and Retesting is another one of the most frequently asked question in Software Testing interviews. So, a very straight forward and crisp answer would be –
Re-testing is the verification of defects to confirm that the functionalities are working as expected. When a bug is fixed, the test cases which failed with reference to it are executed again.
Regression Testing is performed to verify that any changes to the code (bug fixes, enhancements, code cleanup etc.) have not impacted the untouched or other functionalities of the software/application.
For example:

  • Consider an application ‘abc’ with modules ‘a1, b1 and c1’.
  • Some bug fixes are to module b1.
  • Retesting – Testing the bugs raised and module b1.
  • Regression Testing – Testing the areas affected by module b1 on a1 and c1.

Regression Testing
Image Source: MS Word Clip Art
The image above also represents basic Regression Testing and Retesting concept:
Rotten apple spoils the barrel –
Ensure the rotten one is removed ~Re-testing
Always go through the rest ~Regression Testing
Following is a detailed description of differences between Regression and Retesting.


Regression Testing

Retesting is performed to make sure that the tests cases which failed in last execution are passed after the defects against them failures are fixed.
Regression testing is performed to ensure that changes like defect fixes or enhancements to the module or application have not affected the unchanged parts of application.
Retesting is carried out based on the defect fixes.
Regression testing is not carried out on specific defect fixes. It is planned as specific area or full regression testing.
In Retesting, the test cases which failed earlier are included in the test suite.
In Regression testing, test cases which impact the functionality of application are included in the test suite irrespective of their passed/failed status in earlier runs.
Test cases for Retesting cannot be prepared before start testing. In Retesting only re-execute the test cases failed in the prior execution.
Regression test cases are derived from the functional specification, user manuals, user tutorials, and defect reports in relation to corrected problems.
Automation for retesting scenarios is not recommended.
Regression scenarios are the first candidates of automation testing
Retesting is performed before Regression.
Regression testing can be carried out parallel with Retesting.


Quality Center(QC) Site Admin Error: [Mercury][Oracle JDBC Driver][Oracle]ORA-28000: the account is locked

Yesterday, while performing some activities in Quality Center Site Admin, I got following error on one of the projects.
Failed to Get Users In Project;
Failed to get users of project id = ***;
Stack Trace:
com.mercury.jdbc.base.BaseSQLException: [Mercury][Oracle JDBC Driver][Oracle]ORA-28000: the account is locked
**I have clipped the rest of stack trace
I got the idea but still, in an effort to not to contact the DBA, I deactivated the project. On trying to activate the project, I again got following message.

Failed to Get Projects Properties;
Failed to get projects properties;
Failed to save projects properties;
Cannot build directory item for key ‘[***_db@jdbc:mercury:oracle://***:1521;sid=***(***_db)]’ in TD Tables Struct Dir;
Failed to fill table struct for table null in database ***_db@jdbc:mercury:oracle://***:1521;sid=***(***_db);
[Mercury][Oracle JDBC Driver][Oracle]ORA-28000: the account is locked
 **I have clipped the rest of stack trace
The solution was very simple. I did not have to do anything here. I just dropped an email to the DBA asking him to unlock the account. Bingo!!!
Still if you want detailed solution from DBA end, following link may help:

Principles of Software Testing

Following are the seven principles of Software Testing as per ISTQB syllabus. The principles are very basic and if remembered, may prove very-very useful and sometimes help in resolving misconceptions. The very one or two liners description says it all about them, so I have not edited the contents:
Source: ISTQB Foundation Level Syllabus

Principle 1 – Testing shows presence of defects
Testing can show that defects are present, but cannot prove that there are no defects. Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness.

Principle 2 – Exhaustive testing is impossible
Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, risk analysis and priorities should be used to focus testing efforts.

Principle 3 – Early testing
Testing activities should start as early as possible in the software or system development life cycle, and should be focused on defined objectives.

Principle 4 – Defect clustering
A small number of modules contain most of the defects discovered during pre-release testing, or are responsible for the most operational failures.

Principle 5 – Pesticide paradox
If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects. To overcome this “pesticide paradox”, the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.

Principle 6 – Testing is context dependent
Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.

Principle 7 – Absence-of-errors fallacy

Finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations.

Software Testing – Myths and Facts

“Software Testing is relatively new” – I get irritated whenever I hear or read this. As if before the term, software’s being developed were not tested. Oh, I used the relatively new word again – checked for their expected behaviour.

Image source: http://qld.greens.org.au/sites/greens.org.au/files/u4412/fact%20or%20fiction.jpg
So, when we talk about myths about software testing, the above stands on top. There are few more I have tried to jot down in no particular order. Let’s see if you agree.

1.  Software Testing is relatively New
I do not need to write anything for this. We get to hear this ironic term at all places – big or small.

Fact:  It has been existing ever since first piece of code was written.

2.  Testing is boring
Testing being a monotonous activity is reflected very frequently at almost every platform. People have a misconception that testers keep on doing the same old clicks and data entry without any creativity.

Fact: A statement somewhere on internet says it all – “Testing is like sex. If it’s not fun, then you are not doing it right.”

3.  Testing is easy/No formal training is required
Testing being an easy job is another big misconception. There are arguments all over the world that since users keep on finding bugs, it’s no big deal being a tester. Sometimes, a proper planned formal training for the same is also neglected.

Fact: Many times testing proves to be more complex and tedious than development as its difficult to analyze the behavior without code (I am not saying that developers have an easy job, but access to code gives an edge on analyzing the behavior), Testers require a deep understanding of testing methods, business requirements and the development process.
Formal training and experience makes a good tester with solid skills or we can say a valued resource.

4.  Anyone can test
I cannot forget the statement by one of my managers – “Amita, don’t fell offended, but the fact is that testing can be done by anyone. I mean, you need special skills and technology knowledge to develop the software, but testing can be performed by developers as well.”

Fact: If that was the case, no company would have paid a dollar to testers. There would have been no companies that specialize in only testing services. This is the trap management falls into.

5.   A tester’s job is to find “ALL” bugs
100% test coverage is one of the top goals of most of the testers. This is the most common myth which clients, Project Managers and the management team believe in.
Fact: This is the trap management fall into. The very first principle of software testing states that – “Testing shows presence of defects”. Testing shows that defects are present, but cannot prove that there are no defects. Even if no defects are found, it is not a proof of correctness.
6.   Automated Scripts replace manual testing
Whenever I give a POC for automation, people have an impression – “Wow! Just click and all done!” Statements like – “So, if you create the scripts once, we can just run them for next releases”. This is the most common misunderstanding that automated tests are equivalent to manual tests. The worst is that there are testers and test managers who actually believe it.

Fact: No test automation tools can ever replicate human feelings or emotions.
For example, a tool can test the fonts, color and layout of a screen is as per the test script but it can never analyze if a screen is user friendly.
7.    Software Testing is “time consuming” and “expensive”.
I personally get the emails to revise our estimates for testing efforts very frequently. Sometimes, I hate to justify the minute details of my estimates. The considered myth that its too much effort – “time consuming” automatically generates the next one – “Expensive”.

Fact: Software testing principle 3 – Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.
One cannot expect the testers to be magician and test the code overnight when they have no idea of background.
Decide – Pay during development or pay latter for production issues and reputation.
8.  Software Testing is same as Quality Control
I can bet that almost 90% people confuse testing with quality control. Software Testing, Quality Assurance and Quality Control are the terms used almost interchangeability.

Fact: Testing is just a component of software quality control, wherein a tester identifies the bugs for the stakeholders. Quality Control include many other activities like Reviews – Self review, peer review and structured walk through

9.  No changes – Regression testing is not needed
Regression Testing is skipped many times to save efforts. There has been no change in this code is the most common excuse to that.

Fact: Even if the module was not touched, spending some bucks on re-verifying the results may save the cost of an unidentified bug or scenario.

10. Software Testing is the career choice for failures
Fresher’s dread the software testing field. They think that it does not offer career growth and is a low profile job.

Fact: Think again. Facebook, Microsoft etc. pay millions to find a bug.

These are the most common myths I have faced during my career. If you have any additions, or faced similar experiences, please feel free to comment or share. This does not do not welcome general like/dislike comments. I love them the most… 🙂

Mercury Screen Recorder: MSR or HP Screen Recorder

Mercury Screen Recorder or HP Screen Recorder is an add-on provided by HP Quality Center/ALM which enables users to capture movies of events on their PC/screen. The users can use these movies to report bugs back to development teams.
Details for downloading compatible versions can be seen on below link:
Below are some of the salient features of Mercury Screen Recorder:
  1. Easy to operate
  2. Built-in Movie Editor
  3. Availability of Exporting the Movies to Different Formats There are five file formats that can be exported from Mercury Screen Recorder:
·         Standalone EXE
·         Flash
·         AVI
·         Windows Media Video (WMV)
·         MS PowerPoint
There are two separate applications included in a Mercury Screen Recorder installation: the Recorder and the Player.
  • The Recorder application records what happens on your Windows desktop and saves this as a movie file. It can also record a spoken commentary, if you have a microphone connected to your PC.
  • The Player application plays back movie files created by the Recorder, to display a recreation of what was seen during recording. The Player can also be used to edit, annotate and export the movies to other file formats.
Prerequisites for using MSR:
  1. Quality Center client must be installed, or Mercury Screen Recorder will not run.
  2. User must be able to connect and authenticate to Quality Center server.
  3. Mercury Screen Recorder will use one ‘Defect’ licence on the connected Quality Center server while running.

Following are the steps to Install Mercury Screen Recorder: 
  1. Open http://qualitycenter:8080/qcbin/ 

  2. Click on “Add-ins” link. 
  3. Click on “More Mercury Quality Center Add-ins” link. 
  4. Click on “Mercury Screen Recorder Add-in” under section “Others”. 
  5. Mercury Screen Recorder add-in page as shown above will be opened. 
  6. Click on “Download Add-in” link.
  7. Either “Save” it on your machine or click on “Run”. 
  8. Again click on “Run” on security warning window. 
  9. Mercury Screen Recorder is installed on your machine. 
  10. Check Start–> All program –> Quality Center 9.0 –> Mercury Screen Recorder.
In addition to the salient features, following are some more advantages of Mercury Screen Recorder:

  1. Tester need not waste time in typing the steps to reproduce and attaching snapshots. The same can be      recorder by the tester.
  2. The recording can be directly attached to a defect in Quality Center.
  3. Saves time, prevents confusion/conflicts.
  4. Movie watching is always better than reading.
  5. Can also be used to record a demo on applications which may also be saved for further reference.

Quality Assurance and Quality Control – QA Vs QC

Before I jump into the title of this post, I would like to touch upon the base term – ‘Quality’.

If I look into oxford dictionary as a layman, I get the following definitions of the word ‘Quality’.
  • The standard of something as measured against other things of a similar kind; the degree of excellence of something.
  • A distinctive attribute or characteristic possessed by someone or something.

Everyone has their own interpretation of quality. Broadly, Quality means “conformance to requirements”. ISO 9000’s states quality as – “degree to which a set of inherent characteristics fulfils requirement”.
Coming to more technical details,

A Product developer will define quality as– The product which meets the customer requirements.
The Customer will define Quality as – Required functionality is provided with user friendly interface.

With reference to quality, QA and QC are two terms that are used most frequently and almost interchangeably. Let’s define both the terms.

Quality Assurance (QA): It may be defined as processes of software quality that assures that the standards, processes, and procedures are appropriate for the project and are correctly implemented.
QA refers to the maintenance of a desired level of quality in a service or product, especially by means of attention to every stage of the process of delivery or production.
There are two principles included in Quality Assurance:
  1. “Fit for purpose”, the product should be suitable for the intended purpose
  2. “Right first time”, mistakes should be eliminated.

Quality Control (QC): It may be defined as the function of software quality that checks that the project follows its standards, processes, and procedures, and that the project produces the required internal and external (deliverable) products. It is performed by testing a sample of the output against the specification
If I have to differentiate between the two, I would do that as –
Quality Assurance is the process of managing for quality that makes sure you are doing the right things, the right way.
Quality Control
verifies the quality of the output and makes sure the results of what you’ve done are what you expected.

Quality Assurance Vs Quality Control (QA Vs QC)

Quality Assurance
Quality Control
It is a proactive quality process.
QC is a reactive process.
The goal of QA is to improve development and test processes so that defects do not arise when the product is being developed.
The goal of QC is to identify (and correct) defects after a product is developed and before it’s released.
Verification is an example of QA
Validation/Software Testing is an example of QC
QA is a managerial tool
QC is a corrective tool
It does not involve executing the program or code.
It always involves executing the program or code.
All peoples who are involved in the developing software application as responsible for the quality assurance.
Testing team is responsible for Quality control.
Establish a good quality management system and the assessment of its adequacy. Periodic conformance audits of the operations of the system.
Finding & eliminating sources of quality problems through tools & equipment so that customer’s requirements are continually met.
Quality Assurance is the process of managing for quality;
Quality Control is used to verify the quality of the output
Quality Assurance is process oriented
Quality Control is product oriented
It identifies weakness in processes to improve them.
It identifies defects to be fixed.
It is done before Quality Control.
It is done only after Quality Assurance activity is completed.
Quality Assurance means Planning done for doing a process.
Quality Control Means Action has taken on the process by execute them.

Toastmasters – Project#5 – YOUR BODY SPEAKS – An Evening at DDA Sports Complex

  • Use stance, movement, gestures, facial expressions and eye contact to express your message and achieve your speech’s purpose.
  • Make your body language smooth and natural.
TIME: Five to seven minutes.
I had written this speech long time back but did not deliver it as my mentor feared that the content was so easily available online. I could not help it. I thought of topic and as I googled it, there were many results. Anyway, I tried my best to make it as original as possible.
I also used printouts for each category and pasted them asking the audience to guess the type by looking at picture. Here it goes…
An Evening at DDA Sports Complex
Every evening, my mother in law gets ready and calls – “Chalo Ricky”. Ricky ignores and keep on hanging in between my knees or on the pockets of my jeans. He continuously repeats – ‘Ma, ma, ma”. Reason? Because, I have the car keys in my hand. So I would be going out!. The car keys switch hands and Ricky’s hanging garden switches along with that. We start the engine and steer ahead to Ricky’s favorite place – The sports complex. The moment you step into a sports complex, I cannot help but notice the different types of mommies over there. I have tried and categorized them into 5 common categories. Obviously, there are more moms than papas. May be this is the reason I would be referring mom and not papa. Of course the points I noticed applies to papa as well.  
The first and most looked up to is the –
The Super fit/unfit mom
Well, be it a boy or a girl, we cannot “not turn around to get jealous or admire that rocking body.” She had a baby a month back? She could be an inspiring workout buddy. In the meantime, ladies, do not get your guy notice that. If she has been noticed, have a look around, you would definitely get a mom who is in a bad shape than yourself.  Pradeep, my husband get to hear – “Have you seen xyz??? If I was fat, I would have been like her!?”.
Baby No! – Mom
The kid tries to jump off that slide, “No baby”. The kid runs to next ride and she has to get up and follow him, “No baby”.  “No, do it this way, Darling,”.  this mom will not only direct her child as to what playground item to play on next, but will tell you and your child what to do as well. She may be the one who is continuously on her latest iPhone. “Yes yes… The presentation was awesome”. Beta don’t go there. “ya… Oh you got those stilettos!!!”
The Poor mom
There’s no missing this one. She’s exhausted! She’s broke! She is Poor lady. Her kid is at its best at throwing tantrums. He/she is lying flat on the grass or the worst in the middle of a slide when 4-5 children are waiting patiently for the slide to get clear. What the kid is doing lying there? Crying at the top of his voice. Nothing is going to calm that child. He himself has forgotten why he started crying. He is just – aaaa   uuuuu….. His eyes are flooded with tears, his cheeks have gone blood red and the poor mom is trying everything in the world – Get up beta. Beta at least tell me what happened. Ok, get up and we would have a chocolate. Look there is a peacock. See the aunty is saying – haaaww, such a bad baby!!!. Get up now… or you are going to have the worst moment of your life. Ok fine. Keep lying here. I am going.
But here’s what’s actually pretty good about this mama: You’re off the hook when it comes to small talk. You don’t have to contribute anything but a few nods.
My nine month 11 kg kid does not eat anything – mom
She is running behind her kid all the time with a box of sandwiches, a fruit, or water. She’s convinced that her child is on the verge of starvation and that it’s only a matter of time before he faints from malnourishment.  And the child of course he is starved to death. He is doing whatever he can do not have that food. Deny, run away, cry, plead, take in mouth and throw away. Everything!!! Reyansh? My kid? He would pretend he is not listening. If he does, he would poke his finger into my own mouth and try to push the eatable into my mouth
The perfect mom           
All the moms, no need to feel guilty. All the fathers, no need to go back and give an example to your better half. And all those who are still not parents, no need to look up for some one. This “Perfect Mom” does not exist.
Every mom is funny In her own way. But, don’t forget that she is funny because she loves you. She would anything in world to get a hug from you and see that little twinkle in your eye whenever you smile. She does not have any other task in the world but her child. I learned this after I was born again on 7th april 2012 – the day I became “Ma”.
So, repeat after me – “Mummy,”. “I Love You”. Excellent, now do not forget to reciprocate it to your mom! Thanks.

Below was the evaluation:-

  • Met the objectives
  • Good use of body language
  • Constructive suggestion would be – try and make your pauses bit smaller.
Timer report – 6 minutes 2 seconds
Grammarian Report –
  • used he-hear-her for him/her
  • Used “that” does not exist, but corrected herself for a human– “She” does not exist.
Ah Counter Report
·         Used cannot – not turn around (Although, I do not think it was mistake since it was meant to speak like this)

·         Used like-like twice