דף הבית >> כתבות ומאמרים >> Microsoft team system 2010




Microsoft team system 2010 test essentia
the good, the bad and the uglyls

Microsoft team system 2010 test essentials – "the good, the bad and the ugly"

Obviously Microsoft announcement on the 20'Th of October for the new testing tools and capabilities of team system 2010 was a big wow…something that we have waited for a very long time.

I really liked the tester profile that Microsoft was aiming at:"the generalist tester" (what we all call "manual tester"). Accordingly Microsoft build a testing suite that should answer most of the desires that the generalist tester has (more than 70% of testing are done manually). They didn't forget off course the other 30% and build some capabilities for these testers as well….

On this post I will elaborate on the 5 "good" elements that Microsoft included in this suite (in the next one I will speak of the "bad" and "ugly" ones)

 The good: there are few initiatives that should make the difference:

1.      Lab Management - the most important step toward "no more no reproduce".  This idea is based on system center virtual machine manager that enable the tester to attach a snap shot of the defect environment to the bug report. This enable the developer to run the test on the same environment as the tester did.

2.      Rich bug - when finding a bug the tester will only have to "open" a new bug report and add a "name" to that report. All the rest will be added automatically including:

                         i.     Video recording of the run

                        ii.     Enable action recording

                      iii.     Capture machine information

                    iv.     Screen capture

3.               Coded UI – just like other record and playback tools (QTP) this feature can be used for functional testing. It is not too hard to deal with but still coding capabilities are a must.

4.               Manual test runner – a very handy feature that will record all the manual testing and will enable the tester to run the same tests automatically on future runs.

5.               Impact analysis – every code or requirement changes can show immediately the impact on other elements in the software and which tests must be run accordingly.

Ram

You can also visit my blog at www.qa.blogix.co.il


+ הוסף תגובה חדשה
תגובות:
Loading בטעינה...

Go Back  Print  Send Page
 QAtest אתר מהנדסי בדיקות תוכנה , דוא"ל : qatest@qatest.co.il | צור קשר