Mainframe testing
novice
i would really appreciate any leads to sites/forums on
mainframe testing..i.e. non Y2k please.....
furthermore any discussion/facts etc by mainframe testing
gurus will be gratefully accepted.
best regards
Navin
* Sent from AltaVista http://www.altavista.com Where you can also find related Web Pages, Images, Audios, Videos, News, and Shopping. Smart is Beautiful
vant...@my-deja.com
The principles of testing on MF are similar to GUI. Is there anything
specific you are looking for?
--
Tim Van Tongeren
Sent via Deja.com http://www.deja.com/
Before you buy.
novice
i was thinking more on the lines of testing involving
Cics+Cobol+Db2(sql) systems.
what i wanted was experiences,tips in the methodology to
be adopted with reference to the M/F Platform.
Thanks
Lig
What type of testing do you want to do.I am into data driven
testing(Automated) , using WINRUNNER. Specify what you want to know. I will
see if I can help you.
Cheers
Lig
novice <navinpr...@hotmail.com.invalid> wrote in message
news:0237dd28...@usw-ex0108-061.remarq.com...
novice
why i wasn't very specific was i did not want to restrain
the topic to maybe automated or manual testing.
since you have mentioned about automated testing ..
can you pls describe briefly the steps used in your
testing process ??
it may be about 1) how to decide to use automation or not ?
2) method of identifying test cases ?
3) which area should be focussed first ?
i.e GUI,Path coverage, code coverage, performance, etc
4) regression testing ?
and so on..
thanks
navin
novice
bhomes
I don't know test automation tools for mainframe. They might exist though.
What I used in a similar situation was a standard test automation tool on a
windows emulator.
The emulator accessed the Cobol, DB2 and CICS programs and the capture
replay tool worked on the emulator window.
The trick was that there were no buttons or GUI objects in the emulator
window. The solution was to have the tool check within the emulator window
(copied to the clipboard), the presence of something that would signify that
a result had been sent.
This solution enabled automated testing (including some regression testing).
Hope this helps
---- Bernard H.
"novice" <navinpr...@hotmail.com.invalid> a écrit dans le message news:
0237dd28...@usw-ex0108-061.remarq.com...
> Hi
> i was thinking more on the lines of testing involving
> Cics+Cobol+Db2(sql) systems.
> what i wanted was experiences,tips in the methodology to
> be adopted with reference to the M/F Platform.
> Thanks
> Navin
>
>
novice
thanks for your post.
I would like to know more about the emulator which you
used could you pls give me more info regarding the
name of the emulator, the Plus and negative aspects
which you found on using it and id possible some info
regarding how you did your preparation for testing i.e
recording the flow etc
would greeatly appreciate your reply
thanks in advance
navin
bhomes
The emulator at the time was Relay Gold and emulated 3270 terminals. There
was also a version of Relay Gold emulating VT220 terminals (for Unix).
There were some things to take into account (problems for french national
character) but nothing major.
Negative aspects :
- application base state concerned only the emulator, not the M/F session,
so this had to be adressed
- database could not be accessed directly, as it required another emulation
session
- processing of screen verification was done through the clipboard
- the class testing and content verification functions from the capture
replay tool could not be used (there was only one object : the emulation
window)
Positive aspects :
- capture of screens via the clipboard created .txt files that were easy to
manipulate
- the capture replay tool used (QA works - now Silk) was easy to program
- a small tool was developped to translate spreadsheet files (containing the
instructions) to commands understood by the capture replay tool and applied
to the emulator session.
- multiple sessions (on different PCs) could be synchronized, including
database interrogations
Testing preparation
- You can't record as easily as you would using a windows app. The tool
developped enabled us to write the tests faster and maintain them easily.
Hope this helps
Contact me directly for more detailed info if necessary
--- Bernard H.
"novice" <navinpr...@hotmail.com.invalid> a écrit dans le message news:
0a0bc822...@usw-ex0108-061.remarq.com...
novice
thanks a lot for the detailed info..
Will certainly use your insightful info
thanks again
Navin
lig
I have been extensively involved in Y2K and now EURO testing on M/F . I use
WINRUNNER on DB2 and VSAM files. Data comparision is effected seperately.
Much of my inferences below are from the Insurance industry and the test
packs are designed for reusability.
As regards the screen captures etc, we code the script such that the
baseline is done and this forms the bais for unit/module testing. Meaning
the inputs in baseline are used as data for testing. i.e These values are
used to test the very same system after it has undergone change . The
expected results have been logged in the baseline and trhe actual results
are trapped during testing.
Coming to identifying test cases, with specific reference to EURO , I decide
on the automation considering the number of entries on each screen , the
complexities of entries and above all ,the number of amount fields to be
captured and compared and the over all reduction/savings in time and effort
of the process compared to manual entries.Do keep in mind that the effort of
automation is ONLY ONCE and once thats done , testing is mostly at the hit
of the button , even if something is found wrong during testing. Alternately
, I would say that there is no point in automating a stream of say 15
screens of entires of various nature in an insurance industry and ultimately
trapping 1 amunt field to compare on the 16th screen , say an obvious round
figure only to exit after that.
As regards choice of testing, it could be done in many ways.A few that I
commonly follow are :
1. Combine screen flows option wise;Meaning take option 1 on screen 1, then
all options on the subsequent screens.
2. Combine similiar modules by functionality/complexity of programs/ ease of
automation /
3. Estimate the files/databases updated by each program and club the ones
that read and update similiar files/DBs together.
Coverage : We come across some blind variables/values that are generated
based on some screen inputs. These go on to update some files and surface in
a different screen/application.Such cases are difficult to trap.We design
some temporary screens that display the value of the variables when
generated and before insertion into the DB.Such code intrusion is kept
minimal.A better way would be to querry thge DB independently of the testing
and get the value that has been inserted by the process/program and check if
it is indeed correct.The fact that we do dual roles of development and
testing gives us a little flexibility for code intrusion;Although pundits
will oppose such an idea.
Mail me for any clarifications.
Cheers
Lig
remove .nospamm to reply
novice <navinpr...@hotmail.com.invalid> wrote in message
news:08335b66...@usw-ex0108-061.remarq.com...
> hi again
> why i wasn't very specific was i did not want to restrain
> the topic to maybe automated or manual testing.
> since you have mentioned about automated testing ..
> can you pls describe briefly the steps used in your
> testing process ??
> it may be about 1) how to decide to use automation or not ?
> 2) method of identifying test cases ?
> 3) which area should be focussed first ?
> i.e GUI,Path coverage, code coverage, performance, etc
> 4) regression testing ?
> and so on..
> thanks
> navin
>
>
>
asifsoh...@gmail.com
There are various kind of tests : integration tests, performance tests, volume tests, regression tests, stress tests etc. You can test a all cluster of programs or a whole day or night of production. You need to know the expected results, discuss with business analysts, with system team, with Capacity team, ….And you will have to know a lot of tools or technic : Strobe, File Aid, Ecomp, CA7, report Excel, Word, DB2, CICS, zOS, Sort, backup, recovery, etc.
visit [URL="http://www.mosttechnologies.com/solutions/mainframe-testing]Mainframe Testing[/URL]