For want of a nail, the shoe was lost; for want of a shoe, the horse was lost;
For want of a horse, the rider was lost; for want of a rider, the message was lost;
For want of a message the battle was lost; for want of a battle, the kingdom was lost . .
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.
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
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
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.
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?
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.
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
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
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.