Software Testing Videos and Tutorials: Load Testing, Unit Testing, Functional Testing, Performance Testing, Agile Testing, DevOps
One of the problems we face in automated system testing is how to setup and manage the life cycle of the included applications. Traditional virtualisation technologies can provide solutions to these problems, but at the price of heavy resources requirements and unacceptably long startup times. Docker on the other hand, with lower resource requirements and shorter application startup times, has seen a lot of interest lately for looking like a better fit for automated system testing.
Your application is a unique snowflake. Your software tests are too… but they shouldn’t be! Years helping teams write better tests has taught me one thing: consistency is crucial. Inconsistent tests slow teams down, wasting time to understand how each test works.
Software development and deployment contexts have changed considerably over the last decade with Agile approaches. Performance testing has had difficulty keeping up with modern testing principles and software development and continuous deployment processes.
The software industry is changing fast. Many of the companies software testers work for have to re-adjust their working patterns, release cycles and project approaches in response to this change. It’s never been more important to remain relevant to the company you work for. Yet a surprising number of people are ignoring the needs of the business they work for, clinging to outdated approaches to work and running away from change.
10 years ago, Dan North first came up with the idea of Behaviour-Driven Development (BDD): using examples in conversation to explore the behavior of systems, then carrying those examples into code. Since then, we have learned a lot about how BDD works, how it works best, and how it can fail horribly! Even the most experienced BDD practitioners have learned a lot from their failures… but what were they? And how are we failing now?
At a first glance you might relate software testing in an Agile context to abbreviations like TDD, BDD, ATDD. Though these are often valuable practices they are closer related to checking of the software. The point is to run them often and to help developer to know when to stop coding.
An important responsibility for many software architects is fostering and defending non-functional software qualities. These qualities are numerous, and they can interact in complex ways, so techniques for keeping abreast of them are vital for gauging the health of an architecture.
