Unprotect an excel sheet without password... solved

If an excel sheet is marked as protected then you will not be able to modify many of the cells in the sheet and the sheet could be password protected as well. So, here is a trick which will help you to unprotect an excel sheet without entering password.

Step #1: Press ALT +  F11 or click on View Code in Developers Tabs

Step #2: From left panel at project panel double click on the sheet name which you want to unprotect

Step #3: In the White Space Enter the below Code. Do not change the code just copy paste:

Code:
Sub PasswordBreaker()
    'Breaks worksheet password protection.
    Dim i As Integer, j As Integer, k As Integer
    Dim l As Integer, m As Integer, n As Integer
    Dim i1 As Integer, i2 As Integer, i3 As Integer
    Dim i4 As Integer, i5 As Integer, i6 As Integer
    On Error Resume Next
    For i = 65 To 66: For j = 65 To 66: For k = 65 To 66
    For l = 65 To 66: For m = 65 To 66: For i1 = 65 To 66
    For i2 = 65 To 66: For i3 = 65 To 66: For i4 = 65 To 66
    For i5 = 65 To 66: For i6 = 65 To 66: For n = 32 To 126
    ActiveSheet.Unprotect Chr(i) & Chr(j) & Chr(k) & _
        Chr(l) & Chr(m) & Chr(i1) & Chr(i2) & Chr(i3) & _
        Chr(i4) & Chr(i5) & Chr(i6) & Chr(n)
    If ActiveSheet.ProtectContents = False Then
        MsgBox "One usable password is " & Chr(i) & Chr(j) & _
            Chr(k) & Chr(l) & Chr(m) & Chr(i1) & Chr(i2) & _
            Chr(i3) & Chr(i4) & Chr(i5) & Chr(i6) & Chr(n)
         Exit Sub
    End If
    Next: Next: Next: Next: Next: Next
    Next: Next: Next: Next: Next: Next
End Sub

Step #4 Now Click on the Run Button or press F5:

And pufff.. sheet is unprotected for you now. Also you would be getting a message in the pop up window.
This Message is contains the password which can be used to unprotect the other sheets in the same workbook.

Limiting network speed on a mobile device

Recently I caught up in a problem where I had to run an application on a mobile devices with limited speed. There catch here was the fact that the application was not available over internet so it was not possible to access it using GSM i.e. 2G or 3G data.

I had to access that application using Wi-fi network only. This was bit challenging as there is no any such app available in the app store and also to modify speed at router level required much of expertise.

Then I came across with this very simple solution.

Route all the traffic using a proxy server and limit the speed on proxy server. One can use his own system as a proxy server and there are lots of free tools available for the same few of them are Fiddler, burp suit, etc..

It is very easy to configure your own system as proxy server using above tool and once that is done you can you limit network speed on your system using free tools like netlimiter or net balancer.

Post that all you have to do it to put IP address of your system in the proxy server field of your device and all the traffic on the mobile device will now get limited to the speed which was set on your system.

The Bug Life Cycle

 Just like a real life bug a software bug is also born and later bloom to attain many stages before dying i.e. getting closed. These stages so generic that each defect or bug can fall under its stages.

A bug/defect is always managed by a bug tracking system and there are lots of bug tracking systems available nowadays, this includes JIRA, BugZilla, TFS , TeamTrack, etc. the list is very large of such bug tracking systems. The choice of a bug tracking system totally depends on the business and the features required.

Though there are very generic stages of a bug life cycle still each bug tracking system follows its own cycle for a defect. All of those stages can later be mapped to generic bug life cycle (Refer to Diagram). A typical bug life cycle is explained here for a basic understanding.

New:

Life of a bug start with very discovery of a bug i.e. with the point of time when it is identified but in a bug tracking system life is considered to be started at a point when bug is first logged in the system and that state is commonly referred as New. That simply means that the bug i very much new and no work is done on it.

At this point no one can be sure of the person who is going to fix the defect but the defect remained in the system and can be discussed during team meetings.

Assigned:

Once the defect is assigned to a developer its state is changed to assigned, it simply means that a developer is working on the defect and the resolution can be provided soon. But a defect being in a stage does not always guarantee that a fix will be provided because at this point developer is going to study the defect which can lead to any result even to the rejection of defect.

From Assigned state defect can achieve three different stages which are explained here respectively:

Researching:

Many of the time developer needs to do some research to know more of the defect or to explore additional stuff in order to understand the behavior of defect and hence the state of defect can be set to researching till developer is researching. Once the research is completed defect is sent back to assigned state and developer can start working on providing the fix or can take other actions.

Defer:

The defect can be deferred if it is scheduled for a later release or some other reasons. Thus the state Deferred. The defect can only enter to state "New" from here similar to reopen from closed state. Please note that though this state is very much equivalent to closed but it is not exactly closing the defect because at deferred state we do not have a resolution for the defect but at closed state we have a resolution of defect.

Test:

At this state the defect is assigned to a test team member once the resolution of defect is provided by developer. A defect from assigned state can be sent to a tester with many of the resolutions that includes providing a fix or rejection of bug. Here, tester has to carry out required tests to verify the fix provided by developer or he can provide extra information to developer in case of rejection and send it back to assigned state.

In case of the fix, if all the testing goes well and tester does not find any issues then he can close the defect and so is the state closed. If at any point tester found any issue he can send the defect back to developer in assigned state with reason as "retest failed" and here developer again has to work on the issue and can come up with a resolution as described in Assigned state.

Closed:

If the testing for the defect proves that the defect is fixed than the defect's state can be changed to closed which means the defect is now fixed. This state can be achieved from deferred state as well e.g. if a defect was uncovered at a time and was sent to deferred state after few releases that issue becomes irrelevant and hence can directly be closed.

Once a defect is closed it doesn’t mean it cannot be observed again in the software. Though it is very rare but if same defect is observed again then the defect at state closed can be reopened and sent to New state.

These are very generic states a Bug/Defect can have and these can further be divided into other states as per the implementation of a bug tracking system.

The Principles Of Testing

Every profession has some building block or principles and likewise any other profession testing too have some principle on which it relies. These define very basic yet roots of software testing and should be kept in mind while testing.

Software testing has seven basic principles and each of them have its own meaning /purpose. We can go in detail with each of the principle to understand its meaning.

Principle 1 – Testing cannot prove there are no defects
"testing shows that there are defects but it cannot prove there are no defects"

The basis of this principle is the fact that it there are always some scenarios /combinations left which are either not possible to test or are less important. Testing can always reduce the possibility of finding a failure of software in production but it cannot guarantee that the software is defect free.

Let’s take an example of some mail server like GMail or yahoo mail, no matter how thoroughly it was tested there will always be probability that it will not work properly on some newly developed browser. But after testing it is guaranteed that mail server will work on most of the web browsers.


Principle 2 – Exhaustive testing is impossible
"Exhaustive testing is not possible except of trivial cases."

Testing everything i.e. each and every possible combination of inputs and the precondition is not possible because there are constraints such as time limit or the cost of testing and in some cases testing each combination is not even practical.

For example if a user ID on a login page accept numbers and characters with a total max length to 15 then it would not be practical to test each and every combination of characters that are accepted for the user ID. That will consume much of time and will cost too much even if done by some automated program.


Principle 3 – Early testing
"Testing should start as early as possible in software development life cycle"

Once the development is started there remain many defects which costs more to fix then to fix them in requirement phase only or in other words if it is the responsibility of software testing to ensure the quality then imparting the quality process late would obviously cost something. As the development progresses costs to fix a defect increases because the area affected by the defect can be increased and/or the complexity of code is increased.

If a product has a feature which can never be used or wrongly represented in requirements document and testing is not started early i.e. with requirement phase itself then it would obviously convert to a faulty design and a lot a rework might need at later stage but if the testing process is implemented in the very beginning of software life cycle then the faulty design can be identified and the amount of rework can be reduced very much.


Principle 4 – Defect clustering
"A small number of modules usually contains most of the defects discovered during pre-release testing, or is responsible for most of the operational failures"

Usually it is observed that most of the defects that are identified for a software are from certain modules only and the testing should be focused on those modules only after observing the defect density.


Principle 5 – Pesticide paradox
"If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects."

We can understand this principle by the example of an agriculture farm where a farmer is using facing problems with some pests. Now one of his friend suggested his a pesticide, the farmer started using it and found that it removed the pests very significantly. He was so impressed that he used the same pesticide next year as well and then next many years. After few years he observed that his crop has developed pests and his old best friend the pesticide has no effect on the pests. He was very surprised and was not able to figure out the reason for the problem. any guesses why this happen?

Answer is simple, pests have developed immunity for the pesticide over the time.

Same thing happen with the software also, if same test is applied to the software repeatedly then the test would no longer uncover any new defects. Hence, to overcome this "pesticide paradox" it is advisable to always try to update and enhance your test cases. New and different test cases should be added to the test suit so that new defects can be uncovered.


Principle 6 – Testing is context dependent
"Testing is done differently in different contexts"

Same things are done differently for different contexts in our real life as well, like saying hello to your parents will have different tine than saying hello to your friend.

Similarly in software field testing is also done differently for software with different purposes. Like for a e-commerce website testing money transaction related tests is very crucial while for a satellite software most important thing is to make sure that satellite is able to communicate with ground station successfully


Principle 7 – Absence-of-errors fallacy
"Finding and fixing defects does not help if the system built is unusable"

Sometimes this happen that a software is built and validated with QA but still that remains unusable because it is unstable and does not fulfill the user requirements. So, it remains duty of a QA tester to always think from a user perspective and provide a feedback as if real production user would have been using the software.