Agile Methodology

1. Delivers the maximum business values early on in the project.

2. Promotes customer happiness.

3. Provides customer driven approach.

4. Spotlight on the speed of delivery.

5. Provides frankness and visibility to customers.

6. Removes obstacle in a prioritized and systematic manner.

7. Improves employee maintenance by empowering employees and by promoting self-management, team communication, learning, and value-building.

image courtesy: Google

Product Piece Proficiency Points

Client Happiness Index [CHI]
Delivered Deficiency Declaration [3D]
Key Product Observant [KPO]
Product Flux [PF]
Error Matrix Indicator [EMI]
Flaw Abolition Track [FAT]
Gauge Of Delivery [GOD]
Test Coverage Catalog [TCC]
Cost Of Defects Exposure [CODE]
Consistency Of Product Systematized [COPS]

Benchmarking

“Benchmarking” is the practice of evaluating your system’s performance against a baseline that you have created internally (or) against an industry standard certification by some other group/organization.

In the case of a Web application, you would run a set of tests that follow with the specifications of an industry benchmark in order to capture the performance metrics necessary to determine your application’s benchmark score.

You can then compare your application against other systems (or) applications that also calculated their score for the same benchmark. You may choose to tune your application performance to attain (or) surpass a certain benchmark hits.

Some considerations about benchmarking include:
• You need to play by the protocol. A benchmark is achieved by working with industry terms to meet such standards. Benchmarking involves identifying all of the necessary components that will run together, the market where the product exists and the specific metrics to be considered.

• Because you play by the rules, you can be clear. Benchmarking outcome can be available to the outside world. Since comparisons may be produced by your competitors, you will be using a strict set of standard approaches for testing and data to ensure reliable results.

• You reveal results across various metrics. Performance metrics may involve load time, number of transactions processed per unit of time, Web pages accessed per unit of time, CPU usage, memory usage, searches, and so on.

Standard Bug Post will have?

Bug Summary: [Summary of what happened.]
Bug ID: [Hope most of the tracking tool will automatically create by itself.]
Area Path: [Where the issue is present?]
Build Number: [Version Number which you get in mail from Dev Team.]
Severity: [Text, Tweak, Minor, Major, Crash & Block.]
Priority: [None, Low, Normal, High, Urgent & Immediate.]
Assigned to: [Developer-XYZ]
Reported By: [Hope most of the tracking tool will automatically pick by itself as you would have logged-in.]
Category: [Design Issue, Functional Bug, JavaScript Error (Web app), Added Feature & On Hold.]
Status: [New/Assigned/Resolved/Reopened/Acknowledge/Close] (Depends on the Tool you are using)
Environment: [Windows XP/SQL Server 2005]
Computer Resolution: [Check with your monitor resolution.]
Description: [Precise explanation about the bug.]
Steps To Reproduce: [Optional, when Description is understandable.]
Expected result: [What the exact functionality need to do.]

Software Testing Reviews

Inspection: It is a more methodical and careful type of peer review. Inspections are more effectual at discovering defects than the informal reviews.

Pair Programming: In Pair Programming, two developers work jointly on the same program at a single workstation and constantly review their work.

Pass About: It is a multiple - parallel check where several people are invited to offer observations on the product.

Peer Desk test: In Peer Desk check only one person as well as the manager examines the work product. It is a casual review where the reviewer can use defect checklists and some investigation methods to increase the efficiency of the code/product.

Team Reviews: It is an intended and structured approach but less official and less fussy comparing to Inspections.

Walkthrough check: It is an informal review because they typically do not follow a distinct procedure, do not denote exit criteria, require no management coverage and produce no metrics.

Responsibilities As Who?

Testers & Test Lead

- Recognize the Application under Test.
- Get ready for a test strategy.
- Help out with preparation of test plan.
- Design high-level sections.
- Build up test scripts.
- Realize the data implicated.
- Perform all the assigned test cases.
- Record the flaws in a defect tracking system.
- Retest fixed defects.
- Assist the test leader with his/her tasks.
- Provide advice on defect triage.
- Computerize test scripts.
- Understanding the SRS.

QA Manager

- Preparation of System Test Plan.
- Structuring of the Test Team.
- Programming the test preparation.
- Module distribution.
- Walk through on Test Process.
- Client relationship management.
- Verify the Status information.

Project Manager

- Preparation of SRS.
- Configuring the Development Team & Test Team.
- Management of necessities throughout the project life cycle behaviors.
- Research on Detailed Design Document.
- Analysis of Unit Test cases and Integration Test cases.
- Guidance on programming and linked coding conventions & principles.

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.

Build a great brand experience

It’s really hard to build a brand. It’s hard to get the attention of others, it’s hard to get people onto your website, and it’s hard to create something that people will buy and use. We realized early on that the best visitors we get hear about us through word of mouth. Word of mouth is driven by happy people who have a great brand experience.

This is how we’ve focused on building a great brand experience:

1. Trust : A great brand experience needs to establish trust between the business and its customers. We establish trust by giving surprisingly honest feedback to customers (such as sending them to a competitor if they’re not a good fit), making it easy for anyone to get in contact with us (by putting a phone number on our website), and focusing on coaching instead of selling.
2. Do the work for the customer : We try to do as much work for the customer as possible. This means spending extra time designing a product to simplify the first time experience, asking for the least amount of information needed to solve a problem, and putting the onus on us to do the work.
3. Creating a genuinely useful product.
4. Surprise people with greatness : Give people unique and useful things that they’ll actually use. Give out the best quality t-shirt you can find instead of settling for the standard Hanes. Give people unique things they couldn’t get anywhere else. Give people something that will make them feel proud to support you.

Brand is everything. It’s every interaction with someone outside of your business. It’s your company culture. It’s your production process and the way you deal with a bug.

The secret to brand building is to start early and often. Your brand is not your logo or color scheme, it’s how people think about you. It’s the way that you represent yourself.