To work successfully, a tester needs to go beyond the narrow task of checking software functions. A tester needs to imagine the usage of this software and its place in the activity, integration into the business level. And for checking the stability and performance — understand the hardware level. Finally, a tester must be skilled in designing a comprehensive suite of test cases that guarantees the software’s quality.

All these tasks need the ability to understand and build various models and ways to interface them with each other. A powerful tool that ensures such work is systems thinking. It is clear that it is impossible to talk about it in one talk, but my story will give an overview, and, more importantly, highlight the importance of systems thinking in the work of a tester. And, I hope, it will give impetus to a more in-depth study.

An analyst often needs to quickly understand people's thinking and emotions, and do it quickly. For example, you offer a solution to a customer, and, in response, you receive an emotional reaction from those you have seen for the first time. Or when the team refuses to accept the customer’s next requirements. Soft skill models help with this: they allow you to understand how other people, who may not be like you, think and act. Models also help you look at yourself from the outside and evaluate your potential for development. The benefits of models are the same as the benefits of knowing design patterns: you can work without them, but with them, you can work faster and more effective, although inappropriate use can be harmful.

There are many models, and I have managed to create a comprehensive model that integrates psychology and neurophysiology. And in the talk, I will demonstrate its application in specific cases.

It is necessary to understand and effectively communicate with team members, stakeholders, users and related teams for productive collaboration. Many soft skill models can help: they allow you to understand how other people, who are not like you, think and act, and show diversity. Other models describe team dynamics and leadership styles. 

Systems thinking is a powerful tool for building models of the real world and designing its changes. I talked about it and the underlying rational thinking at the autumn Analyst Days. But are such powerful general tools really necessary for analysts and architects in their daily work? Perhaps simpler techniques are sufficient: highlighting the glossary of the domain area, mindmap for structuring, bpmn for processes, c4 model and Archimate for the architecture of the IT landscape, OOP for building data structures, user story and use case for describing the users' activity, DDD and Event storming for complex domains? All of them are designed for IT and work successfully. 

My experience is that applied methods are good and correct, but without the support of systems thinking, their formal application leads to design errors. In the talk, I will focus on points in the project where mastery of systems thinking is essential and will show how applied methods rely on it.

The modern world assumes you actively define your path rather than follow the standard career ladder. To successfully self-determine, you need to be able to address various questions:

• How do you determine whether to move forward or stay in your current position?
• How can you envision different development options and choose among them?
• How do you distinguish between the challenges of learning and exhaustion when pursuing something not your own? 
• How do you know when it's time to take a vacation to prevent burnout or focus on your family?

Answers to such questions are not taught in school or university; you must learn them independently. I will share some frameworks that enable you to think systematically about all of this and make decisions.

This is not my first talk on this topic; previous ones are on my website. However, in preparation, I discussed current issues with the Program Committee that testers often encounter, and the focus of the talk will be on them.

The essential skill of an analyst is to identify objects and their relationships and determine the types and workflows of documents – in general, to build models. This should be done during interviews, analyzing documents and Excel files. Typically, object-oriented approach is used for this purpose. OOA is a specific instance of systemic thinking methods based on rationality. They teach how to structure information about the world: to mark up texts and other narratives to build models by considering the world as a collection of interacting systems. Understanding these thinking methods provides a powerful apparatus for analysts to solve complex problems. This is analogous to integration methods: there are specific approaches for particular integrals, and there are general approaches.

In the presentation, we will discuss applying rational and systemic thinking methods for solving analytical tasks. 

There is an idea that systems should at first be described as a black box, and requirements engineering is devoted to ways of such description. Goal: if we check the system for compliance with the requirements, we guarantee that the system is adequate for business needs. But it doesn't work that way. So, it makes no sense to go too deep into the requirements, but you should quickly start to make models or use easy formats for requirements. 

I'll review different approaches to writing statements: procedural and object approaches, DDD, use case, user story and others.

The modern world assumes that a human seeks an image of his future and independently builds a path to it. Standard career ladders are irrelevant, the rapid development of technology requires changing specializations and mastering new things. And, unlike in the past, work becomes not just a source of income, but also an activity of professional development, which gives drive, self-realization, energy, and happiness. A person should be active, serve as a driver of his own changes and make choices rather than handing over control of his life to others. The events of this spring have greatly raised the urgency of the topic, including the solution of internal conflicts of value: geopolitics has begun to influence professional self-determination much more actively. 

In the talk, there will be approaches and schemes that allow technologically solving the problems of building an image of the future and your trajectory of movement.

We all realise that changing a task status only reflects the actual activities of the person who performed the task: writing staging or code, running test cases, or doing something else. And we never reduce the status change to simply moving the task to another column. But when the analyst thinks, for instance, about the work with the order, the actual activity is left out of his/her mind, and he/she thinks only about the work with the system. As a result, solutions are created that are not suitable for real life, although formally, the system has all the necessary features. 

The talk will consider examples of such problematic situations. It will show how changing the status of documents reflects the task flow just like the familiar task flow on the board, including the decomposition of a large task into several tasks and bundling tasks into release packages.

The modern world assumes that a person is looking for an image of his future and way to it. Standard career ladders are not relevant, the technology renovation demand to change specializations and learning. Unlike in the past, a job becomes not just a source of money, but also a professional activity that provides drive, self-realization, energy and happiness. A person himself must be active, serve as a driver of his own changes and make a choice, and not give control of his life to others: then you will get happiness and drive only with luck. 

The talk includes approaches and schemes that allow technologically solving the problems of building an image of the future and its own trajectory. Previous versions of the report "How to build your professional path" https://mtsepkov.org/SelfDet2 focused on building a path to the image of the future, this one is expanded with approaches to building such an image of the future, which will give meaning to life, drive, self-realization and energy.

Our experts Maksim Tsepkov, Grigory Pechenkin, Alexander Baikin and Dmitry Bezugly will answer your questions.

There were several cultures of developing software projects. Each of them generate not only its own methods of project management but also its own ways of maintaining requirements and designing software. Programming paradigms changed: OOP came to replace the procedural approach, DDD appeared, and later the focus shifted to interfaces, usability and UX. 

The architecture of the application also changed: first, they switched from client-server to three-tier, then the desktop client was replaced by the web with the concepts of MVC, MVVM and many others, then mobile applications appeared, reactive programming approaches appear, the application consists of many services, and the user switches between devices. All this required new approaches to design, new books appeared on the implementation of new concepts, while the old ones remained relevant. 

The talk will be devoted to the logic of the development of methods and actual modern design problems that has no books and courses yet.

At last SQA Days, I told about a model that effectively represents a modern application consisting of an integrated set of services exchanging messages and calling each other (https://mtsepkov.org/Multyparadigm-SQA). This model allows you to design scenarios for checking asynchronously communicating services, including checking complex cases to ensure application resilience under various failures. 

The talk will continue with a workshop in which the model's application will be explored using specific cases from the participants. Those whose cases are reviewed will get solution ideas, while others will see the model's practice, evaluate it and think about applying it to their work.

At last Analyst Days, I talked about a model that effectively represents a modern application consisting of an integrated set of services exchanging messages and calling each other (https://mtsepkov.org/Multyparadigm-AD). Such a model is consistent with the code and allows you to design changes as the application evolves and measures them against the complexity of the model's changes. 

The talk will continue with a workshop in which the model's application will be explored through specific cases of the participants. Those whose cases are taken apart will receive ideas for solutions, while others will see the practice of working with the model, evaluating it, and thinking about applying it in their own work.

For a long time, most applications were developed as large monoliths or systems of large modules, in which the processing of user requests could be represented as a procedure. And for testing, it was enough to check the application response for the user and the changes in the database. Based on this model, you can write test cases or checklists. 

Today we see in use microservice architecture or the actor model with asynchronic messages, that can be lost during transmission or double operated and produce various complex effects. In this case, the classic application model is no longer sufficient for developing application testing - it does not provide an idea of ​​the problems that arise. Other models are needed that are adequate to the applied programming paradigms, based on which it is possible to develop scripts for checking complex cases that ensure the stable operation of the application in complex situations. Such models will be discussed in my talk.

During a long time, the main development approach was OOP. In this case, the construction of the object model of the subject area in the form of structures of references and documents and business logic in each object is a suitable design method for the analyst, and the developer easily transfer it to the code and the developer can change the model during realization if choose different way. Therefore, the model reflects the code, and complexity of model changes due to new requirements allow to evaluate the cost of development. However, other paradigms for the implementation of high-load applications, such as microservice architecture or the actor model, are becoming quite popular. In this case, analysts need different methods to describe the requirements and domain model, that they are adequate to the programming paradigms. I talk about some of them in my speech.

On the one hand, the Requirements Specification cannot die. The specification of requirements is a direct expression of the essence of a systematic approach and thinking. The more complex the system, the more accuracy and care required when making any changes. And the created systems do not become easier... 

On the other hand, the Facts are a stubborn thing - honest process/architectural work with a cascade of formed specifications, classic As-Is To-be transitions come across much less often, from start-ups unicorns are born, and certainly there weren't any specifications in them... 

We invite you to a discussion at the round table: 

• Influence of two paradigms on Business and System Analysis: design and product. 
• How to move from one paradigma to another with minimal personal and organizational losses.
  

When designing complex enterprise applications, it is effective to use models that describe the subject area and the application itself in accordance with the Domain Driven Design approach. At the same time, good visualization is an indispensable attribute of the model. We will exchange experience in building an application architecture using three main models: a domain model, represented by a class diagram, a resource movement model, represented by accounting diagrams, and a workflow model based on a state diagram. All this is complemented by a business process model based on the activity diagram (activity diagram) and combined by the Archimate enterprise architecture model, and complemented by a system metaphor when it comes up to be invented. We will show examples of diagrams from real projects.

Analysts work between the cultures of customers and the dev team. Even in one company, the cultures in divisions often vary dramatically. Analysts must have the competence to recognise the culture of users and customers quickly and align to it because the culture sets an implicit context and defines the meanings of concepts. Later they should transfer the meanings and implications to the development team based on their culture. Also, the sensation of the culture is significant during the maintenance of software to provide joint activities of people of different cultures.

For fast and effective operations in various cultures, we can’t explore the corporate culture of a company or a division separately. We need to have cultural models in our kit. I'll talk about the spiral dynamics model that describes and operates with the values and culture of people and organisations. This talk continues and develops my lectures and articles about it, with a focus on the activities of the analysts.

Clients often accompany their request for new features with an idea of what exactly it is necessary to develop. Performers, in their turn, embark on designing the features required immediately, without finding out what problems they are supposed to solve. As a result, the solution developed does not meet the client’s expectations, and this may be due to several reasons. First, the customer’s idea may not be relevant to his situation initially. Secondly, the solution may turn out to be wrong because of the details of the implementation. Thirdly, it happens that the task can be accomplished faster and easier. For this reason, the analyst should define the client’s problems as early as on the first stage of the project.

My presentation demonstrates how it can be done and provides the examples of how the immersion into the business plan of the project changes the ways of solving the problem.

One of the tester's tasks is to look on the system through the helpdesk's eyes, to check whether the interfaces of the system can effectively resolve incidents according to SLA. Good resolution of the incident is not only to localize the error in the system, but also to help the user solve his business problem, find a workaround "here and now." Even in the case, then the cause of the problem is situated in the another system. Experience shows that this is often a weak point and requires the involvement of developers to directly analyze the data and correct it directly in the database.

Based on my experience, I will tell you what functions are useful in the system for the effective resolution of incidents of inter-system integration, as well as incidents related to processing of special business situations and deals not provided for in the system. I think the story will help listeners look at their system in terms of compliance with the SLA.

Quite regularly you hear questions like the following: "We have a Scrum project, I need to write test cases for the testers, and I do not understand where I get information from." When you start to discuss, it turns out often that the word "Scrum" in the project they know some original design, while the inquirer is precisely sure that this is exactly Scrum. Meanwhile, Scrum and other Agile methods are a normalized model, about which you can read the documents, and from which you can get answers to this and other questions. But I will not provide the documents. I will show how to think in the logic of Agile mindset, get answers to this and other issues. Of course, as long as such values of the Agile Manifesto as working software, cooperation with customers and others do not seem to be a mere sound. I will show everything on real cases from listeners, solving their problems.

Later...

The problem of self-determination, planning and building own future becomes more and more actual nowadays, comparing to the past, when you determine only ~2 times, when define your profession and create your family, and moreover, this was pre-defined by your family. 

Today you should do that regularly, moreover - in fast changing world, we see that especially in the IT-world, when technologies change rapidly.

I've built and prepared a bunch of schemes helping to do that. I'll tell about them in my talk, and then I'm ready to solve your cases in the bar camp format. 

Methods of design and requirements processing should ensure effective communication between team members and provide agile development of software with the possibility of further modernization. In the course of evolution, IT has accumulated a rich set of practices for projects with different complexity, scale and purpose: user story, use case, BDD, TDD, FDD, DDD, architectural work in SAF, and more traditional approaches. As it always happens with a wide range of tools, the problem of choice appears. Well-known tools or methods' comparision on model tasks are mostly preferred. But what's good for small tasks, not always suits long project.

The report provides an overview of various practices that help to solve communication problems and the conceivable models of labour division within the team. The presentation also considers approaches to support the product development and modernization on a long life cycle. This report develops the ideas of my "Agile Engineering practices" post.

Many QA professionals are convinced that IT industry has perfect vision of the quality and the means of its achievement. Therefore, the situation, when you switch to another company this ideal appears to be different, most values are being challenged, and common ways of working are very distinguishing, becomes an unexpected shock.

The fact is that understanding of the quality criteria in IT-projects has come a long way from orientation to the perfect engineering product to meeting the steak-holders’ interests and providing prospects for business. Currently the awareness appears that different projects require different quality, and its criteria vary during the project.

The report considers the space of quality criteria description and shared responsibility in the projects, which are to be examined for detailed examples.

The speech develops my preceding reports (http://mtsepkov.org) about the evolution of quality criteria (AgileDays-2015) and sharing responsibilities (AnalystDays-2015).

An analyst starts his work with building a hierarchical structure of terms, where all clears and understandable for all stakeholders. This is a scientific mindset. However, there is an alternative - a tag cloud of concepts with associative chains. Therefore, thinks the child, when still cannot create logical structures. Previously we believed that a professional’s mindset should be based on hierarchical structure, but now comes the understanding that second mindset also works effectively: marketing, political technologies and media follows by this way.

There was even a special word – folksonomy – contrary to the taxonomy for logical classification. Imagine that you describe a clear hierarchical architecture to a colleague and it seems he knows all the words. Only in his head instead of taxonomies - cloud folksonomy in which your design will fall quite differently.

The analyst must be able to work with it, and in the talk, I will give a few methods based on schemes of SMD-methodology.

Division of responsibilities in software development process is one of the most popular topics for discussions and chats. Participants are usually confident about other persons' misunderstanding of their responsibilities, although the issue of responsibilities division is certainly known. However, there's no the only true division of responsibilities in software development, because the boundaries depend on certain project aspects and special kinds of performed work: analysis, design, development, testing. The presentation considers schemes of management and shared responsibility in software development: responsibilities and roles in the development team, division of responsibilities from the Company and the Customer and different stakeholders on the Customer's side. We are to discuss the origination of some schemes of shared responsibility, kinds of project characteristics, which affect design of project roles and those effects, which cause slack in different places of these schemes.

Last autumn my range of vision was extended by such model as Spiral Dynamics. It gave me systematic viewpoint of many trends such as community development or IT (as well as not IT) management.

I spoke about the Spiral Dynamics itself on Agile Days conference. Here I’m going to explain how it influences on understanding of processes used in the company, in the industry and in the world in general. Also I'll unfold how it might give you knowledge about how you can find proper place in these processes and how to make decisions more wilfully.

I’m going to do it from Software Test Engineer point of view. Precisely from Software Test Engineer who is going to grow into Manager. I’ll consider some important questions and provide Spiral Dynamic’s answers on them.

Division of responsibilities in software development process is one of the most popular topics for discussions and chats. Participants are usually confident about other persons' misunderstanding of their responsibilities, although the issue of responsibilities division is certainly known. However, there's no the only true division of responsibilities in software development, because the boundaries depend on certain project aspects and special kinds of performed work: analysis, design, development, testing. The presentation considers schemes of management and shared responsibility in software development: responsibilities and roles in the development team, division of responsibilities from the Company and the Customer and different stakeholders on the Customer's side. We are to discuss the origination of some schemes of shared responsibility, kinds of project characteristics, which affect design of project roles and those effects, which cause slack in different places of these schemes.

There are many methods to develop requirements (user story, use case and so on), but all of them mainly describe behavioural aspects. But how to work in the sphere of complex business requirements where objects change their behaviour as the context may admit? Domain-Driven Design (DDD) is an approach that allows to create clear and clean vision of domain area. Ubiquitous language gives ground for communication between customers, analytics, developers, testers and end-users. And we can use models developed in this language instead of traditional requirements, which are used only to build models in this process, and then they lost their actuality. This approach significantly simplifies design process and reduces risks in complex IT-projects enabling business professionals to fully verify Models. And then, while in operation, Models allow to develop and expand software system efficiently for many years following changes of customer’s business processes.

Who among of us has not faced with a situation when customer requirements were implemented thus he did not required at all? Hence, the implementation were changed many times, unless excluded. In the report we will talk about establishing that kind of relationships with customer when main goal is to solve customer problems and not just to working out requirements. This report is not about “how to live”, it based on real (!) cases that was arising in relationships with customer. We would like propose a method establishing relations, analyze the combination of formal and informal communication, as well as deal with labor costs and payment issues. We also will consider the psychological side on different project phases. There is no way without that, because teamwork assumes no formal interaction, but communication and collaboration, with establishing partnerships for produce the value. As a result, this approach leads to mutual success and improving realization of the potentials of you and your team.