Александров Александр Леонидович
TestOps - a tribute to fashion or ...
It is difficult today to find a QA engineer who hasn't heard the expression “TestOps”. But have you ever wondered what exactly “TestOps” means? Is this a position? Is this an approach to organizing the work of testing? Is it philosophy? About this, and not only, we will talk to the participants of the round table.
Requirements - why are they? Requirements Consumer Perspective
The features of checking the testability of requirements are considered. The possibility and expediency of testing without test cases and/or without testers is analysed. The features of requirements and testing in maintenance projects are investigated. The importance of managing requirements and testing with changes is emphasized. Risks of testing due to the requirements are listed.
Testers: Automation ↔ Hiring ↔ Training
Demand and supply in the testing market are considered and analysed. The current and prospective place of automation among all testing activities is investigated. Actions are proposed to bridge the gap between the current state of affairs and the desired requirements for testing processes and resources.
The way we test changes at breakneck speed - every few years, there are new tools, new techniques, and new buzzwords. Over the course of several decades, software testing has seen many effective practices and patterns.
Unfortunately, there are also practices or (anti)patterns that have more bad consequences than good ones despite initially appearing to be an appropriate and effective response to a problem.
Martin Fowler defines an antipattern as ”a solution that initially looks like an attractive road lined with flowers… but further on leads you into a maze filled with monsters.”
In this talk, we will share some antipatterns that we believe negatively impacted the testing community in the past - and what we are learning from those experiences.
ISTQB, training, free cheese - what's next?
Analysis of the approach to preparing for ISTQB certification in one company. Illustration for free cheese.
Dunning-Krueger effect in testing
The talk addresses the following issues:
- What the Dunning-Krueger effect is.
- Test manager responsibility area.
- Typical misconceptions about test automation.
- The modern needs for testing and testers.
- Do we need testing at all?
- Where else the Dunning-Krueger effect is manifested.
These issues are analyzed in detail and resolved using examples from the authors' professional activities.
The talk consists of two sections.
Section #1 explains testing economy approaches discussed at SQA Days-24 and SQA Days-25 conferences. The connection of this topic with the test efforts estimations, testing risks and priorities and "quality cost" concept is shown. The linearity of the technological point of view on testing and increasing the testing flexibility using attracting the economic realities is provided. The extended cases illustrated the differences between versions 1.0 and 2.0 of the testing economy are demonstrated. Focused attention that version 2.0 appears only when version 1.0 is already available, but we decide to work efficiently rather than a plan and estimations.
Section #2 is devoted to methods of obtaining testing knowledge and skills. Explaining the updated concept of Luxoft training centre, training needs, scope and process are considered as well as process audits services and other Luxoft training centre advantages.
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.
Economics of Software Testing. Version 1.0
It is well known that exhaustive software testing is impossible. However, there are statements about testing completion, although testing can’t be completed, and acceptance testing criteria are economic, rather technological. So testing differs from, for example, development.
The message consider in detail Version 1.0, the main activities are:
- We build restrictions and plan activities
- We estimate the labour costs for testing
- We justify the assessment, show its realism and effectiveness
- We work in accordance with the plan and evaluation
The message also briefly describes main Version 2.0 features - use reasonable work effort effectively by analysing:
- What test cases are needed (and whether they are needed)
- What test data are needed
- What testers are needed - little strong (but expensive) or many weak (but inexpensive)
- What kind of automation (and if at all) is needed, tools, coverage
Investments in labour costs are still returning (ROI), but the goal is efficiency (maximum of benefits)
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?
Current State vs. Common Sense
In 1997, Brian Marick wrote "The classical testing mistakes".
In 2009, I conducted an analysis of the state of the mistakes.
The trend seemed encouraging.
Now I have decided to do the same, based on my messagen on SQA Days conferences.
I decided to collect all and understand current trend of topics proposed by myself on the conferences and undersand today's progress of testing as the engineering discipline.