What most schools don't teach

Understanding of the testing in "modern agile world" - what's wrong with it

Initially I planned to write response to this article http://xpinjection.com/2013/01/31/stop-scrum-and-kanban (Russian) since my comments raised a discussion point. But I found that from start number of details for response grows endlessly and I need to stick to some really important things, so I will try to do that below.

First of all I will clarify my personal point of view:

• Agile is a great vision for development processes but it's not applicable everywhere, absence of understanding this leads to big problems in development;
• professionals prior to processes - we should have professionals that developing product using specific processes and tools, but not a processes and tools that uses people to develop a product (that's what agile manifesto is talking about - http://agilemanifesto.org, but it's not an agile only idea, we might be non-agile, but this principle should be used anyway);
• products should be always done with high quality and processes and tools should help to do that - if used process or using of proposed tools leads to lower quality of products we should cancel using of them;
• people should have ability to do things easier and faster - all things that makes process harder or slower should be eliminated or replaced with helpful stuff;
• any rule - is not a rule if it turns work into a stuck or a problems or leads to providing low quality products (especially for commercial software), dogmas are not a part of software development but professional knowledge and mission to get best quality are;
• cannot be agile and non-agile in a same time, if there real needs to change the process from non-agile to agile - old logic should go away
• context - it's what really drives development, development without relation to context and without understanding the purpose - completely wrong. Eventually - testing without counting on product context does not have any sense http://context-driven-testing.com.

So let's see what we have in development processes of commercial software now:

• market and business expects continuous delivery of new features, new products, new solutions - no time to stop and think what and how we doing
• agile and scrum became "trends" - everyone says it's good and everyone tries to apply agile processes for all IT development because see magic words "fast and continuous delivery of products" - result looks as http://www.halfarsedagilemanifesto.org = FAIL
• everyone trains how to communicate but mostly nobody trains how to work (Dan Kennedy raised this in his work "No B.S. Ruthless Management of People & Profits: No Holds Barred, Kick Butt, Take No Prisoners Guide to Really Getting Rich")
• outsourcing (even instead of outstaffing) is a rule, because better to have cheap and easy controlled people for "dirty" work, than good and enterprising but not-very-cheap and not-so-easy-controlled professionals. This is especially true for big and old companies with long history products in development.

That's not only problems but main ones. I won't say that they are everywhere, but this article is about projects (not even companies) when such problems are exist. Trying to be in a trend and to be agile people forgets that if we need to build something new and do that right we should break old and wrong stuff and sometimes even break or hardly change even that old things that looked right. I will try to describe those things (maybe it will look as some how-to and it's good if it's really will be how-to).

I did split for psychological/philosophical part and technical part.
And before you read next part of my article: please read 2 links with word "agile" above again incl. http://agilemanifesto.org/principles.html, http://manifesto.softwarecraftsmanship.org and read and try to understand article form SCRUM Alliance:
http://scrumalliance.org/articles/483-you-may-be-a-scrumbut

Psy and Phy:

• Agile - is not process or tool or business model, this is a vision how to deliver high quality products to users. Understanding of this should be first thing that should be done on all levels of product development: from marketing to last junior tester/developer that joined team right now. There will be no agile development if no agile vision applied on psychology level of each person involved to development.
• Now part of trend is to compare "agile vs waterfall", in terms of the people that advertising this - you could not be agile if your vision on things in development is completely waterfall-ed. I think that it's not completely true but in most cases it's correct - while switching to agile better to proceed with complete instead of partial movement because any "merge" error will lead to unrecoverable break of process.
• Agile - is not a magic stick, it just a vision that might or might not be used depends of what we want. But it won't work if it's unapplicable or we won't use it's key principles (it won't be Agile so).
• SCRUM (as an example and as a most popular trend within agile models) is not a process itself. It's a framework/model to build agile development process. It have limitations and should be applied with complete understanding about goals of product, it's context, expectations and it cannot be applied as a "tool only" or "management only" feature. SCRUM-based development should use all main model ideas and should be configured with involving whole team and not some parts.
• Not applicable if:
• one part of team to be "scrummed" and others are not
• management is "scrummed" but development is not
• programmers are "scrummed" and testers are not
• from team of 100 persons on all levels 99 are in scrum and even 1 is out
• ...and vice versa of course
• Agile processes and SCRUM model (as well as Kanban, XP, MSF4Agile and any other agile-oriented models) requires that all people be self-organized and professionals in their work. No exceptions. Of course - there will be more and less experienced people with different skills, but each of one should be professional, should understand what the product is, self-educate and understand what and why he/she doing that.
• I like to call agile models with term "predicable but flexible". Predictable - because we can estimate results and track what's happening, as a result - deliver working software with predicted and even predefined/expected quality. Flexible - because we expect to be available to work with dynamically changed situation and change things to match new requirements/expectations.  That's initially 2 of 4 main items of agile manifesto, but not understanding of them makes process unmanageable.
• Before SCRUM all the team needs to understand 2 things: 1) what is Agile, 2) what is SCRUM. Saying to people "now we SCRUM" without sure that they understand at least all the key principles of agile vision and selected model does not make things agile - it pushes things to butt.

Tech (I will talk mostly about testing here but not only):

• I used word "professionals" 4 times above and will repeat that again: no one should develop or test without understanding what to do. Functionality should not be developed without understanding goals of implementing it and proper design, testing should not be done without understanding expectations from working functionality and knowledge of functional details and design.
• Developers should not be just "coders" and testers should not be just "clickers". No details here - it's mandatory and it's a one of key things that makes process agile. We are non-agile if disagree.
• Testing should be started as earlier as possible. Testers (does not matter will we call them QA or not) should be involved starting from requirements analysis and even creation (again - depending of product context).
• Vision of expected behaviors of product should be the same between management and development (incl. testers). Communication must be organized in a way to reduce possibility of misunderstanding.
• Development and testing results should be easily accessible to each team member  in easy and fast way.
• Testing should proceed until release simultaneously before, with and after design of functionality and it's implementation (coding, integration).
• There is no manual or automation testing - that's the testing or coding and that are not definitely merged things.
• No test should be written without understanding the product and functionality details.
• Test cases and scripts are not the manual or rule - we might have no strictly defined tests but functionality should be tested well.
• Testers could or should use automation scripts and tools depending on context of testing needs. There could be manual only, automated only or mixed auto/manual testing depends from what we really need but not what someone decides.
• There could be non-automation testing artifacts and tools (for example, cases/scripts for manual passing) - they also should be created and used depending of context and real needs. For example:
• if tester see that test-cases not needed to test functionality well - he/she should not spend time for writing them
• if tester see that functional map or mind-map with be more effective to describe what to test - he/she should create it while testing. Example: http://www.bettertesting.co.uk/content/?p=956
• If tester see that writing test script/cases most effective - it also should be done.
• Any of such decisions should be made on initial planning process stages and testers should be involved to them.
• If tester see that some initial decision/plan was not effective - decision or plan should be changed.
• Automation team should be part of development even in non XP agile processes.
• Automation scripts writers should always work with development directly.
• Automation is a tool, not a solution.
• Automation code is a code - not just tests.
• Cases for manual runs should not be mixed with automated cases, but automated cases should have proper references to existent manual ones.
• Exploratory testing is not a strictly defined part of agile testing. It's an idea of creators of Context-driven school and it could be used if it's effective independently of process. When we planning exploratory testing we should not forget this map:
• James Bach described principles of exploratory testing and I should not add more, since he is one of creators :-) http://www.satisfice.com/articles/what_is_et.shtml
• Exploratory testing is trackable and well reported if well organized, it's really hard to be agile and deliver software fast without doing exploratory testing.
• Exploratory testing in most cases requires more understanding product (but not knowledge), testing types and methods than scripted testing but it's faster and in most cases it provides better results than scripted one.
• Testing team should work directly with programmers. When saying "development" we should mention whole development team and testers as a part of it (if we have dedicated testing team within project).
• Developers should write tests. Unit tests of course, integration and code acceptance tests (especially using effective fault injection methods) and white box regression tests. White box testing is a developers responsibility and must be in any testing process, especially agile-based. http://softwaretestingfundamentals.com/differences-between-black-box-testing-and-white-box-testing/
• Bugs are prior to test-cases as a results of work. No matter how to report them. I found that a lot of people really think that agile requires to minimize writing of bugs but that's not true. Really only clean eXtreme Programming and Test-Driven Development (as a separate process or as part of XP model) does but not because bugs not needed, but because XP expects pair development/testing process and bugs expected to be fixed directly after test running and TDD because tests created and executed before working code written, so bugs also expected to be fixed directly in most cases. If those practices/models not used then reporting of issues should be mandatory and high priority, reports might be direct to developers of using bug-tracker but they must be in.
• automation should write auto-test code based on bugs, it might be per-bug solution if needed but not a rule, better to have improvement of acceptance criteria and updated test for it
• scripts/cases for manual runs could but not should cover even critical bugs - depends on purpose of method used to test each particular functionality, also filed bug - is already a test case
• question: what to do with regression? see answer below
• Term "regression testing" for doing functionality tests even for legacy and "expected to be unchanged" functionality should be excluded from usage. It's NOT a regression. It's acceptance or usual functional tests. Regression testing - it's limited number of tests that recent change in code does not break related functionality. That statement lead to other four:
• regression statement important ONLY in compare with last build before recent change of code/bug-fix, it's not important in compare with any released product or any other functionality
• no need to do any "regression" runs of scripts/cases/functional maps etc. each functionality should match current release acceptance criteria - it should pass it and it's OK when functional tests on acceptance runs will contain extensive exploratory run as well as running automation script or additional manual script. Decisions should depend on actual expectations from functionality and it's context (again, yes)  and should be planned within sprint as usual User Stories/Tasks, not as just "number of test suites/cases/scripts to pass" or something like that
• decisions to fix the bug should depend from acceptance criteria for current release only, even if it's "old missed bug" and "no users get it" - there should be no checks to confirm that. If the bug is serious - it must be fixed, if not very serious - let's decide this on scrum meeting or sprint review or sprint retrospective or triage (if present)
• all bugs should be fixed and closed, dropped and technoted if known but fix postponed, release could not be counted as succesful if not so
• all technotes should be documented and in case of decision to fix them for next release they must be turned on to user stories and tasks for dev team.
• Team should get all process related information in a same time - on scrum meetings (and be involved to all of them). There should be no practice not to notify someone about any decision for process/product/results - team should be considered as a single unit.
• There should be no limitations for direct connection within team (from junior participant of development team to product owner and vice versa).
• Team should be self-organized (directly from Agile Manifesto) - means that high level planning and priorities might be done w/o involving development team, but decisions how to do and how much time required to do any task should be always done based on what developers say. All planning details should be based on development team participants comments/suggestion and requests. We should trust to each team participant, but also it means that everyone should trust to each other and provide required information with important details and in time to all team.
• Reporting stage should be easy to proceed for any participant. Scrum Master should make reporting easy and results clear and transparent.

That's the main things that I wanted to take attention too. But really it's a much more details and maybe sometimes I will extend them. But for now that's mostly all what I wanted to say what we should do if we want not to get wrong behavior when changing process to SCRUM (all the things I got from practical experience, not from theory).

P.S. Some discussion points:
I still think that critical/primary (does not matter what terminology to use, btw, but it should be unified for whole project) cases should be described in testing documentation independently of type of run. Means that we should should have test scripts for manual runs always. But they should not be used as main and strict todo manual. It should be as small as possible, but should cover all critical areas and be key point to run into details from it.

Scrum is not good itself, Kanban or, at least, Scrum-ban is better and actual.

I welcome any discussion or pointing me to incorrect or confusing statements, ask question or propose addtional info to extend article or create second part of it.

P.P.S. I'm really thinking that article should be divided into mgmt/dev/qa parts but for not don't see proper way to do that correctly without duplicating info, so for now I left it as is.

С вашим тестированием скорее всего что-то не так via XP Injection

вот развёрнутый построчный коммент на сей шедевральный псто Николая Алименкова
http://xpinjection.com/2013/02/08/your-testing-is-not-ok-if/

Тестировщик не участвует в обсуждении и планировании задач, которые он будет потом тестировать.
Ну, это воистену, причём проблема в том, что на практике, особенно в больших проектах (то есть где реально много людей вовлечены в процесс разработки, а много, в моём понимании - это более 30 человек суммарной команды) все, включая отдел тестирования, руководствуются принципом "решать проблемы нужно по мере их поступления" (то есть - будет фича, то будем тестировать, не будет, то и хер с ней) и "моя хата с краю" (то есть, если можно уйти от ответственности за принятие решений, то это будет сделано, а если нельзя, то максимум ответственности будет переложено на кого-то ещё). Результат, как правило, удручающий: всё сделано через жопу и все винят друг друга в "недоработке". Причём, в таких случаях тестировщика выдвигают на конечную стадию оценки (то есть уже по результату) и его же делают виноватым, что "не вмешался раньше". Хотя это, очевидно, проблема не только тестировщика, но и всего процесса тестирования.

1. Существует отдельно стоящий отдел тестирования, в котором каждый тестировщик может тестировать разные проекты. 2. Часто время тестировщика расписано в процентном отношении между этими проектами.
Я разбил это утверждение на 2 части. Первая часть сомнительна. Как минимум в такой формулировке. Отдельно стоящего отдела тестирования не может быть в компании, ибо тестирование - проектно-зависимая активность. Но выделенный отдел тестирования на проекте, который может заниматься разными подпроектами - это реально и нормально. Это, конечно, не идеальный вариант, но имеет право на жизнь.
На вторую часть я ответил в комментарии к статье и дополню: уже само такое допущение является полным бредом даже в пределах одно проекта с несколькими подпроектами. Тестировщик во время одного цикла тестирования должен думать про один проект на протяжении всего цикла релиза, иначе его эффективность на обоих проектах будет не выше 50% на каждом, то есть то, что он делал бы на одном проекте за час, на двух будет делать по два на каждом, причём скорее всего он будет отдавать приоритет внимания на один из проектов и реальная картина будет где-то 80% эффективности на одном проекте и 20% на другом. Мало того - даже переключение между подпроектами туда назад чревато большими потерями времени, ввиду явлений "выбивания из колеи" и "возвращения в строй". Потери времени и концентрации тестировщика будут в любом случае и их практически невозможно не только убрать, а даже минимально понизить эффект. К сожалению, это понимают единицы, а в аутсорсе ваще преобладает принцип "платят - делаем", что, конечно, не повышает ни качество продукта, ни качество процесса, ни уровень профессионализма самих тестировщиков.

Разработчикам плевать на мнение тестировщика, для них он кажется бесполезным грузом.
Любые советы и рекомендации тестировщика проходят через менеджера, который потом пытается продавить их в команде разработки.
Отмечу, что, по моему опыту, "плевать на мнение" не равно "кажется бесполезным грузом". То есть, зачастую девелоперы смотрят на тестировщиков свысока и говорят "ты што, праграмист, што ты гавариж шо мине делать?", но добавляют при этом "занимайся своей работой - ищи баги". То есть "искать баги" по мнению программистов, а часто и менеджмента - это черновая работу, которую просто лень делать программистам и им нужны для этого тестировщики. Я, в общем-то, уже писал, что считаю, что как таковые тестировщики не нужны в виде Quality Control на финальной стадии разработки, но при этом нужен сильный Quality Assurance на этапах инициации разработки и как реалтаймовый контроль качества. Но при этом готов утверждать, что программисты не могут быть высококлассными тестировщиками по определению. Не хочу обидеть никого - тут простая психология и никакого мошенничества: насколько бы ни был критическим склад ума человека - всё равно он сам себе склонен прощать больше, чем другим. Потому для программиста признать, что его код - говно, а написал он херню - всё равно тяжело и избавиться от этого невозможно. Люди, отрицающие это - отрицают своё же существование, по сути. Задача тестировщика - не верить в то, что программист написал работающую программу, что в спеке всё хорошо, что юзер стори корректна, что в баклоге всё нужное учтено и что весь мусор выброшен и т.д. Недоверие, дотошность, граничащая с занудностью, анализ всего происходящего в разработке и понимание того, как устроен софт - вот имхо главные козыри тестировщика. А программисты хотят иметь кликеров, на которых можно свалить облажавшийся релиз и, что пока удручает лично меня очень сильно - многие тестировщики до сих пор считают, что им платят именно за это (особенно в аутсорсе).

В проекте есть отдельная команда автоматизаторов, которая разрабатывает собственный фреймворк для тестирования. При этом фреймворк не применяется в реальной жизни пока не будет полностью закончен.
Насчёт собственного фреймворка - зависит от продукта, хотя, полагаю, это более чем справедливо для веб-стартапов. Но ситуация, когда требуется свой фреймворк для специфического продукта также реальна.
При этом гораздо большей проблемой мне кажется отсутствие правильного отношения к коду автотестов. Ключевое слово в термине "код автотестов" - это не "автотест", а "код". То есть определённые скрипты, которые выполняют те или иные действия. И относиться к ним нужно так же, как и к коду, с некоторыми поправками.
Первое: код автотестов должен быть более читабелен, чем даже код самого приложения. Либо должен качественно комментироваться, чтобы на анализ "а что мы тут делаем" уходило минимум времени. То есть у автотестов должен быть дизайн. А если понять, что написано в автотестах может только автор - ценность этого теста будет крайне невысокая.
Второе: рефакторинг кода автотестов. Если продукт сложный, то у него будет фреймфорк огромный и как бы кто ни хотел - избавиться от накопления мусорного кода не получится. Автотесты должны регулярно рефакториться, чтобы была возможность их использования любым членом команды, при этом не приводя к ситуации "зачем тут миллиарды этого кода?".
Третье: а это уже из "личного опыта" - нельзя смешивать автотесты и ручные тесты. Это разные типы фреймворков, ручные тесты не являются кодом и их стоит рассматривать, как руководство к действию, а не как однозначный скрипт. Особенно это актуально в agile-разработке и с учётом популяризации context-driven school & exploratory методов тестирования. Зы: я говорю не о "применимости", то есть тестировщик может и даже должен проводить тестирование одновременно и ручное и автоматизированное (как там по Баху, ведь автоматизация - это средство в руках тестировщика), но смешивание в одну кашу инструкции для тестирования и код скриптов приведёт к жесточайшему аду и к плохому эффекту "автоматизаторы занимаются автоматизацией, а не тестированием, потому они не обязаны разбираться в функционале, а должны писать автотесты и запускать их".

Разработчики не пишут никаких тестов и все тестирование висит строго на тестировщиках.
Тут как всегда "очевидное-невероятное" и рекурсия - существование выделенного отдела тестирования приводит к тому, что программисты считают, что не должны писать тесты иначе тогда "зачем тестировщики" в результате тестировщики часто получают неотлаженный код и всё валится и валится и валится. Много добавлять нечего - девелоперы должны писать юнит-тесты и прогонять свои изменения на валидность.

По результатам тестирования тестировщика могут либо наказать либо похвалить.
и сюда добавлю:
Тестировщика могут поощрить за количество найденных дефектов.
При всей очевидности сказанного никак не могу перестать удивляться тому, что не до всех доходит.
Начнём с того, что бонусы не нужны. На эту тему лучше всего сказал Джоэль Спольски и мне добавить просто нечего - http://russian.joelonsoftware.com/Articles/IncentivePayConsideredHar.html
Второй пункт, что результаты тестирования без оценки контекста не дают никакого впечатления о реальной эффективности работы отдельного тестировщика. Я даже не уверен или стоит писать много, просто тем, кто это делает стоит задуматься, вот как оценивать такие результаты:
1) один тестировщик написал 10000 тесткейсов, нашёл один баг;
2) второй тестировщик прошёл 10000 тесткейсов первого - нашёл 50 багов, поправил 5 кейсов;
3) третий тестировщик нашёл 150 багов, важность 95% ниже 3 по 5-бальной шкале, написал 500 тесткейсов;
4) четвертый тестировщик нашёл 10 багов - 9 из них критичные, не проходил тесткейсы вообще, написал 50 тесткейсов, работал напрямую с девелоперами при отладке функционалов;
5) пятый тестировщик не писал багов, не писал тесткейсов, при этом вычитал всю user-end документацию, нашёл тысячи несоответсвий, прокомментировал всё непосредственно в документации, написал недостающие технические документы;
6) в функционалах, которыми занимались тестировщики 2 и 4 было найдено по одному багу после релиза уже непосредственными пользователями.
Как кого оценивать будем? ;).
И таких примеров можно привести тысячи. Оценка работы тестировщика, как и оценка работы программиста, кстати, не может зависеть от численных показателей и нужно учитывать много факторов при оценке работы (речь не о бонусах, а именно поднятии зарплаты в целом, а также позиции/уровня ответственности, так как вот эти пункты реально зависимы друг от друга).

Тестировщики работают по выходным, когда были закончены доработки в коде продукта.
Ой, как классно. Работа по выходным и в овертаймы вообще недопустима. Мало того - я бы рекомендовал штрафовать людей, которые работают более 8-ми часов в день (в том числе и тех, кто сидит на работе 12 часов, а выполняет работы на 8). Хотя, честно - самому иногда хочется работать во внеурочное время, потому что ты себе сел и что-то делаешь и никто точно не помешает. Но это хреновый аргумент - при хорошей организации процесса в целом (не только в тестировании - тут нужна глобально хорошая организация, иначе не взлетит) такого желания возникать не должно.

Отдел тестирования постоянно растет и тестировщиков становится все больше. Потом появляются тест лиды, менеджеры, но процесс не останавливается.
Тут depends. Проекты бывают разные. Разной сложности и разветвлённости структуры. И хоть аджайль их в целом, хоть скрамь частями, хоть канбань, хоть раком становись - нужны люди, которые будут "дробить" общую гору "всего" на отдельные понятные и анализируемые части.
Ещё раз обращусь к Джоэлю Спольски - http://russian.joelonsoftware.com/Articles/HumanTaskSwitchesConsider.html
Статья о программистах, но это в той же степени относится и к тестировщикам и вообще: "Хорошие менеджеры считают своей обязанностью устранение препятствий, мешающих людям концентрироваться на одном деле и добиваться результатов." Ну и скопипащу своё:
Есть определённый предел, после которого рост числа сотрудников в команде будет приводить просто к похабному исполнению работы «ветеранами» и спихиванием работы на «новичков». А ещё неплохо учитывать, что увеличение числа людей в команде приводит к падению производительности, то есть то, что 1 человек сделает за 3 дня, 2 человека сделают в лучшем случае за 2, а не за 1,5, а 3 – за 1,5, а не за 1.

Причём "дробление на части" и занятие бюрократией - это таки работа, причём не самая "комфортная", но если она поставлена правильно, то с одной стороны команда будет самоорганизована в плане выполнения работы, но не будет думать "чо это мне делать и откуда брать задачи и что вообще не хватает", так как хороший лид/менеджер (продакт овнер, скрам мастер, да хоть боингом назовите )))) ) будет это пропускать через себя и выдавать уже фильтрованную информацию.

У тестировщиков нет возможности получить сборку продукта на любую версию в системе контроля версий.
Серьёзная проблема, но почти неустранимая, если проект размером с, например, MS Word. Даже сам по себе, без всего остального офиса, но с доп компонентами. То есть сборки должны быть поставлены правильно и регулярно. О чём ниже.

Сборка продукта проходит руками и часто из-за этого тестирование завершается провалом.
Ну как бы кроме этого есть ещё проблема, когда невозможно БЫСТРО получить нужную сборку никакими методами. То есть хочешь вручную - 6 часов, запросить у девелопера - "занят", дождаться своей очереди на сборку - от 3 до 10 часов, если не сломается. И это считается нормальным на всех уровнях, кроме тестировщиков, а поменять ессесно только силами команды тестирования ничего нереально.

Тестировщику приходится отчитываться перед менеджером за низкое качество продукта.
Скажем так, под "отчитываться" можно понимать разные вещи. Я считаю правильной ситуацию, когда проводится оценка проведённых efforts и выясняется, что было не так, почему и принимается решение о том, как этого в дальнейшем избежать или, хотя бы, сократить риски.
Правда, я часто наталкиваюсь на фактор "гордости/стыда" за свою работу. Когда ты пытаешься выяснить детали проблемы или проанализировать с человеком в чём была проблема, а он либо тупо оправдывается, либо обижается, либо в упор не признаёт, если очевидно было, что он неправ (а раз не признаёт, то 100% допустит эти же ошибки в дальнейшем). Бороться с этим явлением крайне тяжело.

В вашей системе для управления дефектами их больше тысячи в открытом состоянии.
А самое ужасное - это если такая ситуация одобряется. И по личному опыту и знаю о ситуации во многих проектах в разных компаниях: решение не фиксить баги - дико распространено, даже если баги очевидны. Лично я дико ужасаюсь с практики реджекта багов по причине "был всегда" с последующим наездом на тестировщика "почему год назад не нашёл?" От такого руки опускаются и хочется тупо убивать. Значимость бага вообще не зависит от того, когда он найден, а решение не исправлять его может быть короткосрочным и также должно зависеть только от текущей ситуации на проекте и критериях принятия продукта в релиз. У меня приятель с одного крупного проекта рассказывал, что у них таким макаром реджектились сразу целые баглисты по всему функционалу. То есть недели тестирования, а иногда и больше тупо вылетали в трубу. Это адский ад.

В команде есть специальный человек, который отвечает за тест-план. Только он может вносить изменения в тест-план и принимать решения по нему.
Не совсем понятно, что Николай имеет ввиду под тест-планом. Если общий проектный документ, то изменения всё-таки в него должны вноситься консолидированно, с контролем версий, а вот обсуждение вполне должно быть публичным. Правда очень часто, как программисты не хотят учавствовать в организаторских активити (тех же скрам-митингах, считая это пустопорожним трёпом), так и тестировщики не хотят учавствовать в обсуждении и корректировании проджект-левел документации. Работа с конкретным функционалом им представляется единственно нужной и смысла в таких документах они не видят и не читают. К сожалению, это весьма устоявшийся подход в головах и менять его нужно в обязательном порядке.

Отчет о тестировании составляется руками и требует больших усилий.
Отсутствуют метрики тестирования, которые отслеживают по ходу разработки продукта.
Информация о результатах тестирования не доступна публично для всех участников проекта.
Три вместе ибо очень завязаны. Причём желательно, чтобы всё делалось в одной утилите (то есть утилита, где создан план = утилита в которую репортит каждый участник команды = утилита для получения общекомандных статусов), из которой было бы легко потом получить нужную информацию как тестировщику, так и программисту, так и менеджеру.



По мере появления свежих мыслей по темам, поднятым выше - to be continued...

Goblin Game: Суть автоматизации регрессионного тестирования

Goblin Game: Суть автоматизации регрессионного тестирования:

Суть автоматизации регрессионного тестирования

Переиначивая копипасты коллективным разумом:

Ты СОВЕРШЕННО не понимаешь в чем суть автоматизации регрессионного тестирования. Это не «о, привет чуваки, зацените какой пиздатый способ повысить качество я нашел в интернете, гыгы». Автоматизация регрессионного тестирования - это не псевдоинтеллектуальный TDD. Автоматизация регрессионного тестирования - это не краудсорсинг, бетатесты или подглядывание за конкурентами. Автоматизация регрессионного тестирования это образ, рассматривая который, инженеры контроля качества могут представить себя в гугле — милыми, беззащитными, сопереживающими миллионерами, которыми они якобы являются. Zynga купила себе Draw Something, а мы смеемся. MS запустил Mango, а мы смеемся. Twitter пропускает сообщения в выдаче, а мы обсуждаем и просим еще. Самоубийства, убийства, геноцид — мы автоматизируем регрессию. Расизм, сексизм, дискриминация, ксенофобия, изнасилования, беспричинная ненависть — мы автоматизируем регрессию. Клиенты разбегаются и перестали выплачивать зарплату — мы автоматизируем регрессию. Мы бездушно подпишемся под чем угодно, наши предпочтения не основаны на здравом смысле, автоматизация регрессии без гарантий и обязательств — наша стихия, мы — истинное лицо рынка контроля качества.

DZis is a Test: Херистики и Характеристики. Если вы приступаете к ...

DZis is a Test: Херистики и Характеристики. Если вы приступаете к ...: … то первое с чего следует начать, это с документов Heuristic Test Strategy Model . И более широкого списка: Software Quality Characteristic...

DZis is a Test: Несколько фактов после посещения онлайн воркшопа Д...

DZis is a Test: Несколько фактов после посещения онлайн воркшопа Д...: Термин «Сценарное тестирование» придумал Джеймс Бах «Сценарное тестирование» – тестирование, проводимое при жестком следовании задокумент...