"Печень" Санкт-Петербургского сообщества тестировщиков.
Выражает себя через обеспечение качества ПО в компании T-Systems, российском подразделении Deutsche Telekom.
Разрушитель хрупких надежд разработчиков на то, что они пишут высококачественный код.
Economics of software testing, v.2.0
The continuation of Alexander Alexandrov's talk "Economics of software testing, v.2.0" where we will extend the field for discussions and discuss the issues of the economics of testing with the audience.
The main points of the talk:
- Exhaustive testing is not possible.
- Testing is as well an economic activity.
- Version 1.0, or What need to do. We work within a plan and evaluation, when a lack of resources, we ask to add them (extensive approach).
- Version 2.0, or How need to do. We work within a plan and assessment as efficiently as possible (intensive approach).
The round table will be devoted to the discussion on how to proceed to version 2.0, analysing the following tasks and using reasonable labour costs efficiently, analysing:
- What the test cases we need (do we really need them?).
- What the test data we need.
- What testers we need - a few strong ones (but expensive) or many of weak (but inexpensive).
- What kind of automation we need (do we need it at all), what tools, coverage.
Usually, when they speak of “Test ethics,” they mention very trivial cases.
We avoid reporting a bug.
We report that testing progress is as defined, even it is obvious, we are late.
Lie or tell the truth.
The answers are also easy to predict because the situations are represented in black-and-white colour. Of course, we report bugs. Of course, we don’t lie about our progress.
But life will present you with more complicated cases where the answer is not so obvious.
"Silo Effect" in development and testing
"Silo Effect", literally, "silage effect" or "silo tower syndrome", is difficult to translate into other languages literally.
In our circle we call this the "Silo Effect". The idea of which is that in the large systems (for various reasons) there are information barriers between different subsystems, both architectural (testing of different functional blocks) and structural (development and testing). These subsystems are separated by a barrier, as if "in a bunker", "in a tank" from the rest subsystems. Moreover, this has consequences for both sides because everyone has no access to information on the other side of the barrier.
In my talk, I want to talk about this effect for those who have not heard of it before and show how we can use it to make the interaction easier for those who know about the existence of this effect firsthand.
TEST-manager or test-MANAGER - solving incoming tasks
- Выполнять тестирование проекта с учетом специфики доменной области
- Обучить команду навыкам поиска, занесения и управления дефектами (defect management process)
- Обучить команду тест-дизайну
- Разработать тестовую стратегию основного продукта и независимых стримов продукта
- Провести оценку трудозатрат на тестирование
- Построить план-график работ по тестированию, распределять обязанности (включая бекапирование ключевых ресурсов)
- Мониторить выполнение работ по тестированию
- Готовить отчеты по активностям тестирования и качеству продукта
- Нанимать и обучать тестировщиков (в том числе и при дефиците ресурсов)
- Разрешать сложные ситуации(некачественный тест-дизайн, отклоненные дефекты, конфликты с другими экспертизами)
Round table discussion: TEST-manager or test-MANAGER?
There were many replies from listeners during the talk of Aleksandr Aleksandrov "Current State vs. Common sence" on SQA Days-20 in Minsk, like "Everything you talk is test manager's business", and there were a long after-speech discussion in lobby.
We have found out, that role of test managers is understood differently by all listeners.
During this round table, we are going to discuss mentioned problem and arise auditory, to get answers / thoughts / ideas / opinions for topics we propose to discuss.
- Could you learn to become test manager (and testing)?
- What would (and wouldn't) test manager do on the project?
- Can we work without test manager (and test management)?
- What would you do if project manager rules everything, and testers are not always agree with him?
- Does manager ought to "move away" from testing, and if ought to, how to understand, how much?
- Does manager ought to be "a barrier" for direct communication between testers and "outside world, and how much?
Using Combinatorial Testing for Mobile Apps
Is told a lot about combinatory testing.
At any time I can list reports related to this, sounded on the conference till past few years.
But what specifics need to apply it in when we're speaking about mobile applications? Usual problem of mobile systems testing - quantity of devices and a lot of configuration of the software which have to be checked. For example, so-called challenge of all mobile testing, the number of Android of devices, could compel testing team to check hundreds of devices and software configurations, having run thousands or even tens of thousands tests.
I will show how pairwase methods can be applied in testing, and, the main thing, I will tell about specifics of usage of combinatory testing for ensuring quality of mobile applications.
Requirements order: from chaos to FIFO
Many companies, working both with classical development methodologies and using Agile approaches, risks to get in a trap of the order during working with requirements. This is dangerous especially there, where is much more difficult - even not impossible - to plan the process of creating the specification or the final product due to increased variability of requirements focus that the customer can change daily.
I want to tell my experience of refusal from a flow generated by the customer on the basis of some of its priorities and the transition to the FIFO queue (First in - First Out).
Mobile APIs Testing: Behind The Scenes
“There is a special app for this”. This phrase can be heard today really often. It treats any site, a social network, even the quick mart with hot-dogs has the mobile application.
Data for these applications is provided by third-party web and API (Application Programming Interface) services - communication frameworks between backend systems and applications.
Testing of web services and APIs is more, than simply check of functions of application. API and services which call it, shall meet such requirements as response time, safety, stability, productivity and scalability.
In my talk I suggest to think about functional and not only functional testings of mobile APIs, to learn, than it differs from simply testing of API and with listeners to create the step by step test strategy.
EARS: The Easy Approach to Requirements Syntax
The key to an effective definition of functional requirements is the minimization of incorrect interpretations and ambiguity. Using consistent syntax in your requirements you can improve legibility, to be sure that every team member precisely understands what product needs to be developed. In my talk I will tell how to improve the creation of requirements using Easy Approach to Requirements Syntax (EARS). EARS is a simple and powerful method to obtain functional requirements. High-level requirements to a system are usually formulated in a natural language. Free formulations in a natural language can cause various problems of interpretation of the text and, as a result, influence quality of requirements. I'll suggest the simple manual which will help to write better requirements, will tell how we introduced EARS and what benefit from this we had received.
True story about SQL Server Change Data Capture testing
Recently the Change Data Capture technology gains popularity: about it writes on Habrababr, speaks at professional conferences for developers.
And if developers think about it, soon for us, testers, CDC will come to be tested on our projects .
In my talk I will tell what is Change Data Capture, what to look for at its testing and I will share information about the rake, which occurred and how to solve problems, that arise when working with the CDC.
Just a bit about the relations between analyst and tester
Analyst and tester. It seems, they are colleagues, whose tasks are densely bound, but, from the other hand, their relationship often is a place of the real battles which brings problems for team and for the project both. I will show a view from both barricades in my presentation will show how easy it can be if no barricades exists at all.