Remote Testers

There is an aged-old saying like “Testers should be divided from Dev/BA team & they should work independently”.
The above statement is linked to the bizarre style of testing, as what is the role of testers and what testers should perform.
If you are cautious on the thought that your testing team must be isolated from other teams, then there is a better possibility that you and your team will achieve more testing; (since you are free from expressing your own test ideas without other’s suggestion/feeds).

ABCDE of a Software Test Engineer

“ABCDE” of a Good Tester’s Quality;

• You Agree to the work/attend official calls apart from your office timings/working days.
• You are always Brisk on explaining the defects on tracking system.
• You are Conscious of your application’s business view and testing life cycle.
• You are Delighted doing multi-application testing.
• You are Ecstatic of your role in your project.

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.

How to determine Flagpole’s height

A group of managers were given the assignment to measure the height of a flagpole. So they go out to the flagpole with ladders and tape measures, and they're falling off the ladders, dropping the tape measures - the whole thing is just a mess.

A Software Tester comes that way and sees what they(managers) are trying to do; walks over, pulls the flagpole out of the ground, lays it flat, measures it from end to end & gives the measurement to one of the managers and walks away.

After the tester's depart from that place, one manager turns to another and both starts laughing. "He prove that, he is just a software tester! We're looking for the height and he gives us the length! How illogically he understands our necessity".

Courtesy for the initial 2 paragraphs : Jokemasters | last paragraph I modified.

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.

On Running Crucial Test Data

Blank: See if suitable “error messages” are shown.
Example: ‘’ [i.e., empty.] To avoid this blank error message, we can also provide suggestion as to disable the Submit/any conditional Button. [Example: Login button can be in disabled state until some data is been provided in both Email ID & Password field.]

Valid: Valid input data is properly saved in database. [Data needs to be displayed as per the client requirements.]
Example: (i) For Name field, valid data is “Snacky” & not “159203”.
(ii) For Tax impound, valid data can be “-14,000”, if that is what the client request is.

Invalid: On providing the Negative values & alphanumeric string inputs, you can check for invalid test data. [It depends on that particular field.]
Example: (i) For Name field, invalid data is “159203” & not “Snacky”.
(ii) For Tax impound, invalid data can be “14,000”, if client requires for ‘-ve values’ alone.

Range: Data set which is out of range data. Identify application boundary cases and prepare data set that will cover lower as well as upper boundary conditions.
Example:
In an organization: Recruitment Rules are;
0–15 >> Don’t hire
16–17 >> Can hire on a part-time basis only
18–54 >> Can hire as full-time employees
55–99 >> Don't hire
- What about ages -3 and 101? , this is what range data is all about.

Bulky: This data set should be large in volume.
Example: 60 MB file

Illegal: Make one data set of illegal data format (one set might have symbols). System should not accept illegal data format. ‘Error messages’ should be generated according to the data.
Example: It depends on the file, which you prepare with regards to the data format.

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.

Bug Bugger Buggest

I got a title name, all of a sudden on reading my team mate’s status message on Facebook and thought of writing a blog related to it. Before writing a blog with regards to that title, I confirmed no blog had that title but a blog had. That too in the year 2006 itself, it was written.

Title which occurred in my mind: Bug Bugger Buggest. But I’m happy, that I saw the title in one of the famous testing blog and the content was also nice.

URL for that blog post: Bug Bugger Buggest

Courtesy: Pradeep Soundararajan

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.

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.

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.

Wanna be a Good Tester?

1) Programmers should not test their own code.

2) Go beyond requirement testing.

3) When Regression testing started, use the previous bug graph/Defect tracking tool.

4) Analyze code changes are done properly for testing purpose. If not don't accept the build.

5) Keep developers away from test environment but never hurt them.

6) Testers need to be right from software requirement and design phase.

7) Share your best testing practices/experience with your testing friends.

8) Think of positives and negatives while going into an application.[Technically and Non-technically]

9) Before testing, Learn to analyze the whats your plan.

10) Test cases needs to be available to developers prior to coding, so that they can't blame you.

11) Write clear, descriptive, unambiguous bug report.

12) Increase your conversation with developers so that you might get a new direction to test the application/modules.

13) Understand how programmers think and do the other way.

14) Ask them questions to client/developers/QA managers. It might be silly but don't hesitate. Some questions can be a turning point of your project/product.

15) Avoid keep all your communication in the mode of verbal.

16) Think like an end user. Listen to end user more and developers less.

17) Learn to say NO when quality is insufficient. Deliver with quality.

18) Increase the learning curve in automated test tool programming.

19) Know your application and domain.

20) Don't be diplomatic.