BACB = 0 – Intro

Making the first move for “Being a Cordial Bugzy” ["BACB"]

Meaning for “Being a Cordial Bugzy” : “Im here to Share my Info related to Software Technology”

Test comrade in "Google" Search

Searching on "Google" for “Test comrade”, it goes for “You Failed Your Math Test, Comrade Einstein”. I’m happy to see Einstein’s name when my blog name was searched.

Top Link(in Google) for the text "Test comrade" is:

Test comrade

T-minus Witness

The list of other types of testing we'd like not to see:


- AGRESSION TESTING: If this doesn't work, I'm gonna kill somebody which can include me.

- COMPRSSION TESTING: [---]

- CONFESSION TESTING: Okay, Okay, I did program for that bug.

- CONGRSSIONAL TESTING: Are you now a bug (or) have you ever been a bug before?

- DEPRESSION TESTING: If this doesn't work, I'm gonna have a bloodbath.

- EGRESSION TESTING: Uh-oh, a bug... I'm outta here and who am I???

- DIGRESSION TESTING: Well, it works, but can I tell you about my truck (or) idea how I made that...

- EXPRESSION TESTING: #@%^&*!$!)!|, a bug.

- OBSESSION TESTING: I'll find this bug if it's the last thing I do.

- OPRESSION TESTING: Test this now!

- POISSION TESTING: Alors! Regardez le poission! அயோ பாவம்!

- REPRESSION TESTING: It's not a bug, it's a new feature.

- SECCESSION TESTING: The bug is dead! Long lives the bug! What you want me to do?

- SUGGESTION TESTING: Well, it works but wouldn't it be better if blah blah blah...

Came through an article and saved the content and added some more myself. Thanks for this article.

Usecase Format and Example!!!

Usecases for the {Functionality Name}
--------------------------------------

UseCase Name: [Give a reasonable name for the usecase.] [Usecase Id]
[Sample Format >> Tab-name_functionality_Report] [Sample Id >> (UCTNFR001)]

Actor: [The users who are going to operate the product/application.]
[Sample Actors >> New User/Vendor/Manager]

Assumption: [Assuming the actor would have done those steps to execute this use case.]
[Sample Assumption >> User is a registered user.]

Description: [Precise synopsis about the functionality.]
[Sample Description >> Adding the item(s) in the shopping cart. {Present Tense}]

Steps:
[Steps to complete this functionality (don’t include the assumption{s} in the steps.)]
[Sample Steps >> {Present Continuous Tense}
1. Actor adds an item with cart ID, item ID and quantity.
2. System checks if the inventory is enough.
3. System updates the inventory level.
4. Updated shopping cart contents and total price are displayed.]

End state: [Need to put in the picture like Actor finished that functional procedure successfully.]
[Sample End State >> User adds item{s} to the shopping cart.]

The below list is an extra to a normal Use-case;

Negative Flow: Apart from the primary flow/primary steps, if there is any Wireframes(if available both for positive and negative flows) & negative steps; that can also be mentioned. 

[Sample Negative Flow >> If user clicks on 'Cancel' button, then application navigates to Home page.]

Note: Make sure the flow/steps is complete/sensible when other than you reads it.

How to be with Development Team?

1) Be neutral with your views.
2) Distribute the bitter flavor in a sweet-coated capsule.
3) Aim to go up against your valuable points at the requirements phase.
4) Sustain a sugary language while discussions.
5) While partying, involve freely with them.
6) Pointlessly, don’t exchange a lot of rigid expressions.
7) In vital circumstances, administer the stuffs in an apt way.
8) Sharing the sensible thoughts (or) suggestion.
9) In a roundabout way, shoot the blunders committed by them.
10) Make an effort to avoid miscommunication & get a good name from them.

Epitome of Testing

For those who are not familiar with the word ‘Epitome’, it’s nothing but “Essence”.

As a person in a QA/Tester role there are a number of typical roles that can be approved.

• Sheriff – Bringing order to the Wild West. Chaotic development processes are roped in and consistency and discipline instilled in the vacuum.

• Cheerleader – Pumping the team up to be more than they are. ‘Better unit tests? Way to go’

• Cop – More or less the opposite of the Cheerleader. While typically you get more flies with honey, sometimes you do have to bring out the vinegar.

• Negotiator – An active role in figuring out the trade-offs between development and test.

• Marketer – A longer-term variation of the Negotiator which uses more subtle techniques for furthering agenda.

• Coach – Strategist and morale support.

-Se7en Deadly Sins-

Lack of "Lust for finding Defects" – Lust could be an objectionable vice in the Bible, but in the "Bible of Software Testing", lust is a good thing; lust for finding defects that is. Have a craving, appetite, or great desire towards finding defects is something that differentiates a great tester from that of a mediocre one. Once this lust dies down inside a tester’s heart, it would be very difficult to keep going.

Having said this, I do realize that there could be times like the "tester’s block syndrome" [a condition, associated with testing as a profession, in which a tester may lose the ability to find new bugs and defects in the software that (s)he is testing]. It can happen with anybody. But don’t let it become the end of the world for you. If you are struggling to find bugs in the software and feeling burnt out, "change the way you have been testing" – adopt new test ideas, try new ways to find where the AUT (application under test) might be broken, try out pair testing, explore new unexplored areas of the AUT and even try taking a short break. And still, if nothing at all works... then change your AUT! I know how difficult it can be to change the AUT (and your project) in certain contexts. In such cases, try out new applications (there are tons out there begging to be tested; just look around) and once you start finding defects in the new AUT, it won’t be long before you would start discovering defects (again) in your old AUT.

Envy – If you are in the field of testing then I can almost certainly bet that you must have come across testing teams where only few team members perform exceptionally well and the others instead of taking it as a reason of motivation rather feel envious about them. Enviousness and jealousy leads to hatred and hatred in turn takes you further away from the path to success.

Lack of "Greed for Knowledge" – Like lust, greed also is a good thing to have for a software tester. Some call it the "burning desire to learn" and others call it "the passion to excel", but to me they all mean essentially the same thing. Once some great mind said -- "knowledge is wealth/money". And it couldn’t be agreed more for software testing. I believe that a tester should be like a "search engine king", who is a jack of all trades and the master of many! As a test manager I would want my testers to be knowledgeable in every aspects of computing -- knowledge about programming languages, operating systems, web services, technology updates, gadgets, search engines, scripting skills... everything counts as long as they help the team to be better at testing.

Sloth – Laziness is not a luxury if you are in the software business; and the onus is even greater if you are a tester working in a tight testing schedule. In my opinion, this is one of the greatest sins a tester could ever commit – laziness in testing, laziness in learning new stuffs, laziness in updating your skills, laziness in showing interest in finding defects in what you’re testing... all can doom you and your career as a tester. So beware!

Wrath – Numerous situations may arise in a tester’s life where (s)he would find her/him against the team of programmer. But anger and wrath are never the solution to such scenarios. Hate the defects, NOT the programmer. Criticize the software that we test, NOT the programmer who coded it. And don’t ever forget that to err is human and if there were no errors, there would be no need for us (testers) in the team. Being diplomatic and factual with a small dose of humility can do wonders in dealing with any such adverse situations; NOT anger/wrath.

Pride – I can imagine how an occasional self-pat can help boost self-confidence and create room for the much needed motivation. But be careful NOT to overdo it and keep it at "occasional" level. Pride is probably the easiest gateway to witness failure and the feel-good factor associated with pride makes it even more dangerous.

Gluttony – Yes, I said that greed is a good thing for you if you are in the profession of software testing. But greed is not same as gluttony (over-testing, excess testing)! Learning to know where to stop testing is a lesser known art. If you didn’t find any new defects in the past hour of testing, then perhaps you wouldn’t find any, even if you extend the testing session for another couple of hours! In such cases taking a much needed break is a wiser decision than to extend the testing session. Furthermore, every test project is associated with budget constraints and you probably wouldn't want to make your testing efforts look like a liability to the whole project instead of adding value, would you?

Courtesy : Some Blogger

Bug Life Cycle