Why I became a tester ?
What do you want to be when you grow up ?
When someone asked me that question, I always tell I wanted to be a software tester!
No, Absolutely not! In fact, even in university I wasn’t sure what I wanted to be. I had a subject in software quality assurance in my degree, which impressed me immensely at that time. But after that when I was looking for a job, I got an opportunity from a well reputed company in the Quality Assurance track, and I grabbed that opportunity without any hesitation.
Today I am happy about the decision I’ve made on that day. I’m having a career that I love and I make lots of wonderful memories, experiences from it.
Like many other in the industry, even though I became a tester because of the opportunity I was given, now I am a software quality assurance engineer because I feel passionately about Testing. It kept me challenging everyday!
Software Testing 101 – Test Case
A set of input values, execution preconditions, expected results and execution post conditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement
Above is the definition from official ISTQB glossary, but in a simple term test case is a set of conditions which a tester use to determine whether a system under test satisfies requirement. Test cases help to find problems in requirement or the design of the application.
Test case template
Test case template can be vary from different companies. However the basic items/section would remain same. Below are some of the basic items you may find in a test case document.
- Test Case ID: Identification number used to identify the test cases.
- BR Number: Business Requirement number, this will map with the corresponding requirement on the requirement / Spec document.
- Prerequisites: Any preconditions that must be fulfilled prior to executing the test.
- Test Steps: Step by step procedure to execute the test.
- Test Data: Relevant test data which needs to execute the test case.
- Expected Results: Expected result of the test case.
- Actual Results: Actual result of the test ( To be filled after the test )
- Test Status: Status of the test – Could be ‘Not started’ / ‘Pass’ / ‘Fail’ / ‘Blocked’
- Executed By: Name of the person who performed the test
- Test Environment: Environment which test was executed
- Remarks: Any special notes with regard to the test case / or the test execution
How to write a good test case
- Ensure all the positive / negative test scenarios.
- Write in simple language.
- Use the exact names in the Web forms / Web screens / Windows forms
Good characteristics of a good test case
- Accurate – On point, It says what it does
- Traceable – It maps with the requirement document, So when in doubt it can be traced back.
- Repeatable – Can be used to perform over and over
Access denied – Call ‘chmod’, May be ?
Have you ever experienced a message saying politely that you have no privileges to perform an action? I am pretty much sure that all of you may have that experience. Like for an example, suddenly your DB server stopped you have to restart the server to continue your work, but the remote user which you are using has not the right access which Oracle ( DB user ) has ( Yes, We had faced a related situation recently! )
Since we are dealing with servers & most servers are Linux based machines, we need to figure a way to handle permission related things on Linux. So then our speaker, ‘chmod’ comes to action.
There are few things you needed to know before you proceed,
- r – Read permission
- w – Write permission
- x – Execute permission
- + – Adding permission
- – – Revoking permission
So let’s say you want to give the permission to everyone to access this file, Here is the way to do ,
You can check the revised access permission by simply type,
ls -la <file_name>
In this case, It should be, ls -la test1
Likewise you can revoke access permission by following below command,
chmod u-rx <file_name>