Let the clock talk

Software Testing is the art of ideas. Thinking in the clock’s approach is forever superior. Clock is the only thing which always thinks about ‘Time’, as its profession is that. As a tester, we involve in most of the time linked procedure. They are;

• Time to investigate a new feature.
• Time to analyze a requirement.
• Time to acknowledge a design page.
• Time to write a test plan.
• Time to carve-in a test case.
• Time to carry-out a test case.
• Time to re-test a test case.
• Time to write down a test report.
• Time to release the product.
• Time to take rest.

5 Whys in Software Testing

I hope all have heard about the 5 why methodology in general for a project. How it can be implemented in Software Testing?

5 Whys in Software Testing? What it intended for us? How does this be relevant to testing?

After production deployment, imagine that someone initially in your team locates a bug, your Project manager asks why this was not found earlier but he/she will tell someone to fix it then that issue will not be remembered as how it occurred. While focusing on a theme/topic, keeping questions in mind and assuming things is the dangerous segment of the requirement/development/testing phase. We hardly ask why an issue was reopened, where the issue was placed and whether some additional issues will occur because of the hot fixes. We need to get rid of the bugs. A good ‘Unit Testing’ could be a solution in this kind.

Conclusion: Keep asking WHY for most of the answers until you are satisfied. You will be satisfied with 4th/6th why. But try to avoid bizarre questions.

Have a great testing day.

Software Tester - Best Practices

As a Software test engineer, our important task is not only writing the test plans/test-cases & filing the bugs. We have few more apexes to be balanced with our testing effort. They are as follows;

(a)Performing a domain knowledge transfer (DKT) to the team with regards to the data collected.
(b)Analyzing how the issues can be sorted out in the code level review for application performance.
(c)Ordering test strategies & test selection techniques ought to be prioritized.
(d)Reviewing UX/UE documents.
(e)Scheduling the prerequisite for a project before the requirement scrutiny starts.
(f)Sheltering the success with the testing process/methodology which is been applied.

CAR in IT!!!

Question: What is CAR?
Answer: Chuck Away the Requirements.

- Understanding of the proposed requirements.
- Pointing out the gaps and raising queries.
- Quick assessment & certification of a feature.
- Determining if an idea is achievable or not.
- Test coverage for that feature.

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.

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.