Tao DevOps

Let’s put our laptops aside and forget about Docker updates. Close your eyes and listen to the tale of DevOps culture, a story that occured in a pretty unusual place – in an airplane cockpit during a plane crash.

We will find out that, as with pretty much every new field today, DevOps appeared before the term ‘DevOps’ was coined. So why did this happen? Why does DevOps have such a profound effect on product quality and development effectiveness?

Let’s look at the DevOps phenomenon from the perspective of a test-focused developer and development-focused tester.
-Which tools are the most important in DevOps?
-What is DevOps at its core?
-What is Tao of DevOps and is it possible to find zen with it?

Clean Infrastructure: journey towards clean and testable Continuous Delivery pipeline - Clean Arch

Test engineers write a lot of code to support their testing activities. However, this code tends to be not very clean or testable itself. It creates lots of fraction and prevents Test engineers from doing their best.

While it may be relatively straightforward how Test Automation code can be done clean, tested and testable, Continuous Delivery code organization is less obvious.

Let's us hear the story about reimplementing a very complex and obscure Jenkins Continuous Delivery Pipeline code in a clean way and find what may be the general principles of making a Clean Infrastructure.

Test automation, Unicorns and other things that do not exist

10 years ago we were told that "Manual Testing" is going to go away. Now, Artificial Intelligence is going to make testers redundant "for certain". We all love and use automation and tools, yet, industry most prominent experts are certainly pushing back "rush for the total automation".

Lets try to sort things out - where those scepticism is coming from?

To understand that, we will have to imagine a driver of a "self-driving" car, a passenger of a plane with a broken "autopilot". And remember what Grandpa Turing told us about algorithms.

Workshop: Building an effective test automation

There're lots of "best practices" for test automation, like Test Pyramid, Page Object Model, Layered frameworks but still test automation initiatives fail to deliver expected results.

There're lots of test automation specialists, but yet, not everybody knows why test automation was launched on their project in the first place.

There're probably two extreme viewpoints on Test Automation - test automation as a way to assure quality and test automation as a way to drive development. Knowing that we're all living in a real-world with limited time and resources - can we imagine something in the middle?

Let's us go through 50 shades of test automation efficiency and learn to find our way towards our goal.

Takeaway:
-Decision-making framework to make sufficient (adequate) test coverage for top-to-bottom (from unit to UI) and bottom-to-top (from UI to unit) test automation.

-Understanding (on practice example) the effect that application architecture has on test automation and a way to increase test automation efficiency.

Alex's quest for quality

Quality remains a bit controversial topic. What is even more controversial, though, is the what testing has to do with the quality. Throughout my career, I was lucky (or not so lucky) to work as Tester, SDET and developer, and I may have very bad news for you.

Surprising, only after moving into Development role I was actually able to (efficiently) improve the quality of the product. There were quite a few lessons learned, and some scientific research performed.

I would like to share my experience and findings and suggest what it may mean for Testers and the industry in general.

Takeaways:
1) Development team, approach and techniques are the main source of quality (or issues with quality) for a product
2) Holistic view on the product delivery and role of testing in it: Testing as a part of QA, which is a part of Risk Management, which is a part of...
3) Learning path to stay competitive in the world with the decreasing demand for testers

Test Automation Architecture

Usually, when people think about test automation they tend to think about test automation tools, such as Selenium, Cypress, or RestAssured. What is often missed is that tools themselves are of little value unless they are built into working, efficient, and maintainable test automation solutions.

In this report, we shall explore three proven test automation solution architecture patterns – each with its benefits and drawback.
We will see:
1) what factors can influence automation architecture choices and
2) if there’re any kind of universal patterns that can be used for different types of the product under test
3) what is Clean Architecture in relation to test automation solutions

Case for testing as an entry-level developer job

Amond the testers it is often said that the fact that testing is often considered as "an easy way to become an IT specialist" is very unfortunate. Testing is a demanding, challenging and interesting job. I even wrote a whole article suggesting that we should not allow testing to be an 'entry-level developer' job.

On the other hand, our industry has seen more than one successful example of people coming from non-CS backgrounds starting their career as testers and then, after some, moving into development. That was my own path as well.

Could it be the case that the idea is not that horrible itself? Could I possibly make a case for testing as an entry-level developer job?

In this talk we will explore:
1)Why it happens that many use testing as an entry-level job?
2) What drawback it has?
3) What are there any benefits for candidates, company and industry in general?

Why you will always struggle with those bloody UI tests (and why you should not)

We have to admit that despite all the effort by think-tanks in the software development industry we are still stuck with lots of UI (or other system-level test automation code). Even worse, we are making more and more sophisticated 'test automation' tooling and even proud of that!

But why it is so? There's something that testers should know about development. One little secret - software CAN be testable. Only by our ignorance we tolerate untestable software, making the whole `test automation` industry possible.

Care about challenging status quo? Then join this session, where I will demystify `the development` magic and will show you how exactly the same application can be testable and untestable - and what implications it has on testing.

TDD: The Good, The Bad and The Ugly

TDD was introduced a while ago, but yet there's no uniform opinion about if it is a useful tool or fancy stuff to brag on.

To make things even worse, there're more than one flavours of TDD: inside-out, outside-in, classicist, mockiest, twitter/ruby-style of TDD...

Let's have a look at the history of TDD, what different schools of TDD are about and what is the modern state of TDD.

Keywords: TDD, BDD, Agile, Refactoring