Michael Bolton was in Cluj between 17-20 November as instructor for RST (Rapid Software Testing) and Critical Thinking courses. Before he continued his journey, Altom team stopped him for an interview to find out what some of his perspectives are on software testing and education in software testing, the link between testing and the scientific discovery process, as well as his opinion about testing communities and their role in potential revolutions in testing.

Like any other success story, when it comes to Performance Testing our story mixes people and processes altogether. Different companies might be built upon different cultures so they implement various mixtures of people and processes – versed teams that have dedicated performance testers might use only guidelines as a process while the more agile teams which rotate the performance tester role between team members, would probably need more detailed processes, checklists, so that the entire performance testing flow would be consistent from one sprint to another and the results offer the same level of confidence.

The use of version control has become the normal way of working while the latest version control tools enable us, the developers, to play with branches the way it suits us the most. Plenty was written about branching strategies and while some of them are very popular, almost all of them have a common problem that at some points must be handled. This is the merging problem. There is a reason why people are talking not only about their “branching strategy”, but about the “branching and merging strategy”.

Embedded systems use microcontrollers to perform the required actions according to the received inputs. The microcontroller offers (among others) I/O ports for interaction with the outside world and a CPU core to run the application program defined in the microcontroller software project. This project needs to include, besides the hardware dependent configuration, a task scheduler, code for peripheral control (drivers) and the actual application modules. The project can also include communication services, libraries and other components. In this article the focus is on scheduling algorithms starting from the super loop, state machine approach and, finally, OSEK/VDX schedulers.

Time is extremely important for the users, reason why we should care. On every project, we should ask ourselves the questions: “Do I save myself a few development hours at the expense of the user?” and “How could I improve the user experience?” People hate wasting time, especially online. We spend so much time online that even the smallest interactions take time. A small inconvenient doesn’t seem much, but more of them put together may lead to frustration and increase the probability for the users to give up using the service you are trying to provide.

Lately, as the web becomes more and more diversified, more and more designers having limited technological knowledge manage to build successful sites. From the beginning, we must admit that designers are totally dependent on the developers to bring their creations to life. On our own, most of us are able to create a static demo or a basic animation if we are lucky, but that doesn’t mean that’s all. Thus, we need a developer to translate our design into the code that any device would understand and execute anywhere in the world.

The web is responsive on its own ­ by default. It's us that's been breaking it all these years by placing content in fixed­width containers - Andy Hume.
While designing websites in a responsive manner is becoming a must lately, we should not forget that there is no universal correct solution for anything, and this also applies to web design. While it can be a massive advantage and attractive feature for the end­user, it can also prove to be a drawback if not used properly. In this presentation I propose taking a look at the DOs and DON’Ts of responsive web design: how it should be used, when it should be used, and most importantly: when it should be avoided.

As everybody knows, winter is a proper time for dreaming and hoping, a moment when dreams seem to be touchable. A moment when children and grown-ups write on paper or in their thoughts fictive or real letters to Santa Claus, hoping their dreams will become reality. This is catchy, as even the people behind OpenJDK expressed their wishes of java, on the first day of December, when they published an updated JEPs list. Hold on, don't get excited just yet...as we bitterly know, they might become reality somewhere in early 2016. Or, at least, this is the plan, and history has shown us what sticking to a plan means :).

Great success stories in businesses are often based on being first on the market, but they thrive by being able to outmanoeuvre the competition and adapt rapidly. The easiest domain that can be used to indicate different examples remains nowadays the technology world, where we can find different good and bad stories. “The first major social network, Friendster, was trumped by MySpace, which in turn was trumped by Facebook. Netscape was trumped by Yahoo!, which was then trumped by Google”. We all know that this is not the end and, somewhere, into a basement or a small garage, someone is building the next 'big thing' that can become the main actor on the market.

This article is the second related to Sun Tzu’s Art of War, and adds more arguments to my personal belief that the 2500 year military treatise is a guidebook for the nowadays role of Product Owner.