Pega SMA ( Agents, Listeners ) in Testing

Coming Soon...!!!

Performance Testing in Pega

Performance testing in Pega using PAL (Performance Log Analyzer)

Pega UI Inspector

Coming Soon...!!!

Pega Rules Testing

In order to start rule testing we must need to know What is meant by a Rule.

According to PRPC,  A rule is a named business object that defines the behavior of part of an application. In Process Commander, a rule is a single persistent instance of a class derived from the Rule- base class.

Generally, everything we create in Pega is called as a Rule. There are various types of rules in Pega but we cannot test all the rules. I will focus on only those rules which are useful for testing purpose and which adds value to testing.

Pega Automated Unit Test

Coming Soon..!!!

Clipboard Testing

Coming Soon... !!!

All About Software Testing

Their are two types of testing mainly Functional and Non-Functional.

Functional testing is used to perform to test  Functionality of that project or product.
Functional testing has following methods

1-GUI Testing/Control Flow Testing/Behavioral Testing
2-Input Domain Testing
3-Error Handling Testing
4-Manipulation Testing
5-DataBase Testing

Some Explanation is given below regarding above points

We are trapped by the same ambiguities that lead developers into error. Suppose the requirements
specification says widget “X must do Y” but widget X actually does Y+Z? How do we evaluate Z?
Is it necessary? Is it desirable? Does it have any other consequences the developer or the original
stake-holder has not considered? Furthermore how well does Y match the Y that was specified by
the original stake-holder?
Here you can being to see the importance of specifying requirements accurately. If you can't specify
them accurately then how can you expect someone to deliver them accurately or for that matter
test them accurately?
This sounds like common sense but it is much, much harder than anything else in the software
development life cycle. See my Primer on Project Management for a discussion.
Alpha and Beta Testing
There are some commonly recognised milestones in the testing life cycle.
Typically these milestones are known as “alpha” and “beta”. There is no precise definition for what
constitutes alpha and beta test but the following are offered as common examples of what is
meant by these terms :
Alpha – enough functionality has been reasonably completed to enable the first
round of (end-to-end) system testing to commence. At this point the interface
might not be complete and the system may have many bugs.
Beta – the bulk of functionality and the interface has been completed and
remaining work is aimed at improving performance, eliminating defects and
completing cosmetic work. At this point many defects still remain but they are
generally well understood.
Beta testing is often associated with the first end-user tests.
The product is sent out to prospective customers who have registered their interest in
participating in trials of the software. Beta testing, however, needs to be well organised
and controlled otherwise feedback will be fragmentary and inconclusive. Care must also
be taken to ensure that a properly prepared prototype is delivered to end-users,
otherwise they will be disappointed and time will be wasted.
11
White Box testing
White-box or glass-box testing relies on analysing the code itself and the internal logic of the
software and is usually, but not exclusively, a development task.
Static Analysis and Code Inspection
Static analysis techniques revolve around looking at the source code, or uncompiled form of
software. They rely on examining the basic instruction set in its raw form, rather than as it runs.
They are intended to trap semantic and logical errors.
Code inspection is a specific type of static analysis. It uses formal or informal reviews to examine
the logic and structure of software source code and compare it with accepted best practices.
In large organisations or on mission-critical applications, a formal inspection board can be
established to make sure that written software meets the minimum required standards. In less
formal inspections a development manager can perform this task or even a peer.
Code inspection can also be automated. Many syntax and style checkers exist today which verify
that a module of code meets certain pre-defined standards. By running an automated checker
across code it is easy to check basic conformance to standards and highlight areas that need
human attention.
A variant on code inspection is the use of peer programming as espoused in methodologies like
Extreme Programming (XP). In XP's peer programming, modules of code are shared between two
individuals. While one person writes a section of code the other is reviews and evaluates the
quality of the code. The reviewer looks for flaws in logic, lapses of coding standards and bad
practice. The roles are then swapped. Advocates assert this is a speedy way to achieve good
quality code and critics retort that its a good way to waste a lot of people's time.
As far as I'm concerned the jury is still out.
Dynamic Analysis
While static analysis looks at source code in its raw format, dynamic analysis looks at the
compiled/interpreted code while it is running in the appropriate environment. Normally this is an
analysis of variable quantities such as memory usage, processor usage or overall performance.
One common form of dynamic analysis used is that of memory analysis. Given that memory and
pointer errors form the bulk of defects encountered in software programs, memory analysis is
extremely useful. A typical memory analyser reports on the current memory usage level of a
program under test and of the disposition of that memory. The programmer can then ‘tweak’ or
optimise the memory usage of the software to ensure the best performance and the most robust
memory handling.
Often this is done by ‘instrumenting’ the code. A copy of the source code is passed to the dynamic
analysis tool which inserts function calls to its external code libraries. These calls then export run
time data on the source program to an analysis tool. The analysis tool can then profile the program
while it is running. Often these tools are used in conjunction with other automated tools to
simulate realistic conditions for the program under test. By ramping up loading on the program or
by running typical input data, the program’s use of memory and other resources can be accurately
profiled under real-world conditions.

Purpose of Testing

The purpose of testing is to reduce risk.

The unknown factors within the development and design of new software can derail a project and
minor risks can delay it.
By using a cycle of testing and resolution you can identify the level of risk,
make informed decisions and ultimately reduce uncertainty and eliminate errors.

Testing is the only tool in a development's arsenal which reduces defects. Planning, design and QA
can reduce the number of defects which enter a product, but they can't eliminate any that are
already there.

And any kind of coding will introduce more errors since it involves changing
something from a known good state to an unknown, unproved state.

Ideally testing should take place throughout the development life cycle. More often than not (as in
the waterfall model) it is simply tacked onto the back end. If the purpose of testing is to reduce
risk, this means piling up risk throughout the project to resolve at the end – in itself, a risky tactic.

It could be that this is a valid approach. By allowing developers to focus on building software
components and then, at a later date, switching to rectifying issues it allows them to
compartmentalise their effort and concentrate on one type of task at a time.

But as the lag between development and resolution increases so does the complexity of resolving
the issues (see “Test Early, Test Often” in the nextc hapter).

On any reasonably large software development project this lag is far too long. Better to spread different phases of testing throughout  the life cycle, to catch errors as early as possible.

What is Pega Testing?

Welcome to this blog where you will be learning about Pega Testing.

I have published the same in Quora to answer about Pega Testing. Below is detailed description about Pega Testing concept.

I think I am the best person to let everyone know about answer to this question as I am into Pega Testing for more than 6.8 years now.

I have started my career as a Manual Tester and my first project was into Pega. At that time, we were using Pega V 5.5.

As I was close with the development team I learned many things which is must to know when you were into Pega Projects. Later I worked with Pega 6.2, 7.1 and now with the latest version 7.3.1. I am CSA 7.1 Certified AND Pega Certified Business Architect 8.
Let me tell you how exactly Traditional Testing is different than Pega testing.

• Pega has a very good built in feature which we call as Pega Automated Unit Test or simply AUT.
• In it’s latest version, it supports almost all types of rules which can be tested.

1. Activities
2. Data Pages
3. Flows
4. When Rules
5. Data Transform
6. Case type ..etc

• As a tester we should be having knowledge to understand these rules and use effectively to enhance the quality of the application.
• Using AUT we just not automating the rules but also we are making sure that if any rule or step is being modified then it can be caught when we re-run the rules.
• Pega not only provides AUT but also it has it’s own debugging tools such as

1. Clipboard
2. Tracer
3. UI Inspector
4. PAL / PLA
5. DB Tracer
6. SMA ( Agents, Listeners )

• Using above tools QA team can analyze the issues without reaching to the development team in agile packed environments that certainly helps dev team efforts to fix the issues.
• Even Pega Operator ID’s play’s important role in verifying the application build, so being a tester you should know the

1. Operator ID rules
2. RuleSet,
3. Access Group
4. Worklist concept
5. WorkBasket concept
6. Service Level Agreements (SLA)
7. Declarative Rules such as ( Decision Table and Decision Tree)..etc

Now a days QA’s needs to move out from Traditional testing zone to the automation world, learn new things and keep enhancing their skills. 

Hope I have answered the queries around Pega Testing which most of the people are unaware of. Reach out to me if any questions around. Thank You. 

Pega Tester’s have more demand/package than the Traditional Testers.

Note:The content in this blog is purely copy right and strict action will be taken if someone is misused.
Any question, please let me know in Comment below. 

Kind Regards,

Fayaz Chaudhari

Pega QA Lead

www.linkedin.com/in/fayazchaudhari