The world of a software house is a constant search for compromise between quality and costs. In many cases, the cost-cutting starts from the test automation. Then you start to talk about ROI but recognize that numbers are not on your side. We were there and what we have found out is that only a complete change in our approach allows us to find common ground with our clients. I will reveal one detail from the presentation - we are not talking about test automation with clients anymore - as a result we do it more and more.​

Are you surprised that success automatically generates new challenges which we further translate into opportunities? We had to reconsider our approach to the test automation environment, internal frameworks and the way we share them between projects, including code ownership, … And again, one simple but unobvious solution allows us to both deliver what we promise and to earn more on our projects.​

As we have been reshaping our approach to the test automation, we had to change the way of delivery too. One of the main decisions was skip out the role of test automation engineer (or software developer in test). We decided to go with the whole team approach which is consistent with the way we sell it. ​

Find it interesting? Join me and listen to our story about how we have transformed test automation.

 
 

Outline/Structure of the Case Study

Presentation is divided on four areas:

- Introduction to the world of projects (the world of Software Houses)

- How Cognifide has changed approach to selling test automation

- Why reusing internal frameworks is not easy / great idea (from internal and client point of view) and how to solve it

- How responsibility of delivery test automation changes in recent years

Learning Outcome

  1. You will explore the world of software houses​
  2. How to talk about test automation in the business context without using ROI, test coverage, …​
  3. How to increase project’s revenue in an unobvious way​
  4. How to implement a whole team approach and be lean without creating fixed roles in the project team

Target Audience

Presentation is addressed to everyone who is interested in how to talk about test automation with business, work at Software Houses and would like to know how to reuse test automation frameworks, or supporting sales processes

Prerequisites for Attendees

none specific but should know that test automation is more complicated than just coding.

schedule Submitted 7 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • Robin Gupta
    By Robin Gupta  ~  6 months ago
    reply Reply

    The proposal does not bring out a singular problem statement, solution and implementation plan and there is a disconnect between the title, abstract, outline/structure and learning outcome. 

    Also, can you please add the below aspects to the presentation?

     1. A general time division of the presentation
     2. While the current content fairly describes the problem statement/solution, adding technical details such as architectural diagrams, code snippets, tools or github repo can help the audience with implementation of the framework.
     3. A short video of the presentation done earlier, or a similar presentation
     4. Challenges/Work arounds of the approach followed here
     

    • Zbyszek Mockun
      By Zbyszek Mockun  ~  5 months ago
      reply Reply

      Hi Robin,

      Thank you for the feedback. Below answers for each of your points

      1. A general time division of the presentation

      • -  Introduction to the world of projects - about 5 minutes, as it's important to know the context and not everyone is aware of what is behind the scene 
      • - Selling the test automation, 5 minutes of history why it is difficult to sell test automation as part of the project (again, a little of context especially to people who knows only product base companies)
      • - 20 minutes (Framework /tools reusability) -it's the main presentation point. It's where we are going to talk about issues that technical people mostly do not interest in, but they are very important aspects of test automation. And of course, we will have a chance to look at open sourcing from different aspects - not just a technical one.
      • - 5 minutes about the whole team approach - so how to deliver test automation together with developers not by creating an additional bottleneck by hiring test automaton engineers - so few things about implementing a whole team approach to delivery.

      2. I am talking here about approaches and decision making, not about specific tools. our experience is based on open sourcing three tools, I can add links, of course, logos, ... but how to open source with tools /frameworks can be another presentation.

      3. Links to presentations:

      - above presentation from SQA Days - https://vimeo.com/ondemand/sqadays26/378110017 (unfortunately the conference owner publish presentation for microtransactions)

      - a quite old presentation: https://www.youtube.com/watch?v=2IIpuOh-wGk

      4. Challanges

      - all on slides, especially in chapter 2 and 3 of my presentation