QA по сравнению с [закрытым] отношением разработки
Это получит Вас, весь пользователь составил таблицы:
select * from sysobjects where xtype='U'
Для получения седел:
Select * from Information_Schema.Columns Where Table_Name = 'Insert Table Name Here'
кроме того, я нахожу http://www.sqlservercentral.com/ быть довольно хорошим ресурсом дб.
11 ответов
Ответ очень субъективен, но вот мой опыт.
В Microsoft есть сильная организация по разработке тестов. Это немного отличается от традиционного QA, потому что мы нанимаем программистов для тестирования и вовлекаем их в процесс еще на этапе проектирования. Их работа заключается в тестировании и особенно в автоматизации тестирования продукта. По моему опыту, тестировщику требуется примерно столько же времени на тестирование и автоматизацию функции, сколько у разработчика на кодирование и исправление ошибок в продукте. Это подразумевает отображение 1: 1. Это очень похоже на эмпирическое правило, согласно которому написание модульных тестов занимает примерно столько же времени, сколько и написание кода.
Это сочетание будет варьироваться в зависимости от нескольких критериев:
- Сколько модульного тестирования проводят разработчики. Чем больше они делают, тем меньше требуется тестов.
- Сколько разработчики пишут с нуля по сравнению с использованием существующих библиотек. Если используется много уже существующего кода и тестировщикам необходимо проверить и эту функциональность, необходимо учитывать невозвратные затраты на разработку при сопоставлении 1: 1.
- Насколько динамична разработка. Если вы пишете пользовательский интерфейс, в котором относительно небольшие настройки разработчика вызывают большие изменения в тестируемой поверхности, вам потребуется привлечь больше тестировщиков.
- Насколько критична эта функция. Чтобы написать что-то вроде GMail, где он используется случайно, а ошибки допускаются и исправляются в полевых условиях, требуется меньше тестировщиков. С другой стороны, если вы работаете с медицинскими устройствами визуализации , вам нужно гораздо больше тестирования, потому что ошибки трудно исправить в полевых условиях и очень плохо, когда они возникают.
For most projects at the company I work at the ratio is 1:1. But this can vary on several factors:
- Dev output. I've seen one dev who had a high amount of output and had 3 QA working on his features.
- Quality bar for the product. A mission critical, high reliability system should have a higher QA bar than an internal reporting website, and will need more QA people.
- Some projects must be tested in higher number of configurations and scenarios. Devs might stay constant, but you will obviously need more QA to cover the full test matrix.
- How automatable the testing is. If testing can't be easily automated, you'll need more people to do manual passes.
In my experience, there are two major kinds of QA staff: those who simply follow a written script and interact with an application in an effort to find edge cases, and those who can actually write automated testing code themselves, and seek to find new and innovative ways (fuzzing, Selenium, writing API clients) to break the dev team's code.
If your QA team is made up primarily of folks of the first type, then a 1:1 ratio or better vs. your developers is probably a must. Otherwise, they'll struggle to keep up with any new features introduced by the dev team, and will often resist any changes made to the product, because it further complicates their testing workflow.
The latter type (i.e., test engineers who can code), on the other hand, are a godsend to any productive development team. The coders can communicate with them as peers, and the testers can find useful ways to automate and improve their own processes by writing smarter and better-abstracted test harnesses and utilities. One really good test engineer can probably support the work of 2-3 developers, especially if those developers are already writing useful unit and integration tests themselves that the tester can use as a starting point.
There are many factors that go into answering that.
- Do you have automated testing?
- How are your release cycles structured?
- What is your unit test coverage % ?
- How good are your people (both QA & Dev)?
- Are you including QA in the entire project life cycle or do you dump on them at the end?
- Are you doing incremental releases to QA?
I've worked places where it varied from 3:1 (QA/DEV) to .5:1 (QA/DEV). It boils down to how many QA resources it takes to adequately test the product and there's no catch-all answer to that.
Right now where I work there are 3 developers for each QA person. This has its ups and downs as at times QA will find a problem but there are solutions outside of code changes,e.g. don't click where it is pointless to do so.
A couple of times there is no QA where I've worked which at times is almost like a recipe for disaster as customers then become the QA as their problems become developer problems.
Количество сотрудников QA не должно зависеть от количества разработчиков . Это должно зависеть от желаемого качества продукта, но не от чего-либо еще.
Многие здесь говорят, что «для QA» работа хорошего разработчика является более легкой задачей, чем «для QA» работа более плохого разработчика. Черт, почему это правда? «Обеспечить качество» - а QA - это «гарантия качества» - означает разработать процесс, который помечает продукт как «QA пройдено» и «QA failed». Я знаю только два процесса, которые зависят от самого кода: статическая проверка кода и экспертная оценка. Хотя первый в некоторой степени используется, и для его поддержки иногда требуются специалисты по тестированию, то, что называется « качество » кода, не имеет значения для бездушной машины. А рецензирование проводится программистами, а не QA. Надеюсь, это убедит вас в том, что количество QA не зависит от разработчиков, не так ли?
В той области, в которой работает наша компания, нет конкуренции, и рынок очень узок. Поэтому мы получаем всю необходимую информацию из отчетов об ошибках и у нас нет QA , поэтому коэффициент равен нулю. Все тестирование проводится разработчиками. Тем не менее, мы живем, потому что необходимое качество не требует привлечения каких-либо специалистов по тестированию.
В нашей организации соотношение dev: QA составляет 5: 2, а для этого нам нужно понять еще один сценарий, такой как
, который работает над модульным тестированием. В нашем случае один человек полностью посвящен написанию плана модульного тестирования, а команда из 5 человек выполняет модульные тесты и исправляет ошибки. наш PL вообще не участвует в кодировании, он занимается только делами, ориентированными на процесс / обзор
Функциональное тестирование проводится тестировщиками, работающими неполный рабочий день, можно сказать, половину ресурса и один цикл функционального тестирования проводят разработчики
зависит от размера проекта, письменного оператора и ресурсов компании в зависимости от уровня CMM
Есть много факторов, самый важный из которых - уровень качества, необходимый для приложения, это небольшой веб-сайт? или крупный медицинский инструмент? или финансовая система? Одна строка кода, измененная для космического шаттла, может потребовать недель тестирования ...
В цехе прогрессивной разработки потребности в ресурсах QA (по отношению к разработке) должны со временем уменьшаться по мере внедрения улучшений QA, таких как TDD , Обзоры кода и т. Д. Я считаю, что QA, сосредоточенное исключительно на ручном тестировании, является пустой тратой, QA следует использовать, чтобы улучшить процесс и помочь разработчикам чувствовать себя глупо (удаляя ошибки до выпуска).
Думайте о затраченных часах, а не о количестве людей. Вполне возможно, что для хорошо протестированного и «Одобренного» приложения на каждый час разработки может потребоваться час усилий по обеспечению качества. Я имею в виду именно техническую роль QA, а не функциональное тестирование. Команда QA и группа разработчиков должны иметь возможность тесно сотрудничать, чтобы группа QA могла писать тестовые примеры одновременно с разработкой. Это означает, что все должно быть записано в контракт реализации (имена функций, входные параметры и т. Д.).
Ну, это зависит от качества персонала в конце дня. Если один программист выполняет столько же работы, сколько два QA, то соотношение будет 1: 2, и наоборот. Качество персонала здесь будет №1.
Мое место работы в настоящее время составляет около 8: 1 dev: qa. Причина этого в том, что мы очень серьезно относимся к автоматическому тестированию. Вся работа должна иметь практически полное покрытие модульным тестированием. Мы также участвуем в функциональном тестировании с Fitnesse (все пользовательские истории должны иметь фитнес-тест), проверки запускают полные тестовые прогоны с CI-сервером, разработчики часто проверяют, мы часто выпускаем.
Это все в ОГРОМНОМ приложении с несколькими тысячи классов и бесчисленное количество сценариев. Преимущество - скорость, маневренность и конечно же стоимость. Независимо от того, какое дополнительное время разработчик (даже самый дорогой) тратит на написание тестов, меньше, чем человеческий капитал, связанный с наймом / управлением большим количеством сотрудников QA или поиском ошибок в производственной среде (даже сотрудники QA в конце концов - люди).
То немногое, что у нас есть QA-персонал, может тратить свое время на написание собственных автоматических тестов с помощью Selenium или участие в разработке новых функций. Они тратят сравнительно мало времени на повторение одной и той же функции снова и снова.