Thursday, September 12, 2013

Win 8/1/IE 11 - Cross Browser Testing, Device Testing and more cool features


I am sure many of you would have discovered these if you have installed Win 8.1 but I wanted to quickly share with others the cool features that IE 11 brings out the box as part of developer toolbar. Highlighting few of them below:

 

1.      Cross Browser/Platform testing: This is cool to see how you site renders on different browser (not just limited to different versions of IE) and  OS’s as well as different resolutions. This will be quite handy for testers.

 
           

 

 

 

2.      UI Responsiveness: Looks pretty nice for performance benchmarking and quick assessment of performance.

                                   



 

 

3.      Network:

 



 

4.      Memory:

               



 

5.      Profiler

 
              


 

 

Test Effectiveness, Test Efficiency, Defect Removal Efficiency (DRE) - Jargons :)



I was talking to a colleague today around difference among these test metrics and I am sharing it with you all if it helps :)
 

Test Case Effectiveness = Total defects found by test cases / Total defects**

e.g. if 80 defects were found by test cases and 10 were through ad hoc testing and 10 were leaked to UAT / Prod then TC effectiveness is 80 %

 

** This includes all defects found post build  phase (after test cases are designed) so if buddy testing was done then sure it should be added to total defects as we will use our test cases to do buddy testing.  Total defects will also include the defects found in UAT and post production as they are leakages.

 

Test Efficiency = No. of valid defects  / Total Defects found by test team (including invalid defects)

 

e.g. if 90 defects out of 100 were accepted then Test efficiency is 90 %

 

This gives us the rework and wastage due to invalid bugs that we rejected

 

Defect Removal Efficiency (DRE)  = Total defect found before delivery (through review, inspection, testing etc) / Total defect during project lifetime

 

Here we are saying doesn’t matter if we found them by test case or reviews, if we found them before UAT then its good and the defects that are found in UAT and Prod will be added to denominator and will show our DRE.

Saturday, August 17, 2013

Mob Testing (inspired by Mob Programming)


Testers & QA's,

There is something interesting that we might want to try. I came across an upcoming agile practice called Mob Programming. In gist, this takes pair programming to next level by coding as a team. The idea is simple that you can write the best code when one person is actually typing the code and rest of the team is providing inputs. This has helped teams deliver builds without bugs. If you think, you are developing, unit testing, reviewing and testing the code all-at-once. How cool is that?

Read about it @ http://mobprogramming.org/mob-programming-basics/

Driver/Navigators

We follow a “Driver/Navigator” style of work, which I originally learned from Llewellyn Falco as a pair programming technique. Llewellyn’s approach is different from any other I have been shown, have seen, or have read about (and I think he invented it or evolved into it.)
In this “Driver/Navigator” pattern, the Navigator is doing the thinking about the direction we want to go, and then verbally describes and discusses the next steps of what the code must do. The Driver is translating the spoken English into code. In other words, all code written goes from the brain and mouth of the Navigator through the ears and hands of the Driver into the computer. If that doesn’t make sense, we’ll probably try to do a video about that or a more complete description sometime soon.
In our use of this pattern, there is one Driver, and the rest of the team joins in as Navigators and Researchers. One important benefit is that we are communicating and discussing our design to everyone on the team. Everyone stays involved and informed.
The main work is Navigators “thinking , describing, discussing, and steering” what we are designing/developing. The coding done by the Driver is simply the mechanics of getting actual code into the computer. The Driver is also often involved in the discussions, but her main job is to translate the ideas into code. Of course, being great at writing code is important and useful – as well as knowing the languages, IDE and tools, etc. – but the real work of software development is the problem solving, not the typing.
If the Driver is not highly skilled, the rest of the team will help by guiding the Driver in how to create the code – we often suggest things like keyboard short-cuts, language features, Clean Code practices, etc.  This is a learning opportunity for the Driver, and we transfer knowledge quickly througout the team which quickly improves everyones coding skills.

I would suggest that if we apply the same to testing how productive it can be. I know exploratory testing is cool but what would be even better is that the entire test team gets into a room and one person takes the responsibility of "driver"- he will follow the instructions of the team and document/execute the test cases. Rest of the team will play "navigators" and suggest scenarios and different test condition. This will be a great demonstration of collective IQ and things like mails, meetings, triage calls can be eliminated to reduce unproductivity.

Let me know your thoughts and if you find this interesting, we can pilot this in one of your projects and evangelize it.
 

Tuesday, May 7, 2013

TFS Live Configuration - TFS Login Details

 
If you are trying to use our TFS Live app for TFS Server 2010/2012 and finding it hard to configure the app then please refer to below details:
 
Details about tfs setting screen:
 
tfs server name: <<the name of your TFS Server>> e.g. xyz-tfs-server
 
path: <<the tfs path. By default it is “tfs” >> e.g. tfs
 
port: << the port that is configured for your tfs >> e.g. 8080 as default for http and 443 as default for https
 
protocol: << whether your tfs is http or https>> e.g. http / https
 
project collection name: <<the name of your project collection>> e.g. defaultcollection
 
 
username: <<your domain credential that you use to connect to your TFS >> e.g. abc\rajkamal
 
password:  ***** (your domain password
 
Sample #1. Enter the TFS details and press authenticate
 
 
image
 
Sample #2. Enter the TFS URL with all the details directly as “TFS Servername”. In this case, you don’t have to worry about entering path, port, protocol or project collection name as they are part of the URL itself
 
 
image
 
 

Enable Alternate Credentials for Hosted TFS / TFS Service

 
If you are trying to use our TFS Live app for TFS Service instance then you must login using “Alternate Credentials”. Essentially you will need to provide your windows live id and newly set password using “Alternate Credential”  when trying to login to our app. This is required due to limited TFS Services API support.
 
 
Details about tfs setting screen:
 
tfs server name: <<the base URL of you TFS Service account>>>  e.g. https://ranjitgupta.visualstudio.com/
 
project collection name: <<the name of your project collection. Most probably it will be defaultcollection>> e.g. defaultcollection
 
username: <<the windows live id that is used to create access>> e.g. raj.kamal@outlook.com
 
password:  ***** (password set using “Alternate credential”)   - Read the section below to enable this setting
 
 
image
 
 
Steps to enable “Alternate Credentials”
 
Step 1. Go to your TFS Server home page and login with your windows live id
 
Step 2. Go to My Profile setting as shown below (at right top)
 
 
image_thumb[2]

Step 3: Go to “Credentials” tab in “User Profile” window

Step 4: Select “Enable Alternate Credentials”

image_thumb[4]

Step 5: Set a new password (Note: This can be same password as of your windows live id so easy to remember)

 image_thumb[7]