In organization with applied agile software development, where software life cycles are very short (i.e. two weeks), changes to the software are very frequent. Usually resources are scarce – power is expensive, test lines are constantly occupied, and hardware parts must be booked only for regression testing. In this perspective, regression testing might introduce a lot of unnecessary overhead. By comparing statistical methods and related to unsupervised machine learning methods, we discovered that due to a uniform nature of code changes, one can easily achieve 90% of bug prediction accuracy while reducing the original testing queue by 25%.
PL
W organizacji działającej w oparciu o zwinne podejście do rozwoju oprogramowania, gdzie cykle życia oprogramowania są bardzo krótkie (np. dwa tygodnie), zmiany w oprogramowaniu są bardzo częste. Zazwyczaj zasoby są ograniczone — prąd jest drogi, linie testowe są stale zajęte, a części sprzętu muszą być zarezerwowane tylko do testów regresyjnych. W tej perspektywie testy regresyjne mogą wprowadzić wiele niepotrzebnych kosztów całkowitych. Porównując metody statystyczne oraz nienadzorowanego uczenia maszynowego odkryliśmy, że dzięki jednolitej naturze zmian w kodzie, można łatwo osiągnąć 90% dokładności przewidywania błędów przy jednoczesnym zmniejszeniu pierwotnej kolejki testów o 25%.
2
Dostęp do pełnego tekstu na zewnętrznej witrynie WWW
The paper is focused on the bug fixing handling business process rather then just on fixing a bug. The tool presented here is dedicated to supporting the business process of bug fixing and not to bug fixing itself. It is addressed especially to small teams having a common testing team.
PL
Artykuł skoncentrowany jest na procesie biznesowym obsługi błędów oprogramowania bardziej niż tylko na kwestiach obsługi błędów. W konsekwencji również narzędzie zaprezentowane w niniejszej pracy służy wspieraniu procesu biznesowego poprawiania błędów, a nie samemu poprawianiu błędów. Jest ono adresowane szczególnie do małych zespołów posiadających wspólny zespół testerów.
This paper contains shorl revicvv ofthe history, present day and possible futurę of the Continuous Integration (CI) practice. It describes how the term was coined. This paper shows the increasc of the intcrest in CI ovcr the last fcw years. It looks on possible improvcments and on how does the CI pave the way for emerging methodologies like Continuous Delivery or DcvOps.
JavaScript jest wyłączony w Twojej przeglądarce internetowej. Włącz go, a następnie odśwież stronę, aby móc w pełni z niej korzystać.