Automation & Mind

Automation testing started. What are all in my (your) mind?

· Is application stable?

· Need to analyze the requirement.

· What are the pages/modules involved.

· What manipulation happens to the data?

· What kind of framework need to be implemented?

· Need to improve in-depth knowledge of the domain.

· Will my framework applicable for web application?

· What are the field validations?

· Where is information stored in the database?

· Questions related to object handling in the application.

· Are the business rules that manage the process?

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.

Testing is Hyped

• Good QA testers are worth their weight in gold.

• Unit testing finds certain errors; manual testing others; usability testing and code reviews still others.

• The peer pressure of knowing your code will be analyzed on providing higher quality.

• Another huge problem with developer tests is that they won’t tell you if your software sucks

• No single technique is effective at detecting all defects.

• Testers are a developer’s editor.

OSDLC

MaximuM ExposurE (M2M - E2E)
OSDLC [Original Software Development Life Cycle]

1. Development team constructs a code that they believe it’s a bug-free.

2. The build is tested and 15 bugs are recognized by testing team and 5 are known issues from the dev team.

3. Programmer resolves 10 of the bugs and clarifies to the testing team that the other 5 aren't actually bugs.

4. Testing team finds that 5 of the fixes didn't work as anticipated and notices 15 fresh set of bugs.

5. Recursion for steps 3 and 4.

6. Since there are various marketing demands and a really untimely product declaration based on overly-optimistic programming schedule, the product is released by pushing the code into the production instance.

7. Users locate 125 new bugs which has some domain issues which we never consider as a bug.

8. Original developers are cashed for their great work, is nowhere to be found in that office surroundings.

9. Newly accumulated programming group fixes almost all of the 125 issues but brings in 350 new ones.

10. Original developers more often visits that product’s testing team and enquires about the good and bad things about that product. [At some point, the entire testing department quits.]

11. The company might be traded by the competitor using earnings from their latest release, which had 500 bugs.

12. New CEO is taken place in by the board of directors. He employs a set of programmer to recreate the product from the square-one & an automation test groups for regression process.

13. New Development team constructs a code that they believe it’s a bug-free.