Re[13]: Зачем вообще QA и мэнэджеры?
От: StanislavK Великобритания  
Дата: 31.05.17 12:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:


SK>>Контроль? Тесты, многие тысячи тестов — покрыто все.

I>Отлично, уже лучше. Но это автоматические тесты, они не выявляют новых видов багов. Т.е. если у тебя один тест на длину строки, то он найдет только баги с длиной строки и не сможет ничего сделать, если в строке символы не те. Далее, если ты допишешь тест на символы, то оба твоих теста будут делать одно и тоже годами — длину строки и символы.
Если не полный дебил пишет, то будет приличный тест. В принципе ничего не выявляет новые баги пока это кто-то не протестирует и не обнаружит баг.

I>Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях. Т.е. 'внезапность' и 'неопределенность'. Этот класс проблем покрывается эксплорейшн тестами. У них такая особенность, они абсолютно не автоматизируются. Это понятно, или надо объяснять ? Часто это тест в стиле 'кликать как юзер' со всеми вытекающими проблемами.

Не, объясни. Что именно не автоматизируется? Постановка рандомных параметров в сервис? Или какие-то экстреммальные знаечения не кодятся? Или ты намекаешь, что никто не заменит обезъяну рандомно стучащую по клавишам?

I>И возвращаемся к старому вопросу — кто у вас делает эксплорейшн тестирование?

Разработчики делают тестирование. Надо гонять свой код так, чтобы шанс ошибки был минимален. Называть это "эксплорейшн тестирование" или нет, я не скажу. В нашей области ошибка легко может стоить несколько десятков миллионов, так что к этому серьезно относятся.
Re[14]: Зачем вообще QA и мэнэджеры?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.06.17 14:26
Оценка:
Здравствуйте, StanislavK, Вы писали:

K>>>Контроль? Тесты, многие тысячи тестов — покрыто все.

I>>Отлично, уже лучше. Но это автоматические тесты, они не выявляют новых видов багов. Т.е. если у тебя один тест на длину строки, то он найдет только баги с длиной строки и не сможет ничего сделать, если в строке символы не те. Далее, если ты допишешь тест на символы, то оба твоих теста будут делать одно и тоже годами — длину строки и символы.
SK>Если не полный дебил пишет, то будет приличный тест. В принципе ничего не выявляет новые баги пока это кто-то не протестирует и не обнаружит баг.

Браво! И кто же у вас решает эту проблему "ничего не выявляет новые баги пока это кто-то не протестирует и не обнаружит баг" ?
Вот QA именно этим и заняты и это называется эксплорейшн тестирование.

I>>Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях. Т.е. 'внезапность' и 'неопределенность'. Этот класс проблем покрывается эксплорейшн тестами. У них такая особенность, они абсолютно не автоматизируются. Это понятно, или надо объяснять ? Часто это тест в стиле 'кликать как юзер' со всеми вытекающими проблемами.

SK>Не, объясни. Что именно не автоматизируется? Постановка рандомных параметров в сервис? Или какие-то экстреммальные знаечения не кодятся? Или ты намекаешь, что никто не заменит обезъяну рандомно стучащую по клавишам?

Придумывание новых кейсов, которые еще не прогонялись на приложении, новых стратегий, новых последовательностей и тд и тд. Т.е. __исследование__ качественных свойств системы. У девелоперов крайне плохо с этим, т.к. основная их обязанность — код писать и проектировать. А исследование, это самые разные инструменты. Смотришь, как работает система, делаешь наблюдения, анализируешь закономерности, придумываешь новые тесты и так 100% времени.

I>>И возвращаемся к старому вопросу — кто у вас делает эксплорейшн тестирование?

SK>Разработчики делают тестирование. Надо гонять свой код так, чтобы шанс ошибки был минимален. Называть это "эксплорейшн тестирование" или нет, я не скажу. В нашей области ошибка легко может стоить несколько десятков миллионов, так что к этому серьезно относятся.

Это значит, что у вас нет эксплорейшн тестирования. Ибо там, где это важно, люди заняты только этим 100% времени. И именно поэтому они QA а не девелоперы.
Re[13]: Зачем вообще QA и мэнэджеры?
От: Ночной Смотрящий Россия  
Дата: 02.06.17 20:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Отлично, уже лучше. Но это автоматические тесты, они не выявляют новых видов багов. Т.е. если у тебя один тест на длину строки, то он найдет только баги с длиной строки и не сможет ничего сделать, если в строке символы не те.


А если, как это обычно и бывает, тесты просто сравнивают образец и результат?

I>Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях.


А можно пример такого неизвестного случая?
Re[14]: Зачем вообще QA и мэнэджеры?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 06.06.17 18:47
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Отлично, уже лучше. Но это автоматические тесты, они не выявляют новых видов багов. Т.е. если у тебя один тест на длину строки, то он найдет только баги с длиной строки и не сможет ничего сделать, если в строке символы не те.


НС>А если, как это обычно и бывает, тесты просто сравнивают образец и результат?


Это чтото навроде approved tests? С ними ситуация ничем не лучше, просто некоторые кейсы проще покрывать вот такими тестами.

I>>Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях.


НС>А можно пример такого неизвестного случая?


Теоретически, если у тебя астрономическое число тестов, таких не будет А вообще нужно смотреть что за софтина и каким методом покрывали тестами.
Re[15]: Зачем вообще QA и мэнэджеры?
От: Ночной Смотрящий Россия  
Дата: 06.06.17 19:40
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Это чтото навроде approved tests? С ними ситуация ничем не лучше


Можно пример проблемы?

I>>>Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях.

НС>>А можно пример такого неизвестного случая?
I>Теоретически, если у тебя астрономическое число тестов, таких не будет А вообще нужно смотреть что за софтина и каким методом покрывали тестами.

Т.е примера не будет?
Re[16]: Зачем вообще QA и мэнэджеры?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.17 07:34
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Это чтото навроде approved tests? С ними ситуация ничем не лучше


НС>Можно пример проблемы?


Пример — косяки в трансляторах/компиляторах. https://github.com/Microsoft/TypeScript/issues?q=is%3Aissue+is%3Aclosed+label%3ABug

Проблема остаётся той же — старые тесты находят только старые виды багов. Один образец покрывает небольшое количество кейсов, как правило, счетное, см файлы в фолдере тестов из указаного репа. А вот количество комбинаций бесконечно.
Потому коммюнити регулярно находит баги в TS.

I>>>>Т.е. они пригодны для поиска _регрессии_. Но они никак не помогают в неизвестных случаях.

НС>>>А можно пример такого неизвестного случая?
I>>Теоретически, если у тебя астрономическое число тестов, таких не будет А вообще нужно смотреть что за софтина и каким методом покрывали тестами.

НС>Т.е примера не будет?


См выше. Сколько бы ты тестов ни написал для компилятора, количество всевозможных синтаксических комбинаций бесконечно.
Re[17]: Зачем вообще QA и мэнэджеры?
От: Ночной Смотрящий Россия  
Дата: 08.06.17 09:52
Оценка:
Здравствуйте, Ikemefula, Вы писали:

НС>>Можно пример проблемы?

I>Пример — косяки в трансляторах/компиляторах. https://github.com/Microsoft/TypeScript/issues?q=is%3Aissue+is%3Aclosed+label%3ABug

Давай конкретно. Просматривать 118 страниц я точно не буду.

I>Проблема остаётся той же — старые тесты находят только старые виды багов. Один образец покрывает небольшое количество кейсов, как правило, счетное, см файлы в фолдере тестов из указаного репа. А вот количество комбинаций бесконечно.


Я тебе в третий раз повторяю — не надо общих слов, давай конкретные примеры.

НС>>Т.е примера не будет?

I>См выше.

Выше это не пример, это посылание на три буквы.
Re: Зачем вообще QA и мэнэджеры?
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.06.17 10:10
Оценка:
Здравствуйте, cocacola, Вы писали:

C>Привет! Раньше в it конторах хоть как то в респектах были разработчики.

C>Счас какая-то хрень, набрали на одного разраба по 2 qa и по 2 мэнэджера, они сидят в носу ковыряют, важные такие, один
C>есть у нас Lead QA, жирный такой, ленивый, важный. А сам тупой, как валенок. Даже авто тесты не может написать. Вот накуя они нужны? ведь разрабы без них обойдуться, а они без них нет.
C>Только бюджет компании проедают. Что за тенденция? И лезут же, лезут, знаний нет, а пирог IT вкусный, за счет наглости кусочек урвать то хотят. С одного митинга на другой ходят. Создают видимость работы. ДА нахрен ваши митинги, продукты пишут разрабы, а вы там хоть обмитингуйтесь, ни хрена само не напишеться.
Да вообще никто не нужен, кроме PM-ов (вы их почему-то называете аналитиками).
Вот поговоришь с бизнесом, всё выяснишь, напишешь требования, поизучаешь на предмет реализуемости, заполнишь implementation notes со ссылками на библиотеки, которые брать, и иллюстрациями в псевдокоде.
Разрабы это берут, две недели в носу ковыряют, и потом такие "нуууу, это 40 мэндэев, плюс регрессия — итого через 11 месяцев зарелизим. Если не дропнем в процессе реприоритизации".
На вопрос "а вы не охренели" они такие "нуу, там же сначала надо анализ и дизайн, потом дизайн ревью, потом UX дизайн, потом вам же вечно наш UX не нравится — его переделывать придётся, потом собсно код, потом код ревью, потом автотесты, потом разбор результатов автотеста, вот и набигает!"
Берёт такой PM в руки студию, за два часа код пишет, ещё час проверяет, и отправляет клиенту со словами "вот вам патч, пользуйтесь, только вашему TAMу про него не говорите — этого релиза официально не существует".
Просто в PM надо брать людей не из маркетинга, которые там не справились, а тех разрабов, которые с предметной областью разобрались.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Зачем вообще QA и мэнэджеры?
От: pestis  
Дата: 08.06.17 10:18
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Просто в PM надо брать людей не из маркетинга, которые там не справились, а тех разрабов, которые с предметной областью разобрались.


Сам себя не похвалишь — никто не похвалит. Вы нормально платить девелоперам не пробовали?
Re[18]: Зачем вообще QA и мэнэджеры?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.17 10:36
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Можно пример проблемы?

I>>Пример — косяки в трансляторах/компиляторах. https://github.com/Microsoft/TypeScript/issues?q=is%3Aissue+is%3Aclosed+label%3ABug

НС>Давай конкретно. Просматривать 118 страниц я точно не буду.


Ткнуть в первый попавшийся ума не хватило ? https://github.com/Microsoft/TypeScript/issues/16139

I>>Проблема остаётся той же — старые тесты находят только старые виды багов. Один образец покрывает небольшое количество кейсов, как правило, счетное, см файлы в фолдере тестов из указаного репа. А вот количество комбинаций бесконечно.

НС>Я тебе в третий раз повторяю — не надо общих слов, давай конкретные примеры.
НС>>>Т.е примера не будет?
I>>См выше.

НС>Выше это не пример, это посылание на три буквы.


Извини, я тебе не психотерапевт.
Re[2]: Зачем вообще QA и мэнэджеры?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.06.17 12:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Берёт такой PM в руки студию, за два часа код пишет, ещё час проверяет, и отправляет клиенту со словами "вот вам патч, пользуйтесь, только вашему TAMу про него не говорите — этого релиза официально не существует".


У нас такие PM называются девелоперы У вас не так ?
Re[19]: Зачем вообще QA и мэнэджеры?
От: Ночной Смотрящий Россия  
Дата: 08.06.17 18:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:

НС>>Давай конкретно. Просматривать 118 страниц я точно не буду.

I>Ткнуть в первый попавшийся ума не хватило ? https://github.com/Microsoft/TypeScript/issues/16139

Ну и? Банальный тест со сравнением вполне такую регрессию поймает, даже если про нее заранее ничего не знать. Если ты намекаешь что набор тестов может эту ситуацию не покрыть? Да, может. Но, во-первых, компиляторы это очень особенная область софтостроения, это я тебе как человек, их писавший много раз говорю. А во-вторых для реальных компиляторов со временем набирается база тесткейсов, которая покрывает 99.99% потенциально возможных проблем.
Re[20]: Зачем вообще QA и мэнэджеры?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.06.17 07:39
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Давай конкретно. Просматривать 118 страниц я точно не буду.

I>>Ткнуть в первый попавшийся ума не хватило ? https://github.com/Microsoft/TypeScript/issues/16139

НС>Ну и? Банальный тест со сравнением вполне такую регрессию поймает, даже если про нее заранее ничего не знать. Если ты намекаешь что набор тестов может эту ситуацию не покрыть?


Именно — любой набор тестов не даёт 100% покрытия.

>Да, может. Но, во-первых, компиляторы это очень особенная область софтостроения, это я тебе как человек, их писавший много раз говорю. А во-вторых для реальных компиляторов со временем набирается база тесткейсов, которая покрывает 99.99% потенциально возможных проблем.


Правильно — со временем. В обычном софте проблемы возникают уже на уровне интеграции компонентов
1 комбинации
2 время
3 многозадачность
4 внешние зависимости
5 зависимости от сторонних компонентов
6 окружение
7 железо

В итоге получается так, что без QA хорошо если п.1, 2 и 3 закроешь, и то "со временем". Всё остальное это требует QA в обязательном порядке. При этом даже п.1 2 и 3 требуют проверки QA
а. девелопер воплощает в тесте ровно то, что и в коде, т.е. своё понимание. Кто проверит, что его понимание соответствует требованиям ?
б. чисто психологически исполнитель сам себя проверяет крайне слабо. То есть, при равной квалификации двух человек (a проверят a и b проверяет a) выигрывает второй вариант.
в. приёмка — как здесь обойтись без QA ?
Re[21]: Зачем вообще QA и мэнэджеры?
От: Ночной Смотрящий Россия  
Дата: 09.06.17 20:23
Оценка:
Здравствуйте, Ikemefula, Вы писали:

НС>>Ну и? Банальный тест со сравнением вполне такую регрессию поймает, даже если про нее заранее ничего не знать. Если ты намекаешь что набор тестов может эту ситуацию не покрыть?

I>Именно — любой набор тестов не даёт 100% покрытия.

Ты прям Капитан Очевидность. Вот только изначально ты несколько иное заявлял:

Но это автоматические тесты, они не выявляют новых видов багов.


>>Да, может. Но, во-первых, компиляторы это очень особенная область софтостроения, это я тебе как человек, их писавший много раз говорю. А во-вторых для реальных компиляторов со временем набирается база тесткейсов, которая покрывает 99.99% потенциально возможных проблем.

I>Правильно — со временем.

Правильно — таки набирается. А теперь почсмотри на свою цитату выше.

I> В обычном софте проблемы возникают уже на уровне интеграции компонентов


В обычном софте проблемы возникают практически везде. И таки интеграционные тесты тоже сущест вуют и способны выявить баги, о которых ты заранее не подозревал. Хуже того, какая то ориентация на отлов конкретного вида багов есть только на уровне юнит-тестов. А интеграционные обычно просто прогоняют сценарии, не ориентируясь ни на какие баги и их типы.

I>В итоге получается так, что без QA хорошо если п.1, 2 и 3 закроешь, и то "со временем". Всё остальное это требует QA в обязательном порядке. При этом даже п.1 2 и 3 требуют проверки QA


Ты слишком категоричен. Я лично лицезрел в рамках одной компании, когда похожие продукты разрабатывались двумя разными командами. В одной были выделенные QA, постоянно что то вручную тестирующие. А во второй вообще ни одного отделного QA спеца не было, ручное тестирование ограничивалось простенькой проверкой нескольких сценариев ПМом перед выкаткой очередного релиза на прод.
И вот что удивительно — багов в проде в первом случае было даже не в разы, а на порядки больше.
При этом я вовсе не утверждаю, что QA вообще не нужны. Просто все бывает очень по разному — разная предметная область, разная сложность и объем решений, разный уровень разработчиков, разный уровень ПМов.

I>а. девелопер воплощает в тесте ровно то, что и в коде, т.е. своё понимание. Кто проверит, что его понимание соответствует требованиям ?


Девелопер, не понимающий требований? Тут никакой QA не поможет.

I>б. чисто психологически исполнитель сам себя проверяет крайне слабо. То есть, при равной квалификации двух человек (a проверят a и b проверяет a) выигрывает второй вариант.


Опять же, не обобщай.

I>в. приёмка — как здесь обойтись без QA ?


Приемка — не всегда бывает, ваш КО.
Re[2]: Зачем вообще QA и мэнэджеры?
От: Ночной Смотрящий Россия  
Дата: 09.06.17 20:30
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Просто в PM надо брать людей не из маркетинга, которые там не справились, а тех разрабов, которые с предметной областью разобрались.


Не, просто не надо заставлять девелоперов формировать окончательные сроки и планы. PM как раз и должен этим заниматься, а не от девелоперов качественное выполнение свой работы ожидать.
Re[3]: Зачем вообще QA и мэнэджеры?
От: Ночной Смотрящий Россия  
Дата: 09.06.17 20:33
Оценка:
Здравствуйте, pestis, Вы писали:

P>Сам себя не похвалишь — никто не похвалит. Вы нормально платить девелоперам не пробовали?


Оплата тут вообще не причем. Причем эти самые РМы, сами и дрессирующие разработчиков. Сперва, когда даже требований еще нормальных нет, они трясут с разработчиков сроки на весь проект, в точности как Синклер описал. Сроки эти, разумеется, можно взять только поплевав в потолок. А потом все те же РМы ближе к релизу, когда сроки горят, начинают сношать и вешать всех собак на разработчиков. Сами себя виноватыми они, разумеется, не считают.
Вполне логично, что в следующий раз разрабы умножат сроки минимум на Пи.
Re[22]: Зачем вообще QA и мэнэджеры?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.06.17 08:40
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Ну и? Банальный тест со сравнением вполне такую регрессию поймает, даже если про нее заранее ничего не знать. Если ты намекаешь что набор тестов может эту ситуацию не покрыть?

I>>Именно — любой набор тестов не даёт 100% покрытия.

НС>Ты прям Капитан Очевидность. Вот только изначально ты несколько иное заявлял:

НС>

НС>Но это автоматические тесты, они не выявляют новых видов багов.


Правильно. Я говорил исключительно про автоматические тесты.

>>>Да, может. Но, во-первых, компиляторы это очень особенная область софтостроения, это я тебе как человек, их писавший много раз говорю. А во-вторых для реальных компиляторов со временем набирается база тесткейсов, которая покрывает 99.99% потенциально возможных проблем.

I>>Правильно — со временем.

НС>Правильно — таки набирается. А теперь почсмотри на свою цитату выше.


Ты сам смотри. У меня 100% а у тебя взятые от балды 99.99 и неопределенный промежуток времени, который нужен, что бы покрыть тестами _старый_ функционал. То есть, новый функционал всегда будет иметь недостаточное количество тестов.

I>> В обычном софте проблемы возникают уже на уровне интеграции компонентов


НС>В обычном софте проблемы возникают практически везде. И таки интеграционные тесты тоже существуют и способны выявить баги, о которых ты заранее не подозревал.


Интеграционные тесты во первых, слишком медленные, во вторых, слишком дискретные.

I>>В итоге получается так, что без QA хорошо если п.1, 2 и 3 закроешь, и то "со временем". Всё остальное это требует QA в обязательном порядке. При этом даже п.1 2 и 3 требуют проверки QA


НС>Ты слишком категоричен. Я лично лицезрел в рамках одной компании, когда похожие продукты разрабатывались двумя разными командами. В одной были выделенные QA, постоянно что то вручную тестирующие. А во второй вообще ни одного отделного QA спеца не было, ручное тестирование ограничивалось простенькой проверкой нескольких сценариев ПМом перед выкаткой очередного релиза на прод.


Реальность обычно прямо противоположна этому кейсу. Более-менее серьезное приложение уже просто не прокликать одним человеком за рабочий день. Пудозреваю, ты чтото недоговариваешь.

НС>Девелопер, не понимающий требований? Тут никакой QA не поможет.


У тебя интересные ассоциации, поздравляю.
Во первых, требования на разных проектах сильно разного качества.
Во вторых, девелоперы как правильно не владеют доменом в той степени, как другие специалисты.


I>>б. чисто психологически исполнитель сам себя проверяет крайне слабо. То есть, при равной квалификации двух человек (a проверят a и b проверяет a) выигрывает второй вариант.

НС>Опять же, не обобщай.

Это факты. Так было уже в бородатые 70е, см Гленфорда Майерса.

I>>в. приёмка — как здесь обойтись без QA ?


НС>Приемка — не всегда бывает, ваш КО.


О чем и речь. И тестирование не всегда бывает. И даже девелоперами. И что с того ?
Re[23]: Зачем вообще QA и мэнэджеры?
От: Ночной Смотрящий Россия  
Дата: 12.06.17 12:01
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Правильно. Я говорил исключительно про автоматические тесты.


И я тоже.

НС>>Правильно — таки набирается. А теперь почсмотри на свою цитату выше.

I>Ты сам смотри. У меня 100%

Что 100%? Тестирование в принципе штука статистическая, никаких 100% нет нигже, не в автотестах, ни в ручном тестировании.

I>а у тебя взятые от балды 99.99 и неопределенный промежуток времени, который нужен, что бы покрыть тестами _старый_ функционал.


Опять глупости говоришь. В тех же упомянутых тобой компиляторах тесты пишутся в начале, а только потом функционал.

НС>>В обычном софте проблемы возникают практически везде. И таки интеграционные тесты тоже существуют и способны выявить баги, о которых ты заранее не подозревал.

I>Интеграционные тесты во первых, слишком медленные

Критерий?

I>во вторых, слишком дискретные.


Тем не менее определенный (существенный) процент багов они выявляют.

НС>>Ты слишком категоричен. Я лично лицезрел в рамках одной компании, когда похожие продукты разрабатывались двумя разными командами. В одной были выделенные QA, постоянно что то вручную тестирующие. А во второй вообще ни одного отделного QA спеца не было, ручное тестирование ограничивалось простенькой проверкой нескольких сценариев ПМом перед выкаткой очередного релиза на прод.

I>Реальность обычно прямо противоположна этому кейсу.

Это уж у кого какая реальность. Я вот реальный случай рассказываю, а от тебя даже гипотетических примеров приходится несколько сообщений просить.

I> Более-менее серьезное приложение уже просто не прокликать одним человеком за рабочий день.


Это очень сильно зависит от приложения.

I> Пудозреваю, ты чтото недоговариваешь.


Ну или просто опыт у тебя с другого бока.

НС>>Приемка — не всегда бывает, ваш КО.

I>О чем и речь. И тестирование не всегда бывает. И даже девелоперами. И что с того ?

И то что QA не есть обязательное условие.
Re[24]: Зачем вообще QA и мэнэджеры?
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 12.06.17 17:28
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Что 100%? Тестирование в принципе штука статистическая, никаких 100% нет нигже, не в автотестах, ни в ручном тестировании.


Разумеется. И чем, по твоему, отличается ручной эксплорейшн тест и автоматический ?

I>>а у тебя взятые от балды 99.99 и неопределенный промежуток времени, который нужен, что бы покрыть тестами _старый_ функционал.

НС>Опять глупости говоришь. В тех же упомянутых тобой компиляторах тесты пишутся в начале, а только потом функционал.

Именно. Потому и вылазят тривиальные баги запросто так.

НС>>>В обычном софте проблемы возникают практически везде. И таки интеграционные тесты тоже существуют и способны выявить баги, о которых ты заранее не подозревал.

I>>Интеграционные тесты во первых, слишком медленные
НС>Критерий?

I>>Реальность обычно прямо противоположна этому кейсу.


НС>Это уж у кого какая реальность. Я вот реальный случай рассказываю, а от тебя даже гипотетических примеров приходится несколько сообщений просить.


Вот интересный пример, из жизни, я месяц кодил на асме, скомпилировал, запустил и всё заработало как положено. И что с того ? В чем тут принципиальная разница с твоим "а я в одной конторе ..." ?


НС>И то что QA не есть обязательное условие.


Спасибо, капитан! В треде речь вообще то про то, что они вообще не нужны.
Re[3]: Зачем вообще QA и мэнэджеры?
От: Sinclair Россия https://github.com/evilguest/
Дата: 13.06.17 11:11
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Не, просто не надо заставлять девелоперов формировать окончательные сроки и планы. PM как раз и должен этим заниматься, а не от девелоперов качественное выполнение свой работы ожидать.
Это на самом деле была шутка про то, что каждая должность считает главной именно себя. Особенно какие-нибудь инфраструктурные подразделения этим грешат — скажем, у админов часто бывает звёздная болезнь; у бухгалтерии тоже.
А если без шуток, то имхо сегрегация конвеера — это тупиковый путь.
Продакт менеджеры, пришедшие из плохого маркетинга (того, где задача ставится в виде "помочь продать это говно", а внутренне понимается как "главное — выбить бюджет"), не могут скомпенсировать неспособность вообще понять технические особенности продукта ежедневными усилиями.
Программисты, намеренно изолирующие себя от потребностей бизнеса, встают в позу "да эти дебилы из продакт департмент сами не знают, чо хотят. Вот я щас как зделаю ровно по требования — пусть поймут, какие они тупые тогда".
При долгой практике умение понимать пользователя вообще атрофируется (особенно если метрики, за которые награждают и карают, измеряются в фуфле вроде количества реализованных сценариев), и программер искренне недоумевает, почему продакт матерится при виде очередного тригрида с пропертидайлогом. (Если бы не NDA, я бы таких вам показал примеров из нашего продукта, что весь форум UX в ужасе разбежится).
Тестеры, которые "без нас всё вообще умрёт", ожесточённо тестируют экзотические сценарии, забывая о банальностях. В итоге растёт взаимная враждебность: "мы этот рейс кондишен три недели всем отделом ловили, а продакт закрыл с формулировкой 'у нас полтора миллиона пользователей, и ни один на это не наступил. Отложим, пока в продакшне не воспроизведётся", и "блин они мне тут эксплоратори месяц гоняли, а на первом же демо партнёрам выяснилось, что заказы с количеством больше 1 в штаты приводят к UnexpectedError".

Причём "корпоративный способ", когда "а давайте зашедулим еженедельные митинги между каждой парой команд" ведёт только к кратковременному улучшению — когда какой-нибудь очевидный идиотизм вроде списка компонентов, не совпадающего у девелоперов и у саппорта, однократно чинится. А потом это превращается в обузу — потому что девелопмент из 40 часов в неделю начинает 8 тратить на "регулярные встречи" с сейлзами, маркетингом, саппортом, QA, продакт менеджментом, UX дизайнерами, юристами, и accounts receivable.

Наиболее толковые результаты возникают всегда на стыке специальностей — когда продакт умеет программировать, или дизайнить, или и то и другое. Или там, девелопер владеет fluent english, и в курсе особенностей рынка и конкурентов на нём, а также умеет работать с QA-инфраструктурой, и читал книги Нильсена и Тафте.
В жизни корпораций такое встречается редко, потому что там начинается гонка — девелопер должен отгружать код 40 часов в неделю; ему некогда заниматься чтением wall street journal.
Или там продакт менеджер тратит недели на изучение обновлённых прайс листов от Microsoft, потому что он не владеет скриптингом и не может написать автоматическую сравнивалку прайсов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.