Merge multiple TRX files (Visual Studio Test Result File)

TRX files are  Visual Studio test results file. For any reason, if you end up having multiple TRX file you still can merge all of them into one file using utility given below. Multiple TRX files can generate as a result of test suit failing and a re-run is required when only failed cases are executed.

Merge TRX files- (only 2 files at a time)

1. Download this utility
2. Copy all TRX files in the same folder
3. USAGE: trxmerger.exe <input1>.trx <input2>.trx <output>.trx

Note: Pick up the TRX file which was created first (Check time stamp) and then move to the next one.Changes from second trx file will be overwritten on first if there are matching test cases.The merged file then can be merged with next one and so on.

Convert TRX file into more user friendly format like HTML-

1. Download this utility
2. USAGE:  VSTSTestReport.exe  "C:\<filename>.trx" <filename>.html
   
   
   
   Cheers!
   Abhay

Mobile Automation: Appium/AVD/Android/Windows - Device not found error,restarting adb server.[solved]

Platform: Windows 7 64 bit
Appium Version: AppiumForWindows-0.16
Android SDK:  adt-bundle-windows-x86_64-20140702

If anyone is working on Appium automation and trying to pull up some automation on Android/Apple and if you run across any errors like below-

debug: Checking whether adb is present
debug: Using adb from C:\AndroidSDK\adt-bundle-windows-x86_64-20140702\adt-bundle-windows-x86_64-20140702\sdk\platform-tools\adb.exe
debug: Trying to find a connected android device
debug: Getting connected devices...
debug: executing: "D:\APPIUM\SDK\sdk\platform-tools\adb.exe" devices
debug: Could not find devices, restarting adb server...
debug: executing: "D:\APPIUM\SDK\sdk\platform-tools\adb.exe" kill-server
warn: code=ENOENT, errno=ENOENT, syscall=spawn
error: Error killing ADB server, going to see if it's online anyway
debug: Getting connected devices...
debug: executing: "D:\APPIUM\SDK\sdk\platform-tools\adb.exe" devices
debug: Could not find devices, restarting adb server...
debug: executing: "D:\APPIUM\SDK\sdk\platform-tools\adb.exe" kill-server
warn: code=ENOENT, errno=ENOENT, syscall=spawn
warn: code=ENOENT, errno=ENOENT, syscall=spawn
debug: Getting connected devices...
debug: executing: "D:\APPIUM\SDK\sdk\platform-tools\adb.exe" devices
debug: Could not find devices, restarting adb server...
debug: executing: "D:\APPIUM\SDK\sdk\platform-tools\adb.exe" kill-server
warn: code=ENOENT, errno=ENOENT, syscall=spawn
warn: code=ENOENT, errno=ENOENT, syscall=spawn
error: Error killing ADB server, going to see if it's online anyway
debug: Getting connected devices...
debug: executing: "D:\APPIUM\SDK\sdk\platform-tools\adb.exe" devices
debug: Could not find devices, restarting adb server...
debug: executing: "D:\APPIUM\SDK\sdk\platform-tools\adb.exe" kill-server
warn: code=ENOENT, errno=ENOENT, syscall=spawn
error: Error killing ADB server, going to see if it's online anyway

This is most probably because appium/adb cannot read (and eventually expand)Windows System32 folder. Do following steps-

1. Open  command prompt and type "path" (no quotes).
2. Check if this path is present- C:\WINDOWS\system32. If not, go to step 3.
3. Add path like this in your system variable-  %SYSTEMROOT%\System32

PS: This worked for me, try your luck!

Cheers-
Abhay

Effort estimation for Performance Testing

A lot of time you need to have a quick answer on questions like-

1. Total man force is required to execute this performance task?
2. How many hours are required on different project activities?
3. How many person days are required for individual project activities

and many more questions that are hard to answer (specially in short period of time).

Attached is an estimation template which can make your life bit easy and is a good place to start with- The results would be in terms of "efforts required by single resource". There are 3 tabs in the spreadsheet: "Estimation Summary" "Timeline" "Assumptions".

To start with first have a look at Timeline tab. It has been designed "With single resource". It is actually a simple table with Activities and Time. Activities are very generic and should hold true for most of the projects-

1. Requirement/Application Analysis, KT 
2. Test Planning
3. Test Setup
4. Test Design
5. Test Development
6. Iterative Test Execution & Analysis
7. Summary Report Preparation
8. Test Management

and time is divided into week1..week2..etc.

All you need to do is select color coding for different activities in terms of single resource and switch to "Estimation Summary" tab.

Estimation Summary tab will give you a nice overview of no of hours required by individual activities and person days. (Assuming 1 person day=8 hours).

Now fly and enjoy the template!

Cheers!
Abhay

Test Approach: Agile + Kanban

The most common question that pops up is- Do we have any standard approach for testing a application in Agile + Kan ban environment. The answer is simple- No. To justify my understanding lets look at what is Agile and Kanban all about. We will then see what is the most working testing approach in such environment- (I have taken most of the references from Internet which means all the credit MUST go to original authors. For the references please see end of this document )-

Agile

• People across functional areas (programmers, testers, technical writers, sales, services, product managers) all work together as one team rather than different groups working in 'stages'.
• Everyone in the team falls into category of ‘developers’ as they work together to develop and improve a product.
• Iterative development (work in short development cycles with focused objectives).
• Incremental development (frequent releases to client) .
• Focus on human communication 
• High visibility of team's progress to management, stakeholders, clients  using daily stand ups.
• Continuous feedback from customers and stakeholders.

Kanban

• You’ll find a lot of terminology in Lean software development comes from Japan and from the Toyota Production System in particular. Kanban translated literally: “Kan” means visual, and “ban” means card or board.
• Kanban is a new technique for managing a software development process in a highly efficient way. Kanban underpins Toyota's "just-in-time" (JIT) production system. Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.
• Kanban is incredibly simple, but at the same time incredibly powerful. In its simplest incarnation, a kanban system consists of a big board on the wall with cards or sticky notes placed in columns with numbers at the top.
• Limiting work-in-progress reveals the bottlenecks so you can address them. Limitations that we saw in previous slides can be taken care of by Limiting work-in-progress.
• The cards represent work items as they flow through the development process represented by the columns. The numbers at the top of each column are limits on the number of cards allowed in each column.
• The limits are the critical difference between a kanban board and any other visual storyboard. Limiting the amount of work-in-progress (WIP), at each step in the process, prevents overproduction and reveals bottlenecks dynamically so that you can address them before they get out of hand.

Test Approach in Agile + Kanban 

• Create just ONE document- Overall test strategy. No one reads test plan during sprint execution.
• Test strategy should be important to the devs, testers, product owners, automation creation & maintaining folks
• Test strategy should have - which exploratory test charters are planned during the current sprint and put that into the Test column
• Describe a loose framework that describes what we are going to do for stories, what we are going to do for integration, what we are planning to do for our exploratory testing that doesn't fit in to stories, and then when we are going to review our test strategy?
• Write logical acceptance criteria.
• How to handle backlog items?
• Test strategy drives entire development team and explains HOW you plan to start testing
• Each story assigned to the sprint should have test tasks in it, that becomes your defacto test plan.