Cucumber driven testing of Microsoft SharePoint

[Henry Dittmer]

I'm a very novice Cucumber user who has a client that is building SharePoint applications and business processes.
I'm hopeful that they might use Cucumber for automation testing.  However, before we invest too much I was wondering if anyone has had experience that we could leverage?

Thanks
Henry C. Dittmer

[Oscar Rieken]

On Thu, Feb 12, 2015 at 12:17 PM, Henry Dittmer <he...@swiftascent.com> wrote:

I'm a very novice Cucumber user who has a client that is building SharePoint applications and business processes.
I'm hopeful that they might use Cucumber for automation testing. 

https://cukes.info/blog/2014/03/03/the-worlds-most-misunderstood-collaboration-tool.html

 

However, before we invest too much I was wondering if anyone has had experience that we could leverage?

Thanks
Henry C. Dittmer

--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Selenium Framework]

I have couple of thoughts on this and these are NOT answers, but my own struggles and what worked for me.

1) All those testing jargon we hear (the list is bigger than the link you shared) - It really depends on the scope of how much we want to test to feel assured and confident to release code to production. The scope "can" be infinite at times, however we are always pressed by time and deadlines, so we have to choose "what is most valuable testing"

2) And the most valuable testing is generally the ones that "matter to customer" (Of course back tracking and getting into details would eventually lead us all kinds of testing again) --- However in many firms there is far too much emphasis on testing for the "sake of testing" , rather than focusing on testing the "acceptance criteria"

3) So Cucumber helps all the roles/team members to focus energies on aligning with "what is most important" -- So as long as we stick to the team (3 amigos) agreeing on "what" to test in the cycles/sprints we have --- We derived a lot of benefit out of Cucumber

4) On the other hand, if we go into too much on the "how" part  (which tools , what languages, what patterns etc.) -- aka. software design, best practices and so on -- we might be losing the benefits of what Cucumber is supposed to do -- Hence the testing pyramid (Search for Matthew Wynne talks on how Cucumber should can touch all the layers in the testing pyramid)

5) Cucumber is a collaborative tool/framework -- NOT an awesome killer technology/tool/library that helps us do all kinds of testing (verification/validation etc) -- So we should look at Cucumber as helping us bring together different stakeholders on same page [Business Analysts, product owners, developers, testers et al.]. The instant we start seeing Cucumber as a ubiquitous technology than solves all inter-operability issues among all stacks [Java, Js, C#, Ruby..zillion others] ,we might be missing the real purpose.

Coming back to specifics to your question..

Cucumber was only the front layer -- the back n-layers of code that I have used and that touches various aspects of application are -- GUI using selenium, API's using rest&soap clients, message queues using apache mq for eg, mainframes using clients like terminal emulators, databases using whatever client libraries were provided by the libraries that existed in those stacks (Java, Ruby, C#, Js ....)

So we had two major purposes that Cucumber helped.

• A common page for product owners, ba's and developers/programmers by describing acceptance criteria --- Business facing scenarios (Working pretty well)
  
• Technical facing scenarios -- All those actual code behind's that only programmers can decipher (apis, mq's...)

We are dealing with figuring out ways to reduce complexity on the technical facing scenarios -- as they constantly evolve and it gets really difficult to have "declarative" style of Cucumber on these technical facing scenarios -- though we are trying to keep it simple and push the "how" complexities as low as possible down the stack [in the layers behind Cucumber]

Personally, I did NOT find a huge value add by using Cucumber to drive the unit tests, because only the developers in the team knew how those worked , product owners or testers hardly cared about those tests, so asking them to collaborate on this was probably not working for us especially when we had more pressing and valuable things like acceptance tests - though we initially started using Cucumber to touch all layers in the application. 

Overall, though we started boiling the ocean (aka. application layers) using Cucumber everywhere we can -- We are starting to realize that we need to address the Testing pyramid (http://www.seleniumframework.com/decision-models/choose-automation-solution-2/) by writing good tests at each layer. Those tests "if" mattered to all the 3 amigos, then use Cucumber, if they do NOT matter (for whatever reasons - time, money, skills, culture) , we are letting the experts (mostly developers) choose whatever works.

At this point in time, we write acceptance tests (the ones that matter to business stake holders, product owners) in Cucumber , the rest of tests that involve more technical details -- we are sticking to tools that the team had skills in or what they agreed upon after internal debates and discussions.

My 2 cents.

cheers,

www.seleniumframework.com