Thursday, December 27, 2012

Learning GREP

GREP command is one of the most frequently used UNIX command stands for "Global Regular Expression Print” .GREP command in Unix operating system e.g. Linux, Solaris, BSD, Ubuntu or IBM AIX is used to search files with matching patterns, by using grep command in Unix you can search a file which contains a particular word or particular pattern.
 
Example 1
Finding relevant word and exclusion of irrelevant word is the most feature of grep command. Most of the time I look for Exception and Errors in log files and some time I know certain Exception I can ignore so I use grep -v option to exclude those Exceptions.
 
grep Exception logfile.txt | grep –v ERROR

This grep command example will search for word "Exception" in logfile.txt and print them but since we have piped out of first grep command to second grep command which will exclude all lines which match world "ERROR". To make this grep example more concrete let's see another example, here we have a file which contains three lines as shown below:
$ cat example.txt
UNIX operating system
UNIX and Linux operating system
Linux operating system

Now we want to search all lines in file example.txt which contains word UNIX but same time doesn't contain world Linux.
$ grep UNIX example.txt
UNIX operating system
UNIX and Linux operating system

Now to exclude all lines which contains Linux we will apply another grep command in this output with option -v to exclude matching word as shown in below grep command.
$ grep UNIX example.txt | grep -v Linux
UNIX operating system
Example 2

If you want to count of a particular word in log file you can use grep -c option to count the word. Below example of command will print how many times word "Error" has appeared in logfile.txt.
 
grep -c "Error" logfile.txt

If we apply this grep command on our example file to find how many lines contains word e.g. UNIX has occurred in the file :
$ grep -c UNIX example.txt
2
 
Example 3
 
Sometime we are not just interested on matching line but also on lines around matching lines particularly useful to see what happens before any Error or Exception. grep --context option allows us to print lines around matching pattern. Below example of grep command in UNIX will print 6 lines around matching line of word "successful" in logfile.txt
 
grep --context=6 successful logfile.txt
Show additional six lines after matching very useful to see what is around and to print whole message if it splits around multiple lines. You can also use command line option "C" instead of "--context" for example
 
grep -C 2 'hello'
Prints two lines of context around each matching line.
 
Example 4
 
egrep stands for extended grep and it is more powerful than grep command in Unix and allows more regular exception like you can use "|" option to search for either Error or Exception by executing just one command.
 
egrep 'Error|Exception' logfile.txt
 
Example 5
 
If you want to do case insensitive search than use -i option from grep command in UNIX. Grep -i will find occurrence of both Error, error and ERROR and quite useful to display any sort of Error from log file.
 
grep -i Error logfile
 
Example 6
 
Use grep -w command in UNIX if you find whole word instead of just pattern.
grep -w ERROR logfile
 Above grep command in UNIX searches only for instances of 'ERROR' that are entire words; it does not match `SysERROR'.
 For more control, use `\<' and `\>' to match the start and end of words. For example:
 grep 'ERROR>' *
 Searches only for words ending in 'ERROR', so it matches the word `SysERROR'.
 
Example 7
 
Another useful grep command line option is "grep -l" which display only the file names which matches the given pattern. Below command will only display file names which have ERROR?
 
grep -l ERROR *.log
grep -l 'main' *.java will list the names of all Java files in the current directory whose contents mention `main'.
 
Example 8
 
 If you want to see line number of matching lines you can use option "grep -n" below command will show on which lines Error has appeared.
grep -n ERROR log file.
 

Tuesday, December 25, 2012

Learning Agile

People often think the goal of testing should be to simply find all the bugs. Well, that’s not entirely realistic. Actually, it’s impossible.  Despite the title of “quality assurance” testers can never truly assure quality, nor can they be expected to find every bug. The real goal of testing should be to improve the software. This is a widely held view of testing in the Agile world. Agile is totally based on well known Agile Manifesto. Here is the summary of the fundamental principle of Agile Manifesto:

                                        Individuals and interactions over processes and tools
                             Working software over comprehensive documentation
                             Customer collaboration over contract negotiation
                             Responding to change over following a scheduled plan
 
In Agile functionality are released in smaller cycles, and work is performed in highly collaborative manner by self organizing teams that embrace and adapt changes to ensure that customers need are truely met. The Agile team adapt to the dynamic changing conditions by breaking a release into smaller short cycles of 1-6 weeks,each cycle is known as iteration or Sprint and is like a miniature software project. Agile methodology emphasizes real time communication preferably face to face. The most broadly acceptable techniques introduced by the agile process is to express product requirements in the form of user stories. Each user story has various fields including an actor, a goal or task they need to perform, an explanation of why it is needed and associated value and corresponding priority.
 
Let us define SCRUM, it is a project management methodology to facilitate agile software development and enable the creation of self organizing agile teams. A Scrum Master is like a traditional project manager in the sense in the sense that he/she oversees the centralization of team communication, requirement, schedules and projects. Unlike the traditional Project Manager ScrumMaster does not direct the team, because the Agile team is based on the philosophy of team member is commited to other team member and not the management authority.
Phases of Agile Project using SCRUM:
 
1. KickOff Meeting:  Everybody in the team  should review the product backlog (master list of requirements that the individual product owner has drafted in the form of user stories). The KickOff Meeting is more of an story writing workshop in which stories are selected and then decomposed into programmable task along with the time estimates for its completion.
 
2. SPRINT/Iteration Planning: Team collectively decides sprint goal and sprint backlog. The ScrumMaster role is to maintain the backlog list based on the team feedback and consensus and building personal commitment among the team members.
 
3. Scrum Meetings: The scrum meetings last usually less than 30 mins and the main objective of the meeting is to answer three questions: what have I accomplished since the last meeting,what am I working on and what are the future road blocks.
 
4. Final Acceptance Meeting: Presenting a demo to the customer/client what the team has accomplished.
 
5. Sprint Retero Meeting: Similar to the postmortem meeting of the traditional projects so that team gets together to what works well and what are the improvement area for the future projects.

Tuesday, December 18, 2012

Severity vs Priority


Severity

·         Severity refers to the Bug and how it affects the User’s interaction with the Application.

·         This is assigned by the Test Engineer

·         Severity is usually a static.

Types of Severity:

·         Critical-> (System Crash)

·         Major-> Impacts the main feature of the product

·         Medium-> Impact some feature of the product

·         Minor-> Minor mistake like spelling mistake

High Severity & Low Priority:  Suppose there is an application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. In this application, there is a fault while calculating yearly report. This is a high severity fault but low priority because this fault can be fixed in the next release as a change request.

Priority

1.      Priority refers with respect to the project and how urgent it is to solve the Bug in the context of the work been done.
2.      Priority should be dynamic, to be revised and updated as the project progresses.
3.      The Priority of a bug should be set and modified in agreement by the project stakeholders based on the strategic and tactical decisions of the project. In most cases, this is done during a regular (daily, weekly, etc) meeting where they review and evaluate the open bugs in the system.

Types of Priority:
·         High
·         Medium
·         Low

High Priority & High Severity: A show stopper error which occurs on the basic functionality of the application(Eg. A site maintaining the student details, on saving record if it, doesn't allow to save the record then this is high priority and high severity bug)
High priority and Low Severity

·         Example 1

Suppose in a banking application there is one module ATM Facility. In that ATM facility when ever we are depositing/withdrawing money it is not showing any conformation message but actually at the back end it is happening properly with out any mistake, hence it is missing of an error message. In this case as it is happening properly so there is nothing wrong with the application but as end user is not getting any conformation message so he/she will be confused. So we can consider this issue as HIGH Priority but LOW Severity defects

·         Example 2:

The spell mistakes that happens on the cover page or heading or title of an application. 
 
Low Priority and Low Severity:

·         Any cosmetic or spell issues which is in a paragraph or in the report (Not on cover page, heading, title)

Saturday, December 15, 2012

Show Stopper: Reporting a Bug

A good bug report is one that describes the problem well enough that anyone can understand and reproduce the bug, regardless of their individual knowledge of the product and without talking to the person who wrote it.”

1. A Descriptive Title
One that contains specific key words and terms to enable categorization.

not good: “Page does not load”
good: “ Contact us page - Server 500 Error when clicking on My Account”
2. Test Environment details

In which the problem was found – the specific system, device, or OS, and any relevant configuration options for the test environment. This identifies if the bug is environment specific.

• build # of the product under development
• type of hardware on which test was run, e.g. Samsung S3, Samsung Galaxy Tab,iPhone, iPad, Mac
• configuration of hardware, e.g. 8Gb iPhone 3G, 32Gb iPad 3G, 8GB 7 inch Samsung Galaxy Tab
• OS version / build # on that hardware
• any special conditions, e.g. on wifi, after low battery warning

3. Bug Type
Choose the correct Bug Type for the issue, for example whether it is functional, GUI or Technical. This will identify who the bug should be assigned to. Severity and Priority of the bug is also important.

4.Steps to replicate: These should start with the first thing you do like “1. point browser to www.domain.com”, include any relevant configuration steps, be atomic, be specific, end with the action that causes the problem to be visible.
Ensure all steps are clear and concise, for example:

1. Point Browser to www.domain.com
2. Click “My Account”
3. Enter email “test@test.com” into email textbox
4. Enter password “password” into password textbox
5. Click “Go”
While these steps may sometimes seem unnecessary, they are very valuable when you want to verify the bug and even more so when there is more than 1 tester testing the product. When a bug has been fixed it will be put back to the testing team to verify the fix and the only way to ensure the bug is fixed is by running the exact same steps as the original bug, without these steps you cannot guarantee the consistency of the tests run.

5. Expected Behavior
As per the requirement document/design document

6. Actual Behavior
Actual behavior observed by the tester.This allows the rest of the group to identify if this is actually a bug or if the product is working as designed.

7. The severity of the issue.
When this happens, how bad is it?

It’s important to be clear on your reasoning as to why you have given the severity you have, so that others can understand and support your decision. One note to remember, your job as a tester is to give the bug a severity level THIS IS NOT PRIORITY – it is the Stakeholders/Project Managers decision to give the bug a priority level which will take into consideration many things including the severity you have given.

8. The frequency of the issue.
How often does this occur? Always? Once?

The general nature of a problem is often not enough to characterize that problem. One also needs to know the frequency. Is a crash always a Critical bug? No, not if it was only seen once in 6 months of development. Is a pixel alignment issue always Minor? No. not when it appears at an obvious point in every launch. Frequency can make a big difference to the overall severity and therefore priority of a problem.

9. Evidence
Some of the evidence that you could supply is as follows:

• A user story this allows anyone reviewing your bug to identify what you are trying to do and also puts the bug into a scenario
• Screenshots
• Video/recorded screen share
• Log Files
• Browser matrix (if web based testing – a list of all browsers that are affected by the bug)
Although the above may seem like it requires a lot of time and work, an extra minute spent adding the above information to a bug report can stop the back and forth between development team and tester along with hours of engineering time, if it keeps someone from investigating the wrong thing, on the wrong device, without knowing that it only happens on the local network with yesterday’s build.

The details above also give management a clear picture of the issue, and enable them to make good decisions about the priority of bug fixes. It’s good to know that the bug that Marketing is freaking out about happened only once, on an old build, and on prototype hardware.

You’ll find that bugs that are clear, especially those that provide a test case in the form of a sample project, will get investigated and resolved more quickly. You will also build credibility as a tester and you will be taken more seriously in your role.

Wednesday, December 12, 2012

ADB "Android Debug Bridge"


ADB (Android Debug Bridge)

Android Debug Bridge (adb) is a tool that lets you manage the state of an emulator instance or Android phone. ADB is bundled with Android SDK package that can be downloaded from Android SDK download page. This tool is useful for communicating with Android phone such as install application, copy files from/to device and perform some linux shell commands.

How to Install

Download and install Java SDK (Ex: jdk-6u20-windows-i586.exe)

Download Android SDK package (Ex: android-sdk_r06-windows.zip)

Extract SDK package into anywhere on your drive (Ex: D:\android-sdk-windows)

Phone Setup

In order to use ADB, you have to enable USB Debugging option in phone settings (Settings->Applications->Development)
 
How to Use
Connect the phone to your pc/notebook usb port
Run Windows command line tool (cmd) and go to D:\android-sdk-windows\tool
New Android SDK puts adb executable file on \platform-tools directory instead of tool. So the path should be D:\android-sdk-windows\platform-tools.
 
Useful Commands
 
1. Check connected phone
Syntax: adb devices
 
2. Login to Android shell
Syntax: adb shell
If you get ‘#’ after typing adb shell, you are already get root access on the phone, no need to type su. Otherwise if you get ‘$’ , type ’su’ to get root access (only for rooted device).
 
3. Some useful shell commands
ls
List directory
Syntax: ls [path]
Example:
#ls /system/lib
cp
Copy file or directory
Syntax: cp [options] source dest
Note:
To copy or delete files in Android root directories you have to change the directory access mode to ‘read and write (rw)’ using command: remount rw
Example:
#remount rw
#cp /sdcard/libsec-ril.so /system/lib
#remount ro
mv
Move file or directory
Syntax: mv [options] source dest
Example:
#mv /system/lib/libsec-ril.so /sdcard/backup
 
chmod
Change file/directory permission
Syntax: chmod [-R] mode[,mode] …. file
Example:
#chmod 0644 /system/lib/libsec-ril.so
 
rm
Remove file or directory
Syntax: rm [options] file
Example:
#rm /system/lib/libsec-ril.so
 
 
4. Installing an application
 
 
You can use adb to install application from your local drive into phone.
 
Syntax: adb install appname.apk
 
 
5. Copy files from phone to local drive
 
Syntax: adb pull source [destination]
 
Example: D:\android-sdk-windows\tools\adb pull /sdcard/arm11-dvm.zip D:\
 
 
6. Copy files from local drive to phone
 
 
Syntax: adb push source [destination]
 
Example: D:\android-sdk-windows\tools\adb push D:\AnReboot.apk  /sdcard