Featured

QA Strategy: Considerations & Decisions on Appian Projects

QA strategy:

Considerations & Decisions on Appian Projects.

This post summarises scenarios, requirements and decisions  that quite often our clients must take when facing these projects.

 

We will discuss questions like:

Must I automate my testing or can I continue with the manual test?

What should I expect from an automated testing tool?

I do have some tests automated. Will I lose all the work done?

How Appian supplied tools can help me and up to which extent?

Is it possible to combine different technical and functional approaches?

 

Welcome,

I really hope you read this short article until its end,

it may bring benefits in your testing strategy as well as improvements on how projects are managed and on your QA efficiency.



Let's go!

 

Any QA manager, in Appian projects, realise than only using manual testing becomes less and less efficient in every sprint:

Appian is so productive that regression increases quite quickly in few sprints.

 

If we don't want to limit delivery dates, we will soon have to decide:

  • Either we increase the effective resources testing, and therefore, we increase the costs.

  • Or, we keep progressively and constantly reducing the test depth and thoroughness, that is, we decrease the quality.

 

The best and common decision taken by QA managers is to:

  • Automate the testing.

 

But then, is when the big question arises:

Automate yes, but how?

 

Technology and experts are there to help:

 

There is always a techie freak in every team; which – is – good. Believe me. 
Sooner or later they will come up with the brilliant idea of using the Selenium driver in Java, or Python, to generate some automated testing.

Why not? At the end... we are developers, right? with a custom development and time, everything is possible!

 

Well,  it is definitively a possible way, but everyone has to bear in mind that Selenium works at a very low level.

Of course it allows you a great level of control, but that also means that you need expert developers, which is shown in the market at an expensive rate.

 

Ok!, let's assume the expense if there are results, right?

 

With this approach we usually see that reaching the expected results is quite difficult. Why?

Reason is quite obvious:

  • Low productivity, causing usually a higher cost.

  • Very limited communication between the Selenium guys automating and the rest of the team, including also the Appian designers!

  • The distance between a very technical work and the business testing. There is a wide gap which makes things more difficult.

 

While the techie approach is an option, it is poor compared with other approaches:

 

Let's have a look at this example

Let’s assume that in our Appian team we have one Selenium expert.

Only using Selenium, we can easily take a day to automate an Appian interface.

Some may think that this is too much, but remember that this is not only to click on a link, or populate some fields… You need to:

  • Manage the session.

  • Obtain the test data from an external source.

  • Apply the validation rules for every component in the interface.

  • Record evidences of the testing (logs, images, videos, ...)

  • And many other things, depending on how demanding we are.

 

It is not that easy, not even for an expert!

On the other hand, there are tools in the market that can automate the same content within minutes, with a normal trained tester.

As a conclusion, using Selenium as a foundation to automate any content is poorly efficient, and even worst in Appian projects.

But, even this is the general rule, in some very specific scenarios where everything else is not working, this powerful low level solution can be the best.

Instead, it can be very useful in very specific scenarios where there is no other way to automate a functionality, and the full control of Selenium is needed to achieve it.

Believe me, we do it. We have such experts… feel free to ask for more!

 

Then, how can we get more speed, what can rocket our efficiency?

Generic tools in the market

You can go to the market searching for test automation tools. There are a wide variety of solutions, from open source to extremely expensive tools.

Each tool has its pros and cons.

Cheap tools tend to be very low level, close to Selenium, with limited functionality, almost no collaboration among the team members and sharp learning curves.

There are also the most expensive tools, capable of an amazing versatility… but you really need to analyse if its worth to invest on such tools and get some ROI, given the cost of licenses, training and certifications.

 

This market is in constant change, and we see fashions and tools of every kind:

  • Simple navigation recording

  • RPA based tools

  • Image recognition based tools

  • And lately, a huge amount claiming to be based on IA

 

But one thing is clear: those are generic tools and are focused to cover the widest possible scenarios. Their target is wide.

This is why they are so complex, require training, and specialised resources.

 

But think on ROI. We’ve seen clients buying really powerful solutions with the idea of one-fits-all, and synergies between projects facilitate the ROI. But every project is different, and Appian projects are even more different than others.

 

Experience teach us that:

  • You must evaluate the urgency to automate: quick wins.

  • You need to consider if you really need to automate everything. Every app is different. Some may not need it at all.

  • "One fits all" is not usually the case. Analyse exceptions, combining solutions and their integrations.

  • And do not forget the fact that every bit you automate, must be maintained! And that's a cost on top of everything else!

 

You really need to carefully analyse the test automation scope and its costs when working with expensive investments. Only then you can expect certain return of your investment.

 

For example, automating the test in Appian applications is imperative because it expands quite easily.

But maintaining the automation with a generic product can be a nightmare.

 

If you're an Appian professional, you will be aware that there are four product updates per year.

Every update can break all your automated tests

 

Do you understand what happens when Appian changes how a component works? Keep reading...



Let’s look at the Appian approach as well

Appian has two particularities; first – I know I’ve already said this – it is super productive, and second, as you may know, it gets updated 4 times a year!

They do a great effort in fixing and improving the platform: Appian can change the way its components are shown from one version to the other.

 

That simple fact can easily break all the efforts to automate your testing with generic tools.

 

I’ve seen it with my own eyes in an Appian project , where they automated an application with a well know generic tool...

  • Test scripts did not even last for a quarter!

  • The first Appian update installed, broke all navigation tests!

  • In that update, Appian changed the way that calendars were shown. That tool based on image recognition, failed to reconcile the change (as many other tools) and they had to start over again!

 

These kind of updates are constant. You can't skip them as they provide improvements... the Appian product evolves!

This is why specialised tools and companies like us evolve with Appian.

 

Now, let's have a look at what you can find on the Appian Market.



Appian Market

You will find two tools supplied by Appian, free to use: FitNesse for Appian (FFA) and Cucumber for Appian (CFA).

Please, bear in mind that both solutions are low level and require certain expertise.

 

Firstly, we have FitNesse for Appian (FFA), based on the open source FitNesse.

You have to write the test syntax in a text editor, without the help of any compiler, with a curious syntax full of pipelines (|) and then paste it to a web interface in order to run it.

It is very hard to work with in a relevant project. You have to constantly be testing what you’re writing and there are no integrations nor extensions available.

 

Cucumber for Appian is a quite better approach than FFA and than Selenium. You develop in Java, you use a compiler warning you of the syntax, but even so is a world limited to developers.


It is quite a paradox to use Appian low-code for applications and then to require a Java expert to test it.

 

We understand Appian's aim to bring tools to facilitate the automated testing,

 

If you're evaluating the adoption of any of these tools, please consider that:

  • Both work at low level.

  • You will need Java Developers, working on black screens to code and run tests.

  • The output is a log that you need to read to analyse the issues.

  • Its working environment, specially FFA, is error prone.

  • There is almost no chance for collaboration.

 

 

You will also find our solution in Appian market!

 

Why did we create Appian Automated Testing (AAT)?

 

Throughout the last five years we’ve seen how our Appian projects become more multi disciplinary:

  • There are more participants with different specialities in the projects.

  • The size of the applications is also increasing.

  • The expected delivery time is shorter.

 

In this reality, we require high level tools to facilitate team work in such a critical thing as quality.

We need flat learning curves, run away from black text screens and integrate the business players. Knowing Appian should be enough.

 

We created AAT precisely from our suffering in those projects, to run away from black screens, prioritising collaboration and covering the needs we found in our projects.

 

As an Appian partner, we had the vision to unify all our knowledge and experience in AAT.

We have created a powerful tool, low-code, where all delivery participants collaborate.

Given our specialisation, we've satisfied BDD methodology at its maximum extent: test can be ready before the development!

 

This is how AAT was born and how it has been evolving for the last five years, getting the best of the technologies and from the Agile world;

From understanding that change is constant, and that we can´t depend on where components are located, of their shape, position, colour, etc. of a component, because you can bet that tomorrow it will be different.

 

 

We realised that:

  • It does not matter if I can record the browsing, because tomorrow it will be slightly different

  • The only constant thing is the behaviour, the behaviour and not the visual aspect is the key.

 

This is why AAT is a Behaviour Driven Development (BBD) tool.

You can find more information on the Web, in the Appian Market, but most primarily by asking us.

 

Our team is very specialised but one of our most valuable assets is how humble and close we are, how we are open to learn, and our pragmatic approach to solve challenges.

 

We will be more than pleased to show you:

  • How any user can automate Appian testing without coding

  • How you can automate testing before the development is ready

  • How robust AAT tests are in front of Appian updates or project changes

  • How the whole team can collaborate in the testing and benefit from it

  • How can you you can reuse the existing tests you have in other platforms, like your Selenium tests

and much, much more!

 

 

Whether you are a techie, a director, an analyst, developer, a product owner or tester, if you are an Appian passionate, you’re welcome!

 

Related Articles

Image
Follow Us on...
CEITA LinkedIn
London, Barcelona, Madrid, Jaipur
© 2023 CEITA SL. All rights reserved
Save
Cookies user preferences
We use cookies to ensure you to get the best experience on our website. If you decline the use of cookies, this website may not function as expected.
Accept all
Decline all
Session Management
Adobe Experience Cloud
Used for debugging purposes in the Adobe Experience Cloud and contains information about debugging sessions.
Accept
Decline
Analytics
Tools used to analyze the data to measure the effectiveness of a website and to understand how it works.
Google Analytics
Accept
Decline