BOOK: Software Testing Foundations, 4th Edition: A Study Guide for the Certified Tester Exam (Rocky Nook Computing): Andreas Spillner, Tilo Linz, Hans Schaefer: 9781937538422: Amazon.com: Books

A book about SW testing according to the International Software Testing Qualifications Board (ISTQB):

Software Testing Foundations, 4th Edition: A Study Guide for the Certified Tester Exam (Rocky Nook Computing): Andreas Spillner, Tilo Linz, Hans Schaefer: 9781937538422: Amazon.com: Books

Quoting:
"Professional testing of software is an essential task that requires a profound knowledge of testing techniques. The International Software Testing Qualifications Board (ISTQB) has developed a universally accepted, international qualification scheme aimed at software and system testing professionals, and has created the Syllabi and Tests for the Certified Tester. Today about 300,000 people have taken the ISTQB certification exams. The authors of Software Testing Foundations, 4th Edition, are among the creators of the Certified Tester Syllabus and are currently active in the ISTQB. This thoroughly revised and updated fourth edition covers the "Foundations Level" (entry level) and teaches the most important methods of software testing. It is designed for self-study and provides the information necessary to pass the Certified Tester-Foundations Level exam, version 2011, as defined by the ISTQB. Also in this new edition, technical terms have been precisely stated according to the recently revised and updated ISTQB glossary."

Agile: Crystal Methods

Crystal is one Agile methodology born in the mid-90s and still used today in some railway projects:

Crystal Methods - Wikiversity


Quoting:

"Crystal methods are a family of methodologies (the Crystal family) that were developed by Alistair Cockburn in the mid-1990s. The methods come from years of study and interviews of teams by Cockburn. Cockburn’s research showed that the teams he interviewed did not follow the formal methodologies yet they still delivered successful projects. The Crystal family is Cockburn’s way of cataloguing what they did that made the projects successful.

Crystal methods are considered and described as “lightweight methodologies”. The use of the word Crystal comes from the gemstone where, in software terms, the faces are a different view on the “underlying core” of principles and values. The faces are a representation of techniques, tools, standards, and roles.

Methodology, techniques, and policies are differentiated between by Cockburn:

• Methodology - set of elements (e.g. practices, tools)
• Techniques - skill areas (e.g. developing use cases)
• Policies - dictate organizational musts

Crystal methods are focused on:

1. People
2. Interaction
3. Community
4. Skills
5. Talents
6. Communications

Cockburn says that Process, while important, should be considered after the above as a secondary focus. The idea behind the Crystal Methods is that the teams involved in developing software would typically have varied skill and talent sets and so the Process element isn’t a major factor.

Since teams can go about similar tasks in different ways, the Crystal family of methodologies are very tolerant to this which makes the Crystal family one of the easiest agile methodologies to apply.

In his research, Cockburn [1999], he defines behaviour of people in teams:

• “People are communicating beings, doing best face-to-face, in person, with real-time question and answer.”
• “People have trouble acting consistently over time.”
• “People are highly variable, varying from day to day and place to place.”
• “People generally want to be good citizens, are good at looking around, taking initiative, and doing ‘whatever is needed’ to get the project to work.”

The points above are why Crystal methods are so flexible and why they avoid strict and rigid processes typically found in older methodologies."

There are several variants of the method and the set of methodologies is sometimes called "Crystal xx". For more details follow the lin k above.  

SW Development: Error budgets?

Just sharing this article with thoughts about conflicts with Devs, Ops /DevOps and about error budgets:

DevOps = Dev + ErrorBudget + Ops - Expedia Group Technology - Medium

Quoting:
"It wasn't until I learned about Error Budgets that I
realized exactly how dev and ops could merge into an effective
"devops", and I've written about that in my latest article https://medium.com/expedia-group-tech/devops-dev-errorbudget-ops-9441e94ff698 "
(...)
"There’s a lovely description in chapter 3, Embracing Risk of Google’s Site Reliability Engineering book which I will quote here:

For example, if product development wants to skimp on testing or increase push velocity and SRE is resistant, the error budget guides the decision. When the budget is large, the product developers can take more risks. When the budget is nearly drained, the product developers themselves will push for more testing or slower push velocity, as they don’t want to risk using up the budget and stall their launch. In effect, the product development team becomes self-policing. They know the budget and can manage their own risk. (Of course, this outcome relies on an SRE team having the authority to actually stop launches if the SLO is broken.)"