drozer is a comprehensive security audit and attack framework for Android.

With increasing pressure to support mobile working, the ingress of Android into the enterprise is gathering momentum. Have you considered the threat posed by the Android app that supports your business function, or Android devices being used as part of your BYOD strategy?

drozer helps to provide confidence that Android apps and devices being developed by, or deployed across, your organisation do not pose an unacceptable level of risk. By allowing you to interact with the Dalvik VM, other apps’ IPC endpoints and the underlying OS.

drozer provides tools to help you use and share public exploits for Android. For remote exploits, it can generate shellcode to help you to deploy the drozer Agent as a remote administrator tool, with maximum leverage on the device.

drozer helps to reduce the time taken for Android security assessments by automating the tedious and time-consuming.

drozer runs both in Android emulators and on real devices. It does not require USB debugging or other development features to be enabled; so you can perform assessments on devices in their production state to get better results.

drozer can be easily extended with additional modules to find, test and exploit other weaknesses; this, combined with scripting possibilities, helps you to automate regression testing for security issues.

drozer provides point-and-go implementations of many public Android exploits. You can use these to identify vulnerable devices in your organisation, and to understand the risk that these pose.

drozer enables you to search for security vulnerabilities in apps and devices by assuming the role of an app and interacting with the Dalvik VM, other apps’ IPC endpoints and the underlying OS.

drozer provides tools to help you use and share public Android exploits. It helps you to deploy a drozer agent by using weasel – MWR’s advanced exploitation payload.

For the latest Mercury updates, follow @mwrdrozer.

drozer allows you to use dynamic analysis during an Android security assessment. By assuming the role of an Android app you can:

drozer’s remote exploitation features provide a unified framework for sharing Android payloads and exploits. It helps to reduce the time needed for vulnerability assessments and mobile red-teaming exercises, and includes the outcome of some of MWR’s cutting-edge research into advanced Android payloads and exploits.

drozer does all of this over the network: it does not require ADB.

In this article we are going to learn about L10N (Localization)testing and how to do that.

What is localization? Localization is a term in software that refers to support any language, any location culture. We can easily understand by the meaning of supporting different language, but what is location culture. This location culture means, the culture format of any geographical location such as Date format, Time format, currency format, number format etc. This is a vital issue when we need to deploy a world-ready software. It is also known as L10N testing

Localization translates UI (may changes some initial settings) to make it suitable for another region. Localization Testing checks the quality of a product for a particular Location/culture. This test is based on the results of globalization testing(verifies the functional support for that particular culture/locale). Localization testing may be done with a localized version of a product. Localizability testing does not focused on testing localization quality.The test focuses on:
- Affected Areas by localization(UI/content)
- Culture/locale-specific, language-specific, and region-specific areas

But, these should be included in localization testing :
-Checking Basic functionality
-Deployment(spatially Setup /upgrade) tests under localized environment. For OS, we should select any language version of Windows/Linux as a platform for the test after installing the target language support or that language specific OS(like Japanese XP).

 Popular Scopes for localization testing :
-Check application resources and attributes
-Check linguistic accuracy (correctness)
-Check linguistic meaning (following culture)
-Check typographical errors.
-Check that documentations, online Help, messages, interface resources, and command-key sequences are consistent/sync with each other. If localized versions of the product exist , check the translation is consistent with previous release.
-Check dependency to system/input/display environment standards.
-Check usability of the UI.
-Check sensitive content(political/religious etc)
-Check your company identity is correct.(market-specific information about your company like contact information or local product-support phone etc).

Some known types of checking for application resources
Checking Content – Static & dynamic content such as product catalogs, search results, etc.
Checking Dates – Is the date January 1 or 1 January or 1st Jan.
Checking Characters/symbols – Different languages have different sets of characters.
Checking Postal codes – In some countries, postal codes contain letters.
Checking Phone numbers – Different formats for different markets.
Checking Direction – Some languages are written left to right, other languages are right to left.

I used to make checklist before doing . My sample localization testing checklist:

- Spelling Rules
- Sorting Rules
- Searching Rules
- Upper and Lower case conversions
- UI Sizes
- Printers
- Size of Papers
- Operating System
- Key boards
- Text Filters
- Hot keys
- Mouse
- Date formats
- Measurements and Rulers
- Currency format, value separator,currency symbol
- Country related codes(phone/postal/country/state name and code)


...I will try to include more testing scopes incrementally..

... Thanks...:) 

In this article, we are going to discuses about what is AdHoc testing and how to do it. 

Adhoc testing is a commonly used term for software testing performed without planning and documentation. This is an unplanned and informal testing .It used to perform with an aim to break the system. It does not follow any test strategy or any test cases or creates any test cases. In a restricted process driven test environment, ad hoc testing perform with random choosing area and testcases which may or may not be followed while performing.

A very highly knowledgeable person(on the system to test) usually the best candidate to perform Ad hoc testing. Generally Testers randomly test the application without any test cases or any business requirement document.

An important advantage of Adhoc testing is that it helps to save a lot of precious time. Sometimes it’s after spending valuable time on preparing and explaining tests that the program’s design is changed. With Adhoc testing precious time is not wasted on planning and documents.
 
Time for AdHoc testing in development process.  
- when the testers do not have enough time at hand to do a detailed testing with proper test plans and test cases.

-When system producing bugs rarely. Usually Adhoc testing perform for a certain time span(say - 2/4 hours occasionally). Ideally a when a senior SQA member is free for a small span of time, that time is the best for adhoc testing while the system is not producing significant bugs. Typically after getting / guessing a bug or a bug area, adhoc testing stopped and exploratory testing completes the full bug finding cycle(getting most of bugs from that area). 
- Sometimes Adhoc testing is carried out at the end of the project after the execution of all the test cases. So in that sense Adhoc testing is the kind of testing which acts as a complement to other types of testing.

The main Objectives of Adhoc testing are 
- To find defects by random approach.
- To guess the bug presence possibilities(“geuss” the most likely source of errors)
- To observer system beheaviour randomely 
- To get scenarios/tests out of defined scenarios.
- To get bugs out of test case areas

How to perform Ad hoc testing 
- Prepare without any documentation of the system
- Start from the basic activitiy to use the system(like installing, looking around, random clicks etc)
- Try to mix up multiple known scenarios (experienced previously)
- Try to think and use the system like as stupid user
- Try to think out of the box.(performing out of the box activities)
- Try to be relaxed and observe how the system performs
- Try to get the lacking of the system and perform to break the system
- Feel like you are playing games(like as a child) and you are aiming to break the system. 
- If a bug found, try to generate multiple time in the same way. (Hence, sometimes, it is very difficult to reproduce the defects as there are no test-steps or requirements mapped to it.) After doing that, try to generate in different ways.
- After getting a bug, try other tasks that relate to the bug more frequently. 



... Thanks....:)....

In this following article, we are going to see what is the life cycle of a bug. I will try explain a bug life cycle from initial stage to end with touching maximum process.

First, Just to inform, A software bug is an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways[wiki]. A bug is a specific concern about the quality of the Application under Test (AUT).
In software development testing time, when an issue which does not verify the requirements, it is reported as bug.(see my old post about how to report a bug). The life cycle of a bug refers to beginning to end of a software bug. Let describe as point.

1. When a bug is just found and posted(reported) for the first time, the state of the bug is called NEW.
2. When a New bug is available to team, the state of the bug is called Open.

..Thanks..:)...

In this article, we are going to learn some basic idea on exploratory testing.

What is exploratory testing and when should it be done?
It is a form of an unscripted testing that is used to explore the system's behavior. It has concurrent design and execution. Usually testers may be learning the software as they test it. It is one kind of search & find approach. Like exploring a system( that why it is called exploratory testing). People with good R&D skills, good finding capacity like detectives can be a good exploratory tester. 
It will be inappropriate to mix up with Exploratory testing and "Ad hoc" testing. "Ad hoc" testing refers to search for bugs by any person where an Exploratory testing refers to add intelligence, skills and techniques with "ad hoc" approach by a professional tester.

Typically Exploratory testing is effect when
-System’s behavior or specification is poorly defined
-A lot of scripted testing are left to complete.
-Crucial time is going on before release.



-Bug finding rates becomes less and team want some interesting bugs to come up.
-New SQA member is waiting to get in to the team

Exploratory Mindset while testing :
- Be Stupid and Simple : Believe it or not, to get more bugs on usibility issues, the more stupaid you behave , the more bug you can find. This stupid &simple means how simple & stupid way you think and measure the software.
- Take product Ownership : To get more bugs, you should be able to take responsibilities of the whole product. You should have the feelings that you are the product owner, you will justify how your product should behave that follows the requirement. Think big picture, take care of small things, perform like an end user.
- Compare with similar System : If you can compare functionality with a similar system , it would be more convenient to find more interesting issues.
- Try to Break the system: Keep the mind set that you have to play with the system like a game, like a goal to find the weak point, try to break the system logically/Illogically( sometimes you may need to be extreme to find tolerance)
- Smell & Note : The best way to do Exploratory testing is to keep note on every issue or dis similarities. Smell & note any problem that comes in font of you or in your mind(you sense it). Use this list later on while dong system testing or functional testing, This approach can find many serious issues. 

In a conclusion , I should say, this is from what I have experienced with. I will incrementally input my new ideas and thoughts. 
...Thanks....:) ....

In this article , we are going to see how to prepare a test plan document. It is from my personal experience and specific to my previous projects. It may differ from other domain of work. In here I will avoid time estimation and resource allocation.

Normally a test plan have to submit while starting of a project or may be beginning of a full test activity. Test planning is the preparing for the testing phase of product development to ensure that what is delivered to the client indeed satisfies the requirements as agreed following design specification documents. The test plan helps prepares those with a stake in the tests by setting stakeholder expectations and documenting the agreed upon testing approaches.Test plan should explain
-the product functions to be tested
-what specific tests will be performed
-the approach to be take for those tests
-what to test and what not to test
-how the tests will be performed
-who will be responsible for performing each test
-what results are expected
-what is considered a successful test and a failed test and
-the exit criteria for any series of tests as well as for the testing phase as a whole.

A well defined test plan must also describe, in explicit detail, the method, goals, approaches, etc to be used for each test.  A Test Plan should contain
a. Test strategy
b. Type of testing
c. Test Matrix (along with Test suit) for Both Manual and Automated testing.
d. Tools we are using
e. Time scheduling(Resource planning may be included)
f.  Requirements For Environment
g. Review and Audit
h. Reporting
i. Risks and Assumptions
j. Approvals for release
k. Closure Activity
I am providing basic understanding of those, I will try to provide a Test Plan document.

A. Test Strategy -This should explain Testing goals,Testing process(combine with development process), Explanation of The type of testing that is going to be performed, Define test scopes and avoidable, What are deliverable of testing team, Explanation for the logic behind every test case and scenarios, Test evaluation methods and mindset, Test Release plan and goals, Test Certification policy(if necessary for product launching), Explanation of Test tool choosing and their managements, Dependency policy and Resolution etc. This strategy actually the summary of full test plan & procedure. This will guide test team to move forward to work.

B. Type of Testing -This should contain the specific type of testing method that are necessary to follow for testing the product. (i.e.- Expiatory testing , we will use after system testing. We need to take care of the overall impact of some specific functionality implemented.) In here, detail areas and scopes are defined for specific test types.(i.e.- Load testing, We need to justify log in functionality running smoothly  for 5000 users where response time should be less than 2second).

C. Test Matrix or Suit- This is the collection of all test cases and scenarios , represented categorically. The test cases are shown in tree manner of user's prospective. Most of the time test suit is also called test matrix. A test suit will contain all area definition with micro level detail test case collection where as a test case will just contain one level upper than test suit(contain all area collection). Depend on project & understanding the definition is used vise verse. i.e.-
Log in Test Matrix, Log in -> Log In page ->(Log In process, Forget password), Forget Password -> Email sending >Reset password
Log in Test Suit, this will contain full test matrix along with the test cases that will be test under that area.
In here, Manual test areas, test cases are define as well as Automated test areas are.

D. Tools - This will describe various tools that we will use for testing, how we will use that(basic), test scopes , test cases, Tools reporting formats.etc.

E. Time scheduling- This basically testing activity scheduling following development process. it is fully depend of resource's skills and availability.

F. Requirements For Environment - This will describe the detail test environment requirements and End user environments. This is also tie with procurement process.

G. Review and Audit: This will define the Review and Audit activity policy, mindset , deliverable , goals , announcements etc.(i.e.- For testing process, some company may do Audit about activity of testing for reporting to Government Authority or Agencies)

H. Reporting - This will specify how testers will track the bugs or issues. This include tools, reporting process & protocols, assignments, way of reporting, notification policy etc. 

I. Risks and Assumptions- Identify the high-risk assumptions of the test plan. Specify contingency plans for each (for example, delay in delivery of test items might require increased night shift scheduling to meet the delivery date).

J. Approvals for release : Specify the names and titles of all persons who must approve this plan and release the product. Provide space for the signatures and dates. It is mandatory for release notes also.

In some working environment , there are also some little elements in the plan, I will try to include those incrementally.
... To be continued..

In the following article we are going learn a small area of
-what is Pre-QA(a kind of Dev Testing)?
-How to do Pre-QA?( a brief scenario description)
-What are the merits and demerits of pre-qa?
- Pre-QA , Why and when?

What is Pre QA?
Pre QA by word definition, some processes or tasks done before real QA. In another word, when we do testing beside developer before the code committed to main trunk , that is called pre-qa. After Pre-qa pass , the work will be ready to QA. We can say, it’s more like development sand box testing
The main goal is for pre-QA to get issue(ticket) ready for full QA .


Now, let’s go detail on How to do Pre –QA.

1. Pre -QA is always a On Developer’s call( developer’s demand). In many team it is must do, but better On Developer’s call as it will instantly find the bugs and developer need to have the mindset.

2.Pre -QA is always done before code committed to main trunk(not even local committee)

3.Pre -QA is always done on developer’s PC side by side(like pair programming, where QA will be the driver & the may be the developer himself)

4.On a Pre-QA, a SQA Role is like as Driver (Ref- pair programming).
The steps a tester should do.
  a.Read the full ticket before coming to developer’s environment
  b.Spatially read the comments & define the scopes
  c.Keep the major test areas/paths before coming
  d.Double check the ticket on satisfying the FRS/SRS before coming
  e.With the developer, first listen the full ticket/job about from developer
  f.Then discuses with reading the ticket & define the scope for testing
  g.Define the paths to test
  h.Do the tests with keep eyes open to find bugs & behavior of the product
  i.On fail, no argument, Just make a list of failed cases and give to developer
  j.Keep a list of possible fail areas for further necessary (from observation during Pre-QA) and if possible comment / discuses with QA team and have listed for checked items before release or integration.
  k.When developer will come up with solved list (provided in pre-qa), do the test paths again.
  l.Some case will verify, some cases won’t and some new faults will rise up.
  m.Now, Notify to QA Lead and project manager or product manager.
  n.In here, the scope will be specified. Some will go to known bug, some will move to next sprint or rescheduled and some will go to QA box.
  o.Now, QA will take a build, verify the solved & unsolved issues, and post the unsolved issues with the reference(build no) in the bug tracker as well as Agile board. 

5.On a Pre-QA, a Developer role is as Navigator
  a.Open the ticket read with the SQA
  b.He should discuses about scope & effect of the code that he has done.
  c.He might show the changes in the modules related to topic( detail understanding for code effects)
  d.He can show the design diagrams to SQA
  e.If , Frontend work involved, Mock-Ups should be shown to verify.

6.Time limit
  a.10 min default
  b.Best practice 5 min
  c.Maximum 15 min  on EPIC ticket

What are the merits & demerits of the process?
Merits:
1.Faster delivery tickets(quick builds & Rapid development)
2.Stop wasting time on reporting/reading/communicating with bugs(less posted bugs)
3.Discuses more on issues for better understanding among the team(developers or QA members)
4.There will be no unknown areas to anyone with More knowledge about business requirement
5.Team became more careful on product ( I have seen many developers showing bugs while doing pre QA)
6.Product become more stable before release and the risk factors become less.

Demerits:
1.Developer/QA members may react on the Pre-QA. A negotiation and professional attitude may resolve the issue( a senior may involve initially to clarify the necessity among the team)
2.It does not follow the traditional testing process.
3.Some issue may be easily miss-judge or overlooked or forgotten if notes are not carefully taken care of.
4.Senior QA members preferable for initial Pre-QA process, so hard for newly QA member to adopt the process and attitude.
5.Large number of team(200+) may face some difficulty to follow all the procedure if they are not properly grouped.

Pre-QA , Why & when?
Well, if you look at the above article, it’s very clear that pre-qa eliminates un necessary documentation, bug reporting, bug investigation time(both qa/developer). So, when we need a rapid development, when there is small release time, which will be perfect situation for Pre-QA practices. Pre-QA not only boosts up the development process, but also increases the interpersonal relationships among team. A team of 20-60 members , can easily follow the pre-qa process along with agile board. If the team is in large scale, they can also follow this by grouping them into small team(scope wise).

And, for following best practices of agile, pre-qa is unavoidable to ensure quality products.

In this article we will know how to write a good bug report.

What is bug report?
A report that describes the process to the futurity of the software in front of every member (basically the programmers) is called a bug report. You may show to the programmers in person or give them careful and detailed instructions on reproducing that. Simply, a bug report is the communicating way to prove that the software has a failure case.
What are the goals of a bug report?
-The fix should be faster so that the software becomes bug free
-The report should clearly describe the problem to the programmer so that the root cause can be identified specifically.
-It should enable programmers to see the program failing in front of them.
-A bug report may contain the following sections to describe itself. It is just a best practice.  There may be more or less sections depending on project.  

Bug No : The bug number of the tracking system
Link : It is the public/private link of the bug
Bug Title  : A title should describe the bug’s key point.(one line max)
Bug Summary : A summary should describe the full bug at a single line( Should not exceed one line)
State :  Any one of the bug states.( detail about those states in different post)  New/Open/Assign/Test/Verified/Deferred/Reopened/Duplicate/Rejected /Closed
Prerequisites: The pre installed items/requirements should be here.
-Name of operating system (if it has dependency on different OS)
-Name of software installed(if it has dependency on software, Ex- Dot Net framework)
-Name of browser (if it has dependency on browser.  Ex- Firefox, chrome, safari.)
-Name of proxy (it it has decencies on environment. Ex- NTLM, Authenticate Proxy etc)
-Hardware conditions & configurations (it it has dependency on different hardware)
Bug found version: The version no of the software in which the bug was founded
Bug fixing version: This is an optional tag describing which version will get the solve of the bug( following project’s release plan)
Severity: The bug’s priority should be here. These are some priority tags (from wiki). Those may be change due to project scope. You may add priority value in there.
Blocker – blocks development and/or testing work (you probably wouldn't know)
Critical – crashes, loss of data (internally, not, say, your edit preview)
Major – major loss of function
Minor – minor loss of function or other problem where easy workaround is present
Trivial – cosmetic problem like misspelled words or misaligned text
Enhancement – request for enhancement (feature requests)
Reproducing steps: These are steps to reproduce the bug. Every steps should be distinct. In here a good tester will provide the shortest path to reproduce the bug.
Actual Value : The facts that found following the steps
Expected value :The results that was expected following the steps. It will be perfect to link up the expected results with SRS/FRC documents.
Assign To : The responsible person who will take care of the bug.(initially, It may be assigned to team leads, they may distribute the responsibility)
Reported by : Bug reporter's name 
Comments :  Comments which are very much welcomed in a bug life cycle. Any member or the responsible person can comments on that. It can be use for describing current state of the bug in development lifecycle.
Attachments : Most of the bug trackers supports multimedia attachments. If necessary , you may attaché pictures, audio or even video. The best practice is to attaché picture(screen shots).
An example of the good bug report: Let's think an web application www.testWebApp.comhas a log in page. A tester have found a bug that an user named Shantonu, password: 123456 can’t log in using Firefox browser(3.6.15) under Windows XP with Authenticate proxy conditions. Now, how he will report.
(please check that bug is not listed before)
So,
Bug No: 1(mostly, the reporting bug tracker will provide the value, no need to insert)
Bug Link: mostly, the reporting bug tracker will provide the link which may public or private
Bug Title  : Failed to log In
Summary : User Shantonu(pass 123456) can’t login with Firefox 3.6.15 under Authenticate proxy on Windows XP Professional(5.1.2600 Service Pack 3 Build 2600).
State : New as Newly posted.
Prerequisites: Please make sure that the following environment is set
-Windows XP professional 5.1.2600 Service Pack 3 Build 2600
-Firefox 3.6.15 is installed (cache cleaned)
-Authenticate proxy is installed 
Bug found version: 0.0.5.125[we will detail explain about versioning best practices on another post]
Bug solving version: 0.0.6.150
Severity: Blocker [as it is un useable on that conditions] (it may be major if the release priority is not on proxy/browser) 17 [IV value following UTP method, describe in different post]
Reproducing steps: 1.While running pc at windows, run Firefox 3.6.15 from start menu.
2. After opening, write the address (www.testWebApp.com ) in the address bar &press enter
3.When login page appears, insert the user name as Shantonu and password as 123456
4.Wait & see that Failed to Login( or http bad request)
Actual Value: The login fail. ( or HTTP bad requested) [it is better to provide a screen shot and the error details here, if possible, include the firebug* error steps]
Expected value: User Shantonu should successfully login [you may add the specific FRS/SRS reference for better understanding]
Assign To : Mr. X( as team lead or sleeted reported person or responsible person)
Reported by : Shantonu Sarker
Comments: 
Attachments : Screenshot1 : Failed state[the attached screenshot]
*Firebug is an add on for Firefox that shows the step by step execution using page source.
Before report a bug , it would be nice if you take care of the following terms
Be specific: Be very much specific for the steps and all the sections.
Be descriptive:  Provide more detail information rather than less. But be careful as If you say too much, the developer can skip some and if you say too short they have to come back and ask more questions. Ex- At the starting of my career, I wrote some bugs with one line steps where I had to explain several time to the developer. Later on I had to provide more detail on the comment section. So, bottom line is , you have to be descriptive enough to make all understand about the problem and you have to avoid over description.
Be careful of pronouns & language: Be specific on component like don’t use words like "it", or references like "the window", when it's unclear what they mean. Ex –
I started sampleApp. It opens a warning window. I tried to close it and it crashed." It isn't clear what the user tried to close.
Did they try to close the warning window, or the whole of sampleApp? It makes a difference.
Instead, you could say "I started sampleApp, which put up a warning window with the title[ let’s say : warning]. I tried to close the warning window, and sampleApp crashed.
This is longer and more repetitive, but also clearer and less easy to misunderstand.
Revise: Read the report and see if you think it's clear. Try to reproduce the bug by following your own steps. Please check the spelling on the revision time.
Use multimedia :  In modern world , every one like multimedia in case of communication. Try to use at least screenshots to describe the error.
Thanks for your time that you pass reading the article….:)

This is shantonu's personal blog.Mail[shantonu_oxford@yahoo.com] to contact.