How to score runs in a developer's pitch?

When communicating or informing a developer that a bug is a bug, it's essential to be clear, precise, and provide sufficient information to help them understand the issue. Here are some steps to effectively communicate a bug to a developer;

Confirm the Bug: Double-check that what you're experiencing is indeed a bug and not an intended feature.

Share System Info: Mention your operating system, browser, or any relevant details about your setup.

Describe the Problem: Clearly explain what the bug is and how it affects the system.

Explain Expected Result: Describe what you were expecting to happen instead.

Show How to Reproduce: Provide step-by-step instructions on how to make the bug happen again.

Attach Screenshots or Logs: If possible, show visuals or error messages related to the bug.

Importance: Indicate how much the bug impacts the system's performance or functionality.

Follow Up: Check if the bug gets fixed and provide feedback if needed.

Be Friendly: Use a polite tone when communicating the issue.

Stay Available: Be ready to answer any questions the developer may have.

---

By following these simple steps, you can help the developer understand and address the bug more effectively.

---

 

ProTesting

In software testing, a dispute, complaint or objection can arise in any situations. Here is a general approach to handle such events;

1. Understand the problem: Get all the details about the conflict, complaint or objection in software testing.

2. Talk to the concerned person/group: Have a conversation with the people involved to better understand their perspective and concern.

3. Investigate the issue: Look into the problem thoroughly. Review test plans, cases, and other relevant information to find out what went wrong.

4. Find a solution together: Collaborate with the stakeholder to come up with possible solutions or compromises that address their concern.

5. Review the testing process: Check if the testing was done according to the established standards and procedures. Look for any mistakes or deviations.

6. Involve higher authorities (if needed): If the issue can not be resolved through discussion, seek help from management or higher-level authorities or friends from your organization.

7. Learn & improve: Reflect on the situation and see if there are any lessons to be learned. Make essential improvements to prevent similar issues in the future.

Finally ProTesting is how you solve the problems and be a professional in your career...

Remember, adapt these steps as needed to fit the specific circumstances you're facing...

THE

Testing HemispherE

Software Testing is a Globe, where you have 2 hemispheres.

One is Manual and the other is Automation. Most companies have both automated and manual testing efforts together. You might disagree but the fact is "there needs to be balanced Automated and Manual test approach for a process/product triumph."

High-quality productivity comes in when your manual test engineers have created a complete set of test cases that have immense traceability and test coverage, and then your automation engineers have automated your smoke & regression test cases.

Software Testing || QA

Test Automation || Product Testing

Continuous Integration || Regression Testing

WEST

WEb Service & Testing

Techniques such as White, Grey and Black Box testing relates to traditional systems, which directly sync-up into Web Services deployments.

However, the following uniqueness of a Web Services deployments introduce exclusive testing challenges:

*) Web Services are fundamentally distributed and are platform and language doubter.
*) Web Services can be a sequence with dependencies on the other 3rd party Web Services that can change without notice.
*) Web Services ownership is shared across various stakeholders.

Software Testing || QA

Web Services || AWS

Rubber Stamping Ideas in Software Testing

Rubber Stamping in Software Testing >> Re-Usability/Framework Usability in Automation.

1. The test scripts will be less expensive due to the better rubber stamping.
2. Modification to the test scripts won’t affect the test data.
3. Healthier rubber-stamping is attained only when the scripts are organized properly.
4. Open to any Test Tool.
5. Test cases can be performed with ample number of data when rubber stamping is fittingly used.
6. Simple script management.
7. Independent of Application under test and same script works for every level of testing.
8. Testing can be planned with/without AUT (Application Under Test).
9. It offers notable (Depends on type of framework).
10. Range of test scenarios can be executed by changing the test data in the external data (as most of us use xls file).

Spoofing For Testing

Hope you guys would have heard about the "Email Spoofing"....

If not, it’s nothing but to steal other’s personal information. When you open (or) view the spoofed email, you expose yourself to hackers who desire to access your inbox and personal records. Emails are spoofed and sent with an intention to mislead. It is considered an illegal activity.

So, what can spoof do for software testing?
Some spoofing points are as follows;
>> Uploading HTML/Script files in your application.
>> URL Injection.
>> Checking the expired Authentication Tokens.
>> Verifying the Bookmarked Web pages (in your application) with other logins.
>> Cookie Decryption.

There are bunch of points apart from the above. Make the best use of the spoofing & phishing techniques while doing software testing....

CT scan

Ever since our apps are on the cloud, we need to think testing as the same.

Functional & Performance Testing Tool, Defect Tracking & Test Management Tool, Capture & Playback Tool, Regression Testing & Database Testing Tool will be provided by service in TaaS.

TaaS means operating Software Testing with a group of people and tools.

1) Main drawback in general cloud service is the security of the data.
2) Another drawback is when some data disaster happens; revival of data will be complicated.

In some testing services, the Cloud Testing package offers the opportunity to access Test Tools with the Test Environments from anywhere around the world.

[CT scan - Cloud Testing scan]
[TaaS - Testing as a Service ]

Testing the Tester’s Pulse!

Height of frustration when our “Project Manager”/ “Team Lead” ask the following statements.

1. Are you sure, you have tested and verified the functionality?

2. Speed up and complete the sanity/regression testing soon as we need to push the latest code into the production instance.

3. It’s just a ‘Change Request’, it will take an hour to test those changes.

4. Guarantee me that, there are no bugs in this tested build.

5. I have a Client Demo within an hour/today, so just have the tasks done. Need this to be in live within the specified time-frame.

6. Are you bored on testing this application repeatedly?

7. Come on/ Plan for Saturday, Sunday or Holidays to test the application.

8. I didn’t have time to read your bug report. Just examine by yourself and close it.

9. Close all the bugs today itself and give an ideal defect report which provides a clear info. (Instead of using the term Testing.)

10. Kindly communicate with developer team and plan accordingly for all the bugs you have posted on Defect reporting tool.

Ergonomic Testing Treaty

= What’s Ergonomic Testing Treaty Is All About =

>> Is the product user friendly?
>> Is the product’s functioning procedure (i.e., Learnability) is in good quality?
>> Is the product’s menus are the right ones for that domain?
>> Is the product’s information presented in an understandable approach?
>> Is the product’s efficiency equivalent to some benchmarks provided by client?

Ergonomic Testing is most likely Usability Testing.

Ergonomic testing should be executed during Requirement/Analysis phase, with the help of a prototype!

Top Ten Open Source Bug Tracking Systems

Top Ten Open Source Bug Tracking Systems

I. Bugzilla > Connecting URL
II. Mantis > Connecting URL
III. Trac > Connecting URL
IV. Redmine > Connecting URL
V. OTRS > Connecting URL
VI. Request Tracker > Connecting URL
VII. Eventum > Connecting URL
VIII. BugGenie > Connecting URL
IX. WebIssues > Connecting URL
X. Fossil > Connecting URL

>Compiled From Different Websites<

Software Troubleshooting

◙ If software sucks, its sucks...that’s it! ◙

=> Stop writing bugs, Start writing superior code.
=> Dead test plans.
=> Developer who wrote the code for particular feature is actually a good tester. They are accountable for testing their own code.
=> Integration testing is where the testers scores points because normal testing can be done by development team. (Testing their individual functionality)
=> User's vision is what testing is. So study the domain & be that particular user.
=> Development team needs to focus on their own functionalities.
=> While bug posting, dev team need to give/provide reports on how/why the bug occurred/solved.
=> End-User never care about the tree, they care about the forest.

Https & Http

We had a simple concern related to Https & Http. This post can be valuable information to both Testing Team & Admin Team.

We modified our site’s URL from Https to Http as per the Client request. I carried it out and checked by refreshing the Home page (in all the browsers, as we were testing the application.) and verified that everything was all right.

When Client typed our site’s URL (Example: abc.com), he got the auto suggested link (Example) for https://www.abc.com/ [‘https’ link came to the top as; until that time, we were using https for our site.]

The first issue was > after this Http alteration, this was not intimated to Client > as to clear his browser’s memory cache. (Cntrl+F5) > Anyway, it was his request to do immediately.

Second issue was > If anyone types Http/Https, the "Http" redirection should have happened.


These kind of silly issues happen but will make a big party boom-off.
Please take care of your application.

Open Quality Testing

:: OQT ::


<< Open Quality Testing >>

.000 & .00

.000 & .00 ?
What makes difference !!!

We were communicating with the development team regarding this .000 & .00 matter since it was implemented.
Reader’s mind :: What is it all about, can you please explain ?

Information was >> In our application, in some areas, we have values with decimal points like ‘.0’, ‘.00’ and ‘.000’ [ Example > Rs.2,000.00/ 2,000.000/ 2,000.0]. Informed to the development team but as this was just a minor text fix, they did not consider for that particular phase. But when mail came from our client for that issue, the same issue was respected a lot. We informed our client that we had already recorded this as a concern in our ticketing system. This is not like informing to client/respecting these concerns and etc.; the main matter is on how we are communicating to development team to resolve these kinds of bugs/issues. If you ask me what the solution is for these, here it is;

Solution: If there is any code implementation for a text box/ drop-down/etc., inform the development team beforehand itself to use that functionality’s code ( for a text box/ drop-down/ browse button/ light box/ etc.) throughout the application and not for that particular object/ menu.

Hope you guys have a tension free testing hours.

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.

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 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.

Response Time, Throughput and Utilization

(a) Response Time
Response Time is the delay experienced when a request is made to the server and the server's response to the client is received. It is usually measured in units of time, such as seconds or milliseconds.

(b) Throughput
Throughput refers to the number of client requests processed within a certain unit of time. Typically, the unit of measurement is requests per second or pages per second. From a marketing perspective, throughput may also be measured in terms of visitors per day or page views per day.

(c) Utilization
Utilization refers to the usage level of different system resources, such as the server's CPU(s), memory, network bandwidth, and so forth. It is usually measured as a percentage of the maximum available level of the specific resource. Utilization versus user load for a Web server typically produces a curve.

Alpha, Beta & Gamma

Alpha Testing: Alpha Testing is mostly like performing usability testing which is done by the in-house developers who developed the software or testers. Sometimes this Alpha Testing is done by the client or an outsider with the presence of developer and tester. The version release after alpha testing is called Alpha Release.

Beta Testing: Beta Testing is done by limited number of end users before delivery, the change request would be fixed if the user gives feedback or reports defect. The version release after beta testing is called Beta Release.

Gamma Testing: Gamma Testing is done when the software is ready for release with specified requirements. This testing is done directly by skipping all the in-house testing activities.