IronWASP: Check to find broken authentication

In this section, we will discuss about how to check and find broken authentication using IronWASP. For demonstration purpose, we would make use of the demo application which is provided by IronWASP like we had used earlier for learning on how to finding CSRF Vulnerabilities.

Now when you login to the demo application, you would find a series of links which are accessible only if a users is logged into the app. i.e. this set of links are only accessible after valid authentication into the app. Sometimes you may have come across a case were this links may be accessible without valid authentication/login. The reason for this can be during development/coding phase there may have been a case where the programmer may have made a mistake in enforcing the authentication which make the link vulnerable. So here our main job would be to test and find out those link or url which are accessible without valid login.

In general, the links which are present in an application can be manually tested to make sure that they are not vulnerable or broken but doing so would sometimes be time consuming & hectic task at times if the application have a bunch of links. But when it comes to IronWASP, the tool perform this task smoothly by automating the process for testing and validate broken authentication.

To test broken authentication using IronWASP, from IronWASP tool invoke Interactive testing tools menu and select 'Test for Broken Authentication'. This would open up a window as shown below where it would ask to select all logs or customize & include specific logs in your test. In my case, i had selected the host name, All logs for logs and then click on the 'Find Suitable Candidate' button.

Note: Before moving on to test for broken link authentication, our first task that we need to perform is to browse through the demo application (all links/pages) once so that the logs will be automatically generated in log section of IronWASP tools which in turn will help us to perform the broken authentication test easily.

After selecting the desired parameters in the configure phase (for broken authentication), it re-direct to 'Select Candidate' phase where you would view all the log requests/responses that was captured by the tool when you had browsed the application manually. Now here we simply need to customize our settings by selecting/di-selecting the desired methods that we want to include in our test (i.e. if you wish to include only 'GET' method and exclude 'Post' method then select them) and then click on the 'Test selected candidate' button.

On clicking on 'Test selected candidate' button, the tool start testing i.e. it automatically visits each links/pages that we had included in our test and check for broken authentication. Here what IronWASP does is, it visit all the URLs that we have selected from the logs and compares the responses that is generated for the URL/Links when not logged into the app with the responses of the same Link/URL that was captured earlier when we manually visited/accessed  logging in to the app. Here it actually checks whether the response of the URL after logging out from the app is same as that off what was generated earlier. And if the responses of both valid & invalid request are same then the tool confirm that the URL/Link is vulnerable thereby highlighting the particular link in 'RED' and that the link is accessible without valid authentication.

You can find the broken links from the percentage of difference in response due to invalid Session ID. In my case as shown in the screenshot below, you can make out that the percentage of difference was "9" means even though i was logged out of the application the server gave a very similar response for the same URl (link) when logged in/out of the app which is incorrect and that the page can be accessed in the browser through the URL/link directly without logging into the app.

To view the valid/invalid responses, move to Invalid/Valid Session Request/Response tab and then click on the render link. This would show both valid & invalid responses which is quiet similar which thereby confirms that the specified URL is vulnerable and can be accessed by any anonymous users directly without valid authentication to the app.

To confirm once whether the URL/Link is vulnerable or not, you can directly access the infected URL in the browser without logging in to the app.

My Learning Material / Reference:

Site Address:

http://ironwasp.org/index.html

http://hack-tools.blackploit.com/2014/04/ironwasp-2014-one-of-worlds-best-web.html

http://securitybyte.org/resources/2011/presentations/ironwasp.pdf

Video Tutorial Link Reference:

Click Here

DOM based Cross Site Scripting using IronWASP

For finding DOM based cross site scripting vulnerabilities, we need to use IronWASP as proxy and then browse through the various section of the demo application using the browser based crawler technique as discussed earlier while learning on how to perform CSRF vulnerabilities. This would generally capture all the logs of the site pages in the Logs > Proxy Logs section of IronWASP tool.

Now to perform DOM based XSS test, expand the Tools menu for IronWASP and select DOM XSS Analyzer. It should invoke a window with title as 'DOM XSS Analyzer'. Here you would find a 'Start Analysis' button clicking which it will go through all the Responses in the Proxy log, extracts all the JavaScript from each Response and externally referenced script files. It would then identify all occurrences of DOM XSS Sources and Sinks. [Basically it does static analysis on all the logs captured in the proxy log section and generate a analysis report in form of a file. It will show the path of the analysis report in the DOM XSS analyzer window once the analysis is complete. See screenshot below.

The screenshot below shows the details analysis of the DOM XSS that it had performed. It basically use regular expression to find the most common DOM XSS Sources and Sinks. The Screenshot highlights all the issues (vulnerabilities) that the tool found for different URLs of the site and display them.

Now click on any specific link would shows all the JavaScript that it located in the specific page/url of the site. In most pages, the JavaScript are located at different section of the site say some JavaScript are inside script tags or may be they are in event handler or there are few which are loaded from external URLs etc. This tool through DOM XSS Analyzer actually loads all the JavaScript present in different pages of the site and then link together in a series and show them in one location. From the report, if we scroll down you would view all the JavaScript that the page uses.

You will find that the different sources and sinks which were identified by the tool are highlighted/marked in different BG font color. So from the report, you can also examine manually and see whether any of the identified sources/sinks lead to DOM XSS Vulnerabilities or not.

My Learning Material / Reference:

Site Address:

http://ironwasp.org/index.html

http://hack-tools.blackploit.com/2014/04/ironwasp-2014-one-of-worlds-best-web.html

http://securitybyte.org/resources/2011/presentations/ironwasp.pdf

Video Tutorial Link Reference:

Click Here

IronWASP Tool Usages: How to find CSRF Vulnerabilities?

In this section, we will learn about how to automatically find CSRF (Cross Site Request Forgery) vulnerabilities using IronWASP. To perform this we would use the DEMO APP as reference to test and demonstrate how this feature of the tool actually works. Basically through this demo app, it allow users to select a star to schedule a meeting by filling in the form which contains name and phone number.

Now after performing this sequence through lo-gin recording, in the Tool >> Log section you would find the corresponding logs that is being generated. Selecting any log item, you can view each request of form which is protected by a token. You can view the token by following this navigational steps - Tool > Log > Proxy Log > Select any log item > Request tab > Body.

Similarly this Demo App has a bunch of celebrity link which performs the same operations i.e. setting up a meeting. Selecting any link opens up a form which are protected by same CSRF of token. So our aim here would be to find out from any of this form is actually making a mistake in validating the CSRF of token or may be in other word to check whether it is possible to submit the form without a valid CSRF of token and still have the application to process it. We could actually test for it by individually accessing and submitting the form and capturing the request with a proxy and then manipulating the value of the CSRF of token. So this is a manual way of testing for CSRF using this DEMO App. But with IronWASP, what we can actually test by automating this series of steps.
 

Now to automate this process, you need to select Tool > Interactive testing tools > Test for CSRF Protection. This would open up CSRF tester Window. Here our first step would be to enter the value of the CSRF token that we have got from the log section. After entering the name of the CSRF token parameter, our next step would be to configure "how do you want to test the CSRF Protection". Basically what this setting will do is that it will replace the value of the actual token with a dummy value. Also we do have another option were we can actually remove the value of the CSRF of token and then perform the test. Since most of the form in the DEMO App is accessed after a log-in, so we have to perform a lo-gin sequence recording for a series of form and then we have to select a lo-gin recording here for perform the CSRF protection test properly. Next step would be to provide the scope for CSRF testing i.e. we need to select the host and then press the 'Find Suitable Candidates for Testing' button.

Now what the tool will do is it would go through the logs and then it identifies & display all the request which has a CSRF of token. From the list, you may select/di-select any request if you wish to exclude from your test and press 'Test Selected  Candidate' button.

 

So IronWASP is then start and test every single requests for CSRF and what it does is it send the request again but this time it replaces the value of actual token with the dummy value that we have selected previously. And once it send the request, it get a response which it then compares with the response of the original request which had a valid token and it shows the percentage of the difference between the response of the request with a valid token and response of the request with an invalid token.

We can view the significant difference of the responses in percentages in the Side by side section as shown in the screen-shot below.

 

To see how the invalid response looks, move to Invalid Token Requests/Responses section and then press 'Render' link under the Response tab. Screen-shot below shows the responses when the token is invalid.

Similarly you can view the response of the valid token from the 'Valid token request/response' section. So when the token is valid you can see from the screen-shot attached below that the meeting was setup and when the token was invalid the application rejected it (i.e. it fails to validate) and shows the application again which is a normal behavior.

 

But in two cases which are highlighted in read in the screen-shot below, the percentage of the differences is actually '2' which means the responses is largely similar and from the response section you can make out that in both cases it says that the meeting is set-up. So this two request which say that the meeting is scheduled are actually vulnerable to the CSRF off attack because even though we send a request with an invalid token the application is processing the request which means it is failing to valid the CSRF of token in this particular instance.

Therefore, there were 2 instances from the test where the CSRF vulnerability was found and the tool was able to detect it automatically using the CSRF test features.

Thanks,

Pinaki Mohapatra

IronWASP Tool Usages: Introduction

IronWASP stands for Iron web application advanced security testing platform. It is an open source tool used is developed for performing security testing on web application to find vulnerabilities. This tool in simple to use and good for beginner who want to learn more/deep on security testing.

Salient features:

• The tool is free, open source, GUI based, easy to use & no security expertise required for learning the tool usages.
• It help users to perform recording through Login sequence.
• It support report generation both in HTML and RTF formats.
• This tools checks and find over 25 different kinds of vulnerabilities, some are which listed below;

Through Active Scanning, the tools help to find defects related to;

SQL Injection
Cross-site Scripting
Command Injection
Header Injection
Code Injection
LDAP Injection
XPATH Injection
Local File Include
Open Redirect
Remote File Include

Through Parameter Manipulation Scanning, the tools help to find defects related to;

CSRF
Broken Access Control
Privilege Escalation
Hidden Parameter Guessing

Through Passive Scanning, the tools help to find defects related to;

Use of HTTP Basic Authentication
Cookies without Secure and HTTP-Only Flag
Cookies containing Sensitive Information
Insecurely Configured Cross Domain.xml file
Directory Listing Turned On
Potential Open Redirect Candidates
DOM XSS Sources and Sinks in the Page
Script, IFRAME and CSS Loaded from External Domains
Script, IFRAME and CSS Loaded over HTTP in an HTTPS & HTTP Page
HTML Form Contents Submitted to External Domains
HTML Form Contents From HTTPS Page Submitted to HTTP & HTTPS Page
HTML Form with Password Field Loaded Over HTTP
Password Sent in URL
Potential Session Fixation Candidates
Vulnerable Version of Web Server
Web Server Banner Grabbing
X-Header Analysis

• Support both False Positives & False Negatives detection.
• Extensible via plug-ins or modules in Python, Ruby, C# or VB.NET and bundled with a growing number of modules built by researchers in the security community like;

WiHawk (WiFi Router Vulnerability Scanner), XmlChor (Automatic XPATH Injection Exploitation

Tool), IronSAP (SAP Security Scanner), SSL Security Checker (Scanner to discover vulnerabilities
in SSL installations), OWASP Skanda (Automatic SSRF Exploitation Tool), CSRF PoC Generator
(Tool for automatically generating exploits for CSRF vulnerabilities).

Source & Downloads:

• IronWASP 2014 beta is available for download in this location - Click Here
• Once downloaded, Unzip the file/content to any of the local directory in your machine. (IronWASP DOES NOT require installation or administrative rights to work).
• After unzipping, browse and explore the contents extracted and look for IronWASP.exe to execute & get started.

Getting Started:

For learning IronWASP tool, you can make use of a demo application that is specially designed where you can test and understand the various features of the tool and the vulnerabilities that it finds. You can find the demo application inside the IronWASP folder that we have extracted with title as “DemoApp“.

Now for using this application - double-click on the demo app file where you can set the port number. After setting the port number click on the “Start Server” button to start the demo application on your browser by typing "localhost:port number" in the URL address.

This tool allow you to select different scan modes to perform the scan. Basically the two scan modes are default and user-configured settings which is used for effective crawling so that you can find more defects. Now we are all set to run and execute our first test.

Perform a vulnerability scans with IronWASP:

For performing a vulnerability scans with IronWASP, move to console tab and enter the application url address for scan.

After entering the URL address, press the start scan button and then the tool will start crawling the website. It will start finding vulnerabilities in the targeted site & once the vulnerabilities are detected, they will be listed in the tool classified as High, Medium and Low depending on the impact as shown in the screen-shot below.

There are multiple ways to perform the vulnerability scan and the easiest way to perform the scan is to type in the URL address and execute the scanning process. Even though, this is the easiest way but it does not give the best coverage. IronWASP does have a simpler method i.e. Browser based crawler which perform this task in a better way and at the same time give the best possible coverage. For performing this test, select Tool > Browser based crawler which actually helps to manually crawl the website (in-case if the website has authentication process to access some web pages). You can make use of the automated crawler that is built into IronWASP. Now in Browser based crawler window, click on 'Open Manual crawler' button.

What it does is that it actually opens up a Google chrome browser and it uses the browser to 
manually crawl through the website. Because it uses a real browser it helps to perform the task and output the best coverage of the target website but the problem with some other tools is that if the website has some complicated functionality or may be if it has a log-in page involved then it cannot automatically go through them really well. So at places like this, IronWASP helps you to manually crawl the website. To manually crawl the website click on the open manual crawler. This will open up another browser instance through which you can manually visit each and every pages including the pages which are accessed after valid authentication or have log-in sequence. The browser that opens up is configured automatically to use IronWASP as a proxy and if you are going through an SSL website then the tool will also automatically handle the SSL error internally. After browsing through the website manually, you can view all the logs that were captured in the log section of the IronWASP.

Now all that we have to do is to start a scan on the logs that are generated through browser based
crawler. You can do that by going to the site map. Right click on any log (host) under site map tree that you wish to scan and select scan branch.

This would invoke a wizard where you can move to the customization phase (Screen-shot attached below). Since some page of the website where accessible after performing the log-in, so to scan those sections we would make use of the login sequence recording (Note: Login sequence record can be performed here: Tool > Sequence Recording Tools > Record Login, CSRF token sequence. This section allow you to perform a log-in sequence recording which can be saved and used in various type of the tests that the tool perform). So here in the customization phase, select the log-in process from the field and then continue moving to next phase.

In Next Phase, click on the start scan button to begin the scanning process. While doing so, it would ask you to assist which request to scan but if you want to scan all the request that is available in the log then click 'No'. By clicking 'No' it would start scan process of all the request one after the other. While the scanning is in progress or after complete, you will find that the tool will identify and show all the vulnerabilities like SQL injection, Cross site scripting etc.

And because we selected the log-in recording, it will check and find whether you are logged into the site or not and if not then the tool will help in logging in to the site to scan the pages which are accessible after log-in. Also there is another way to perform scanning for the log that we have generated from the lo-gin sequence i.e. you can specifically scan a particular request. To do so, move to log section and right click on any request and select the option 'Select this for Automated scanning'. While performing such type of scan, you can also customize your test and include/exclude specific vulnerability check.

When the Scanning process is in progress or complete, you can view the list of vulnerabilities/defect
that are discovered and listed in IronWASP.

To view the defect, select a specific vulnerability. This would render all the details about the
vulnerability/defect on the right panel/section of IronWASP.

IronWASP also has a unique feature which would explain the exact reason why the vulnerabilities was found. So if you look and read the details of the vulnerabilities (Screen-shot attached above), then it would give you an idea & update about the problem that was detected by the tool.

Generate Test Report:
 
This tool also allow you to generate a test status report with all the vulnerabilities that the tool has
identified. For generating the report, select 'Generate Report' in IronWASP.

This section further allow you to customize and choose which vulnerability you want to include in your report. So you can select and include/exclude some vulnerability and then generate report either in HTML or RTF format.

Thanks,
Pinaki Mohapatra

XSSYA Tool Usage

XSSYA is a Cross Site Scripting Scanner/Confirmation tool which aims to find XSS

vulnerability written in Python. It allows a penetration tester to scan a website without using the browser and confirm whether the website is vulnerable to XSS - Cross site scripting vulnerability or not by injecting and executing around 28 encoded payload on the specified URL. Now in general when we scan a website it often gives false positive result/vulnerabilities and that may be because of other scanners scanning the website/execute payload at same time. Now if it return a status - 200 then the tool confirms the site is vulnerable and shows/report result but however the defect found may not be actually a defect in real and so in such case, the penetration tester has to test and confirm manually.

What is False Positive ?

False positive is something when you think a specific vulnerability exist in the code, it may be the result that many security scanner returns after test execution. False positive may occur because of weak static checks that security scanner detect. Sometime a security scanner for detecting a vulnerability it may use the algorithm to find one or more predefined signature pattern (i.e. CHECK LOGIC) within an HTTP response and that might go wrong due to which the scanner will deduce that and show the vulnerability exists (which actually doesn't exist in real) and then report it accordingly.

XSSYA - How it Works ?

Written in Python, XSSYA works by executing it library of encoded payload to bypass WAF

(WEB APPLICATION FIREWALLS). This is basically the METHOD 1 which confirm whether the site is vulnerable or not. If the HTTP response returns status - 200 then the tool attempts to execute METHOD 2 which actually then search for the payload decoded in the web page HTML code and if it confirmed then it gets to the last step and execute document.cookie to get the cookie.

XSSYA Features :

• Support both Windows & Linux ENV
• Support HTTP & HTTPS
• Identifies 3 types of WAF (mod_security, WebKnight & F5 BIG IP)
• XSSYA Continue Library of Encoded Payloads To Bypass WAF (Web Application Firewall) Support Saving The Web HTML Code Before Executing the Payload Viewing the Web HTML Code into the Screen or Terminal
• After Confirmation (execute payload to get cookies)\

Prerequisite:

The only module which need to be download and used is colorama-0.2.7 - https://pypi.python.org/pypi/colorama

OR

Try to directly install through Run prompt using easy_install colorama if python 2.5 or upper version is available/installed in your machine.

Download & Installation Procedure:

• You can download XSSYA HERE . Click on the Download ZIP button to download as shown in the screenshot below:

• Once the file is download, extract all the files to any local drive in your machine. See screenshot below.

Now we are all set to run and execute test using XSSYA.

Test Execution:

• For executing test, open run prompt and redirect to the directory where you have

extracted the ZIP files (Mostly look for the directory which contains xssya.py file). See

screenshot below.

• Now to initiate your test enter python xssya.py and hit enter.

• Enter a Vulnerable Website link and hit enter. (For Demonstration purpose, i am using the following website link which is vulnerable to XSS which i had found from the training video added below - " http://demo.testfire.net/search.aspx?txtsearch= " ).

Note: Make sure to choose a vulnerable link which ends with [ / or = or ? ]

• As mentioned above, in the next step we need to choice 1 or 2 i.e. we need to select Method 1 or Method 2.

Method 1 - It is used to check the link is vulnerable or not.

Method 2 - If Method 1 returns success i.e. if it confirms the link is vulnerable then it start executing the encoded payload (injecting at the end of specified URL) and search for the same payload in web HTML code to get the cookies information.

• At the end of the test execution, this tool also allow you to save the web page html

code and print them. See screenshot below.

My Learning Material / References:

Website Address:

http://www.secure-edf.com/xssya.html

https://github.com/yehia-mamdouh/XSSYA

Video Tutorial:

Happy Hunting !! :)

Web Application GUI Checklist

Testing user interface of web application is to ensure that the task within the application is user-friendly for all users and that the application meets specific standards of graphical user-interface. In short, this is the area of testing that complies with standards and conventions. The checklist mentioned below, may be helpful or beneficial for software tester & testing team to perform UI testing as it comprises of some GUI components that can be used as reference while testing/checking in an systematic way.

CONTENT

• Make sure all the page title or page header content are correct and that they are left aligned.
• Verify all the error message on the screen and make sure it doesn't have any spelling mistake.
• Check to ensure that the fonts applied to the content should be same or match to the requirement specification.
• Check whether the page content are intact when you navigate to another page and move back.
• Verify all the contents and labels are properly aligned.
• Check & rectify the spelling errors in the content.
• Verify all the text or content present for the fields are correct and matches to the required specification.
• Check that all the screen prompts specified matches the correct screen font as specified in the specification.
• Check all the content for respective words to be in lower and upper case.

NAVIGATION

• Verify all the links given in the sitemap prompt to actual page/section as specified in the requirement specification and check for broken links (If any).
• Ensure all the screens which are accessible via buttons are accessed properly.
• Make sure the scroll bar appear when the page/dialog content are long.
• When an error message occurs in a new window, make sure the focus should prompt to the button in the error message which can be used by the user to cancel/close it?
• Make sure there should be a link to navigate to home page on every single page.
• Any operation that invokes or opens a page/section in another browser tab should move the focus to the first editable field.
• Verify whether the tab order specified on the screen move in sequence from Top Left to bottom right. [Note: This should be the default behavior unless otherwise if any other behavior is specified in the requirement specification.]
• Check all the disabled & read-only fields are avoided in the TAB sequence.

IMAGES

• Check whether all the image graphics are properly aligned or not.
• Make sure the text wraps properly around pictures/graphics.
• Verify there are no broken images all over the website.
• Check the size for the graphics used or uploaded.
• Make sure the buttons are all of similar size, shape and are off same font & font size.
• Check all the banners i.e. banner style, size & display exact same as existing window.
• Is it visually consistent even without graphics.

COLORS

• Check the color of the link & hyperlink are standard or not.
• Test the background color of all pages in the site.
• Does all the buttons available in the site are off standard format, color and size.
• Verify that the screen and field colors are being adjusted correctly for non-editable mode.
• Verify the color of the warning message should be appropriate as per specs.
• Make sure that any section/pages background (colors) is distraction free.

INSTRUCTIONS

• Make sure all the error message & tool tip text that display in the site doesn't have any spelling errors & are shown correctly on the screen.
• Verify all the content/text that is shown as tool tip for every enabled field & button match with the requirement specification.
• Check the progress messages on load of tabbed/active screen.

OTHER ITEMS RELATED TO USABILITY

• Verify whether the site is accessible and looks good in different screen resolutions - 640 x 480, 600 x 800, 1366 x 768 etc.
• Make sure the site have a consistent, clearly recognizable Look & Feel.
• Verify whether all the pages are printed legibly without cutting off text.
• Verify all the terminology used in the site are clearly understandable by all site users.
• Make sure the names specified in button & option box are not abbreviations unless if required/specified in specs.
• Assure that the fonts used in the site are not too large or small to read.
• Does the site convey a clear sense and meaningful info to its intended audience.
• Check whether the site provide or facilitate customer service (info, details etc) i.e. responsive, helpful, accurate for all site users.
• Check/verify the site accessibility in all supported devices and that it meets all the standard and convention there.  

Happy Testing !! :)

Things to keep in mind when limited time is available for test cycle

In your life and field of software testing, you must have come across situation where you may have been asked to test an application in a very short span/period of time and deliver a report with a few or XX days. If you have not faced the situation then either you are lucky or you may not have worked on sufficient projects. A proper skilled testing requires lots of planning, effort to work/test the product with a substantial amount of time. In case if the project get's delayed then ultimately the testing phase gets a hit thereby decreasing the time span of testing cycle.
Now in order to deal with such limited time frame which is allowed/given for testing, you should make the best use of the time and resource available. Begin testing with an assumption that "Test all important features/items by prioritizing them (high to low) within the allowed time frame". From an economic stand point of view, it is always advisable to spend less time on the area of the application where the chances of finding defects/bugs is low. As a rule of thumb always prioritize the items i.e. what items/features to test first and in which sequence so that you spend limited time working/testing on areas that really doesn't matter or are low priority. Now for performing such task, you need to require doing some analysis, develop strategy & intuition based on your experience. Make sure, performing a risk analysis on items/features will help you to identify the areas or function where risk involved is high and that would be used most by the customers/end users.


Now while testing, it is always best suited to use a checklist which would help you to identify the key areas. Here is a checklist that I often use when I get limited time for testing an application:

• Check the functionality that most frequently be used by End Users. Ask yourself, “Which functionality is most visible to the End users”.
• Try interacting with all project stakeholder (mostly client, if possible end users) and gather info from them as well which they think are most important to them and include them in your list of test item.
• Test the functionality which act as a interface with an external systems i.e. third party software. These are often classic areas where you can find integration level defects.
• Check the most complex functionality which you expect can be easy misunderstood and misinterpreted. Look for parts of the code that are most complex, and thus most prone to errors.
• Don't forget that the newly added functionality are often least unit tested. Make sure to include them in your test items list.
• Identify related functionality of similar projects that you may have worked on in past and that caused problems mostly in terms of the defect's raised by customers. So try to co-relate them with current project if possible and try to use it to your advantage.
• Identify related functionality of similar previous projects that you may have worked on in past that had large maintenance expenses. Correlate the cases/scenario of the project with the current application and try to use it to your advantage.
• Test the functionality where recent modification where done to code or may be the areas which includes bug fixes.
• Check the functionality which are part of the requirement and design that are unclear or poorly thought out.
• Make sure to gather info on the areas/section where development was done in a rush or panic mode or under extreme time pressure. Include those areas in your test item list.
• Test the section/areas that demand a consistent level of performance and reflect complex business logic.
• Test the most risky area of the application with the largest safety impact which if broken can bring down the entire application. Talk with developers if possible and gather info or take suggestion on the same is probably a good idea here.
• Check the part of the application where many programmers/developers have worked on.
• Check the functionality which are part of new tools, architecture or may be where new technology are involved.
• Test the area of the application where the largest financial impact lies on the end users and project stakeholders.
• Device tests that could cover multiple functionality/features at same time & high-risk-coverage at the minimum time.
• Try to find & test the functionality which in case if it returns incorrect output then it could result in bad publicity.
• Try to find & test the functionality which could cause most customer support complaints.

Note: This may not be a complete list to check/test under a tight schedule though it covers quite a lot of important areas that usually needs attention. Now being a software tester, I am always aware of the fact that using a checklist will allow you to think & perform testing in an more effective manner within a jam-packed schedule.

Happy Testing :)

Software Tester/Quality Assurance Engineer - Can we call them Quality Cops !! :)

Some peoples perception in this software industry that i have interacted seem like Software tester/Quality Assurance Engineer are Quality COP of the products/projects that they seems to be working/testing with.

What do i mean by a Quality COP ?
The answer and reason that i found from few people were little weird where i came to know that Software tester or QA ask too many questions. Few are listed below;

• Are the requirements in place for the product/project ?
• Have we developed the test plan, test procedure that we need to use ?
• Is the test specification metrics and other related documents like SRS, Design Docs, Uses Cases in place ?
• Did we derive the testcase for every modules of the application based on the specs that we received ?
• Did the programmer/developers performed unit tests before sending the build to quality department ?
• Are we suppose to perform testing when the build has been promoted to production few days/hours ago without quality department approval ?

This list goes on…

So i guess these are like the responsibility of every/each software tester/quality assurance engineer to check or validate and assure the software product quality that is been released. So i call them as Quality COP who are responsible to approve and direct whether the product is ready to be delivered/released to the market or may be whether the product is suitable for users to use it or not.
Software tester/Quality assurance engineer (Quality COPS) are responsible to increase the value and life of the product quality being delivered or used by users all over the world as any problem in the product may lead to or affect the lives of people using it. 
Now let come to what we mean by Quality ?

Wikipedia describes quality assurance as follows

Quality Assurance is the activity of providing evidence needed to establish confidence among all concerned, that the quality-related activities are being performed effectively. All those planned or systematic actions necessary to provide adequate confidence that a product or service will satisfy given requirements for quality. Quality Assurance is a part and consistent pair of quality management proving fact-based external confidence to customers and other stakeholders that product meets needs, expectations, and other requirements. QA (quality assurance) assures the existence and effectiveness of procedures that attempt to make sure – in advance – that the expected levels of quality will be reached.

Read more on Quality Assurance from wikipedia

So are we (Software tester/Quality Assurance Engineer) responsible for the Product Quality ?

The Software tester/Quality Assurance Engineer test the product and report bugs. Some of these bugs get fixed for the release and few may not be based on many factors like time limitation/project schedule, improper specification etc. Assuring the quality into Products under development is the responsibility of all the members of the quality department team working on the project but sometime/in some case due to some external/internal factor the product is released with known bugs to the market after communicating the problem/risk/issues to project client which they in turn have to decide or plan to make fixes soon for next release cycle or may be as 'Hot fix'/'Patch' for current release version.

The role of the Software tester/Quality Assurance Engineer is to test software, find bugs, report them so that they can be fixed. The Bug Reports should be clear, easy to reproduce, reduce the time to debug for developers and the report should motivate the developers to fix the issue asap. Software tester/QA should focuses on the software product itself and gathers important information regarding what it does and doesn’t do. The process of gathering should include all the teams associated with the product. Talks to all project stakeholder be it Project client, Project manager, Test manager, Sales/Suppost guys, Development team and gather their expectations over the release.

Finally at the end, i would say that the Role of the Tester is to provide qualitative information on the product to the all project stakeholders for the better decisions. So the big challenge here is to provide accurate, comprehensive, and timely information about the product under development.

Context Driven Information About Bug Report

Dear Blog Reader,

Greeting,

In this post, i would like to explain & explore different stages or cycle of a Bug from it’s inception to closer. The Bug has been found and logged into the BTS (Bug Tracking System) and this is not just the end. Beside this, the bugs has to go through many stages till it die. It is always good to capture the context driven information in the bug report. My experiences with bug reports way back in my initial day's of my career had taught many lessons to improve upon.  
Bug reports is generally used to capture information about what is the problem with the system failure or when a defect exist in a system but mostly people spend very less time in capturing all the details required and there are many reasons for the same.
In general in our day today life, there may be some reasons/excuse what people may quote here;

• The System functionality and it's features are too complex and tough for novice user to understand the bug or it's reports.
• I can reproduce it on my machine if developer need it.  
• We get very less time to test. So we need to test more and give less time to capture & write more information in the Bug Reports.
• You know capturing all the info is process driven & it may not be worth of efforts or may be some times it is a boring stuff to collate the info & push it. :)

And the list goes on...
I hope you may have come across this situation at least once in your career but here the mission of your bug report is to provide details & context of the problem and convey the importance of it with a user driven stories. On another note, comprehensive report with accurate data always help the programmer/developer to locate or reproduce the error/bug inorder to make a fix. In short, your bug report must be like the voice of customer who play the role of an advocate against the problem.
Please make a note that the Bug Advocacy from Cem Kaner is an excellent and good source to begin with. If your report is unable to specify the need of the (bug) context, then it’s better to avoid writing such reports. Also in some case, it may not be feasible for other users using the system to explore & analyze the bug in that fashion. Another context associated with Bug Reports in relation with each stake holders of the project is that the Bug Tracking System must give the right trends and identify the hot spots. Testers must capture the right kind of data to derive better valuable metrics over the bug repository.
You should take some care about few parameters while capturing a bug/failure/error/defect/... which are listed below;

• The test environment should be a replica of the production environment and so while reporting a bug make sure to add all the Test Environment details.
• Add clarity about the Severity & Priority of the bug.
• Add detailed classification on the feature and also make sure to classify the maximum possible sub-feature/component of the system i.e. in short we can say the detailed steps where the bug was found (STEP TO REPRODUCE).
• Add info about the Bug types (i.e. Functional, Performance, Usability, Security etc).
• Versions and Build Numbers also play an important role in bug report which in turn help the programmer to deploy the build and reproduce the issue. Also there should be a build/version number added by the programmer which in turn help's the testing department to retest once the fix is available.
• Bug Classification would be useful incase if the bugs lies in Requirements or Design or Implementation work etc. (Optional).

Now a bug once pushed into the BTS may go through various stages (simple case is explained below) like;
When a bug/failure/error/defect is found it is always advisable to log that into the Bug Tracking System. At an initial stage, it will be treated as NEW Bug in the System and then would be ASSIGNED to the concerned developer/programmer for Resolution, once the test manager review it. The developer then INVESTIGATE and look in to the possibilities of the resolution & takes a call on Resolution for making a FIX or DEFFER the ticket over the information provided and ASSIGN the ticket back to Reporter/Tester. Tester would then validate (retest) the resolved issue in the build & check for the regression scenarios over the fix and finally if the bug/failure/error/defect is resolved it goes into the CLOSED state and then to archive or else the ticket is RE-OPENED/RE-ASSIGNED back to developer if the bug still exist in the system. Note this cycle continues till the defect move's into the Closed state. Finally check back & push the entire context driven information to the bug repository to identify the trends and risk associated with the release cycle incase if the same bug come back in any future release cycle.
I hope the above info may help a tester/QA who is new in pursuing a career in software testing. This article may help in identifying the trends in bugs and there cycle's to focus on the unstable components / environments.

Happy testing :)