How to capture an Android chrome console log?

Today I am going to tell you about how to capture android chrome console log.

Chrome DevTools allows users to capture a console log using a Chrome browser on an Android device, while connected to a computer, using this technique you can debug a website of android chrome.

Requirement :

1.Chrome 32+  on your Mac/Windows machine

2. A USB cable for Android phone to connect to Mac/Windows machine

On Android:

1.OS Android 4.0 +

2. Chrome Browser On Android

3.Enable USB debugging by going to Android Developer option(Enabling this will allow you collect a mobile device log and web console log from the device)

 How To enable USB Debugging?

1.Go to  an Android Setting>>System>>Developer option>>Enable USB Debugging

Those who don’t see developer option please follow this first:

1.Go to Settings > About Phone > >Tap on "Build number" 7 times (you will be notified that the developer options are enabled.)

Now let see how to capture log

1.Open the Chrome browser on your dev machine (Mac/Windows)

2.Open the Chrome browser on your Mobile device as well

3.Connect android phone to dev machine using USB cable

4.a Click on 3 dots menu on the top right corner of the chrome window on your  dev machine

4.b. Click on More tools>>Developer tool

4.c Click on 3 dots menu on  devTool windows , click on Remote devices , new tab get open (Here you can see your connected mobile devices) Note: Discover USB device enabled

  

5.Select the device which is connected on your dev machine

6.You can launch the Website on your mobile chrome browser by either of  this following ways

    6.a.Enter the URL into text box  which shows on the Computer browser, and click on Open

   6.b Or else Enter the URL link in the mobile device web browser’s address bar

   7.Once the website does get open you can observe the inspect button on your computer browser

   8.Click on that inspect button

There you can see the console log J

Screencast - MP4 format Free tool

Today I am going to talk about Screencast O'Matic , one of the Screencast tool.

Before the Screencast O'Matic , I used to use Jing and I was happy using that tool , but On one day I got the mail and request from the client that they want the videos in MP4 format and Jing gives the output file in SWF format and I am not at all intrested to do converison of the videos from SWF to MP4 .

So, I am looking for the tool which should be free and gives me o/p in mp4 format, and Screencast O'Matics solved my problem.Yes, you have read right Screencast O'Matics is free tool,thus they have paid verison too.But as far as now, free tool of Screencast O'Matics solved my all problem.

Access the link is here:
   https://screencast-o-matic.com/screen_recorder

The Key feature of this tool is:
1.No need to install the software
2.It is Free
3.It's gives the output in MP4 format which save more space on your disc
4.It has Record voice over, webcam, pc screen
5.It can be use both MAC as well as windows too.

Every coins has two sides thus,Screencast O'Matics has
It has working limitation , Without internet access you can't able to do recording,

There are limits of free version, it does not allow to recod the video more than 15 minutes those who want to record longer.

But Still I can feel this tool is very easy to use , give it a try.

POC and POO

Point of Control (POC): Point of control is the point at which test objects are supplied with test data.

Point of Observation (POO): Point of observation is the point at which test objects are logged and investigated.

In Black box testing the Point of observation is outside the test object, and Point of control is also situated at outside the test object. Here test object it can be your module/component, System .In Black box testing as you know you can’t see internal behaviour of the test object. So that why the POC and POO situated outside the test object. In black box testing the Point of control are appropriate test input data, appropriate test precondition. The Point of Observation is output, result.

In white box testing the Point of observation and Point of control is situated inside the test object. Here Test object can be source code, design, and requirements. In white box testing as you know that you can see internal working of code. Here internal processing of test object as well as output is analysed that’s nothing but Point of observation .and Point of control is also located inside the test object .The POO and POC is one of the white box testing technique.

Difference between Top-Down Testing and Bottom-UP Testing

NO	Top- Down Testing	Bottom-UP Testing
1	Top-Down testing conducted from main-module to sub module.	Bottom-Up testing conducted from sub module to main module.
2	If sub module is not developed a temporary program called Stub is used for simulate the submodule.	If main module is not developed a temporary program called Driver is used to simulate the main module.
3	Top -Down testing good if major flaws occur toward the top of the program.	Bottom-Up Testing good if major flaws occur toward the bottom of the program.
4	In this test condition difficult to create.	In this test condition easy to create.
5	Observation of test output is more difficult.	Observation of test output is easier.

Top Down & Bottom UP Testing

Top-Down Testing:

Top –Down Testing take place from Top to bottom In this testing Stubs used. “Stub” it’s special purpose software component . If sub module is not developed a temporary program called that is Stub. A stub is called from software component to be tested.

During Testing X  call the Stub A or Stub B.

1.       X calls Stub A  , If error occurs then will come to know that problem is in A or problem in interface between Component X and Stub A

2.       X calls Stub B  , If error occurs then will come to know that problem is in B or problem in interface between Component X and Stub B

Important Note: Remember that here we are testing the component X using Stubs A and B. Stubs are used to simulate the activity of the components that are not currently tested.

Bottom-Up Testing:

 Bottom-Up Testing take place from Bottom to Top.  If main module is not developed  a temporary program used  that is Driver. “Driver” its Software component which calls a component to be tested.

During testing Driver X calls Component A or Component B

1.       Driver X calls component  A, If error occurs then will come to know that problem is in  Driver X or problem in interface between  X and component  A

2.       Driver X calls component  B, If error occurs then will come to know that problem is in  Driver X or problem in interface between  X and component  B

Important Note:

Remember that here we are testing component B and C using Driver X

Example:

Cab Service :  Unit Testing of “Customer order Decline” Program , Here a driver will have code which will create customer order records using hardcoded data and then calls Customer order decline program. Program customer order decline uses another unit which Check how many customer raise the request for cab on same time, check that cab is available or not some complex thing. For checking and calculation call to this unit will be replaced by Stub.

What is root cause analysis?(RCA)

Testing is activity to find defect, prevent defect and gain the confidence of the software but when we detect the defect, failures we need to find out real reason why that happened? what‘s the root cause of that failure? for that we need to analysis the root cause. When we say the root cause that mean when you fix it, when it get resolved and prevent the recurrence of the problem.


Root cause Analysis is the a systematic way to know actual root cause of our problem. There are server ways to analysis the root cause and different techniques too .Every organizations has different techniques and different method to do root cause activity.Understanding the root cause of defect is an important aspect.Many time (RCA) done once event has occurred. But we may make it useful as pro-active method.

Example of Dish washer:
“Machine is 1 week old (Serial no: 123456) After few minutes of loading utensils I see the foam outside the dishwasher”
Now what will be next? The technician check the dish washer operation to test procedure.Technicians determines the cause or investigate why that happened.
Some of the obvious causes technician discover might be:

Liquid dishwashing soap used instead of automatic dishwasher detergent.

Too much automatic dishwasher detergent.

Examine the drain hose to make sure it isn’t kinked.

There are several tool used for the root cause analysis:

Brainstorming:
It's a process where people get together to examine the problem, where the group quickly generate many ideas for the particular problem.
It's a very useful technique because it uses collective brainpower to generate many ideas in a short period of time.

Fishbone diagram:
It is also known as cause –effect diagram, it's a technique to graphically identify and organize many possible causes of a problem
It's help to identify the most likely root cause of the problem.This tool can help focus problem solving and reduce subjective decision making

As tester , we want not to just detect the defect and report it but we need to think about any potential causes of failures.

Tips for Bug Investigation

1       Analysis the software bug cause:

Find the real cause of the software bug;  that cause can be software design, code implementation, tester fault etc.

2       Investigate any other similar types of the bug:

Sometime it’s happen that the symptoms are different but cause is same. Or that bug may be find out the different area of the software system.

3       Check the symptoms of the bugs:

What are the symptoms of the stated bug that need to be check.

4       Reproduce the same bug:

Try to reproduce same bug with same environment which is stated on the bug report.

5       Check  the possible side effect:

Sometime some bug responsible to indicate possible side effects. These could be file corruptions, device failure etc.

6       Communicate with Team members:

Communication is very important. Communicate with them who are familiar of the system. They may be able to provide you some useful information and tips. Even they can provide you possible side effect.

7       Create new test and new data for the bug:

Creating new data, editing test script is useful to check the bug.

8       Report the bug:

       It is very important if you are doing bug investigation reporting the each test important because it can be useful and helpful too.

Software Testing Estimation

Estimation is important factor which associate with each project .The same thing associate to the testing task, testing team that how much time do they required to do testing activity.

Estimation should not be wrong or not to be irrelevant. Test Estimation should be realistic.

In testing there are number of activity need to do like requirement analysis, test planning, test case writing, test case executions, regression testing and all.

To define the test estimation tester has to understand the requirement clearly when project requirement take place.
Need to allocate the task properly. Task should be divide in such way that everyone occupy with proper task and that lead to complete the testing activity in allocated time here you need to understand  Members skill ,expertise which help to estimate the how much time requires to writing, executing test cases etc. See every test team member has their own speed like someone is faster than other to do testing activity.

 (Resources Availability like members presence)To do test Estimation should consider team member availability for particular testing task so that will help to allocating the task accurately.

If new feature is developed understand that feature properly .or if there enhancement is going on existing product then take help of last version project test cases ,script which will be help to do parallel testing.

Test Estimation  judgments come with the experience with previous project.

Bug checking ,regression testing is purely depend upon the size of the project .If more number of the featured develop the chances of bug and checking of the bug fixing more so it may be spoil the testing timeline so you need to be take buffer time for that so you can do this type of testing activity too.

Communication is very important factor, do not hesitate to take the help of and communicate with the team member, developer because at end the project needs to be complete given timeline with quality.

Requirement analysis : Why it is important?

Requirement analysis is very crucial part in testing and it is core activity of the tester.
Tester need to understand the requirements clearly. If there is bigger requirement that need to be split in small requirements and need to be work on it.

The requirement has to be clear, readable, understandable, traceable, and measurable.

If we say requirement clear that mean there is no confusion .If we say readable that mean any non-technical person need to be understand requirement .There is no any unnecessary technical term and It is easy to understand.

The Requirement should be measurable that mean no any assumption .For e.g. take web application if user enter the search term then application need to response as soon as possible. Seeing this requirement we can’t understand what exactly it mean? "as soon as possible" .does it response in 1min,60 sec or in 30 sec ? so there is need to be a specific time in which we can measure the response.

Requirement should be traceable with different level that mean it can be traceable to design level, coding or Testing level.
When we say traceable in testing that mean each Requirement has their own testcase.That requirement need to be traceable to their respective test cases.

The Requirements are key factor for the tester.

Communication is more important, if you do not understand any requirement ask the question until you understand requirements clearly.

Change in requirement: sometimes it happens the requirement get change so in that case it has to be defined process for receiving the new requirement and Ensure that the new requirement request is it approval from all stakeholder.

Test Coverage

When we start testing there are so many question arises like

How much testing is enough?

When we will say the product is good to go?

How we can assure the quality of the product is good?

When we will have to stop testing?

Is the 100% test coverage is important?

Can we achieve 100% test coverage with in timeline?

When we will say testing is sufficient?

How do we measure the software testing completeness?

See in my point of view we can measure the quality by doing the requirement coverage, defect coverage, code coverage.

When we say requirement coverage that mean how many requirements are get validated? Can all requirements trace the respective test cases? Do all the test cases have passed? In vice versa trace the test cases to the specific requirement that requirement is need to be passed. In short software needs to be tested against the all requirements

In Defect Coverage in need to be known how many defect we found? How many defects has fixed?

Code coverage is all about evaluating the test cases against the actual code. We also do the code coverage by doing statement coverage, decision coverage,

  

 See basically when you execute the test case you are testing the component, feature and requirement too. One test case can cover zero or more component and zero or more requirements.  The term Test Case Coverage means to me a measure of how many of the product requirements are being tested by the defined test cases. It is the testers’ job to define their test cases based on the requirements and the goal should be 100% coverage or close to that.

 Test coverage Formula= (Total no of test case executed/ Total no of test case planned)*100

Test coverage ensure that testing is carried out effectively .

Examples of Priority & Severity

Types Of Defect	Example 1	Example 2
High Severity Low Priority	If you found that there is major crash in the functionality of the application but that particular module not to be released in this case priority is low but severity is high	A banking application which generate the weekly ,monthly ,yearly report .if there is fault calculating the yearly report. then this is high severity but low priority
High Severity High Priority	A Fashion Site maintain the customer details on the saving record if is doesn't allow to save record then this is high priority and high severity bug	A banking application which generate the weekly ,monthly, yearly report .if there is fault calculating the weekly report then this high severity & high priority because this fault block the functionality
Low Severity High Priority	Cosmetic Change is the Web site name and Found at time of delivery the Severity of the bug is low but priority is high because it affect the business.	If there is Spelling mistake or content issue on the homepage of a website which has daily hits of lakhs in this case the bug is not affecting the functionality but seeing the status and popularity of the website it is high priority for the business and low severity.
Low Severity Low Priority	If there is spelling mistake on the page which has not more hits then it is low severity low priority	If there is improper alignment of the page then it is low severity and low priority

Priority & Severity

Priority:
The Priority status is set by tester to the developer mentioning the time frame to fix defect. If the high priority is mentioned then the developer has to fix it at the earliest. Priority depends on the urgency with which the bug need to fixed

Severity:
The Severity status is used to explain how badly the deviation is affecting the build. Severity depends on the harness of the Bug.

Related Document:
Examples of Priority & Severity

Defect Life Cycle

1.  New: When the Defect is reported for the first time, its status will be “NEW”. This means that is yet to be approved. The New defect can be a Assign, Rejected or Deferred. 2. Open/Assign: The lead of the tester study the New Defect . Then change status from New to Open/ Assign. And Assign to the respective developer. See you can make the two status separately that Open and Assign .Open : The defect is the Open but not still yet Assign. Assign: The defect Open and Assign to the Developer. 3. Resolved: Developer fixes the defect, assigned back to respective tester. By changing the status of the defect Resolved. The fixed defect need to be verify by Tester/Test Team . If the defect is correctly fixed then Tester change the status Verified else Reassign/Reopen. 4. Deferred: If the New or Assigned defect is decided to be fixed in next release instead of the current release then that defect status change to the Deferred. 5. Rejected: If the defect found to be invalid then it is rejected . The defect need to be rejected by either of Test team lead/Development lead . 6. Verified: If tester find there the defect is fixed then status change to Verified. 7. Closed: If tester feel that filed the defect is no longer exist in the software then it change the final status to be Closed. 8. Reopened/Reassigned: If the defect still exists even after the bug is fixed by the developer, the tester changes the status to Reopened/Reassigned.

How the Bug Report is important?

Bug report is the report to tell the programmer/developer to fix the bug.Seeing the bug report the programmer need to be understand what's the bug is all about.Bug report is the way where you can convince the programmer to fix the bug .Even if you are not the present on your desk the your bug report should do your work at your(Tester) absent.So for that, the bug report should be effective,informative & understandable.If the bug report is good then it is high chances to be fixed the bug.

1.The summery of the bug report should be clear and effective , the summery of the bug should give the more information to reader. Seeing the summery the reader need to be visualize the failure,impact ,consequences of the bug.
2.In the description of the bug report need to be write details of the bug.Like bug environment,In which platform the bug occurs. dependencies of the other module and component all.
3.Write Step to reproduce the bug, give more detailing of the steps.
4.Specify the priority and severity of the bug.Priority indicated when you want to be fixed the bug and severity indicated impact and consequences of the bug.
5.Attach the image file if it necessary.
These are the main component which need to be present in the bug report.

 Filed the bug report on the time don't wait for next-day.Don't make Assumption that obvious bug has been filed.because sometime it's not.Filed the minor bug too don't be hesitate to file the minor bug because some time that minor bug can cost lot.Do not filed the duplicate bug report if you know that then do cross-references.

Traceability Matrix

The Traceability Matrix is to be able to trace from top level requirements to implementation, and from top level requirements to test. It shows the relationship between Test Requirements and Test Cases.

Using Traceability Matrix, we can check that which requirements are covered in which

Test cases and which test case covers which requirements. The same apply for the code too means which codes are covered which requirements and which requirements are covered in which section of the code too.

They are types of traceability matrix:

1. Forward traceability

2. Backward traceability

3. Bidirectional traceability

1. Forward Traceability:

Mapping takes place from requirements to test cases

2. Backward Traceability:

                     

 Mapping takes place from test cases to requirements.

 Bidirectional Traceability:

  

It contain Forward and backward traceability .Bidirectional matrix is good for practise 

A traceability matrix is a table that traces a requirement to the tests that are needed to verify that the requirement is fulfilled. A good traceability matrix will provide backward and forward traceability,. The matrix links higher level requirements, design specifications, test requirements, and code files. This is also known as Requirements Traceability Matrix or RTM.

In RTM each requirements should be traceable: Written test cases should be traceable to its requirement specification. If there is new version then updated test cases should be traceable with that.

and make sure that all requirements included in the test cases

It Easy to identify the missing functionality.

If there is a change request for a requirement, then we can easily find out which test cases need to update.

It is also use for the test coverage.

Why Testing is important.....

Testing is about verifying that what was specified; what was delivered. In simple word software testing is activity to check whether the actual results match the expected result. It is very important to understand that testing is also continuous process .Testing does not stand alone it is intimately dependant activity but it is separate process activity .Testing is the activity which can reduce the defects.

Testing is also begun from the starting phase of the SW Life cycle from the requirements. Traditionally testing is take place at end of the s/w life cycle (Waterfall model), Testing should take place through out software life cycle. If you want to cut down cost of the bug find bug as early as possible. Testing is like repeated activity testing never completed in one pass it has to be give more passes or you can more iteration. Because as you do so you generate more confident for that product.

We say best software which tested by thousands of users under various different condition. Then we can say it is good to go or “stable” but this does not mean that software is bugfree.it’s mean that bugs are well-identified and well understood.

Software bugs can potentially cause monetary or even loss of life. It can be expensive or even dangerous.