Tôi đang tìm kiếm cả giải thích lý do tại sao và khi nào bạn sẽ sử dụng từng hệ thống và những tính năng nào phân biệt lỗi so với ứng dụng theo dõi vấn đề.Sự khác biệt giữa theo dõi lỗi và hệ thống theo dõi vấn đề là gì?
Hệ thống theo dõi vấn đề thường tích hợp nhiều hơn với khách hàng và các vấn đề của khách hàng. Một vấn đề có thể là "giúp tôi cài đặt" hoặc "Làm cách nào để đưa fubar vào flam flam." Họ thậm chí có thể là một cái gì đó như "Tôi cần một chìa khóa đánh giá cho phần mềm của bạn".
Hệ thống theo dõi lỗi giúp bạn theo dõi những thứ sai hoặc thiếu trong chương trình.
Khi xem xét hệ thống web, thường có sự khác biệt lớn về tiêu điểm, giúp khách hàng hoặc theo dõi sự cố với phần mềm của bạn.
Trong khi sự khác biệt là đúng, tôi đã thấy các hệ thống theo dõi lỗi được sử dụng như hệ thống theo dõi vấn đề và ngược lại. Sử dụng nó theo cách "sai" thường dẫn đến trải nghiệm tối ưu. –
Tôi tin rằng một lỗi là một thứ có thể được sửa trong mã, trong khi vấn đề là một vấn đề với khả năng sử dụng.
Ví dụ: biểu mẫu đăng nhập. Lỗi trong biểu mẫu đăng nhập sẽ là biểu mẫu chuyển hướng không chính xác sau khi đăng nhập hoàn tất. Mặc dù vấn đề là quy trình đăng nhập tổng thể quá chậm hoặc không có tùy chọn gửi email mật khẩu bị quên.
chỉ là ngữ nghĩa. Một lỗi là một vấn đề, một vấn đề là một cái gì đó để làm. Chúng khác nhau nhiều.
seconded: bug == issue == vấn đề cần được sửa – hometoast
-1, hệ thống theo dõi vấn đề thực sự phục vụ một mục đích khác với hệ thống theo dõi lỗi, xem nhiều câu trả lời tuyệt vời khác. – molf
Tôi không nghĩ rằng ngữ nghĩa của nó ... Bạn có thể được yêu cầu sửa lỗi 1, 2 và 5 trong khi bạn gặp phải vấn đề mới khi cơ sở dữ liệu bị hỏng. Một vấn đề có thể là một lỗi hoặc hai, nhưng không giống nhau ... – RSolberg
'Đường mờ của nó ở mức tốt nhất. Hệ thống theo dõi vấn đề có lẽ sẽ được coi là tổng quát hơn của cả hai. Trong đó tất cả các hệ thống theo dõi lỗi đều là hệ thống theo dõi vấn đề, nhưng không nhất thiết là ngược lại.
Từ bạn bè của chúng tôi Wikipedia
Một hệ thống theo dõi lỗi là một ứng dụng phần mềm được thiết kế để giúp đảm bảo chất lượng và lập trình viên giữ dõi các lỗi phần mềm báo cáo trong công việc của họ. Nó có thể được coi là một loại hệ thống theo dõi vấn đề .
Kiểm tra nhận xét từ Người bạn chung của chúng tôi: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems "Trang này chứa cả vấn đề và hệ thống theo dõi lỗi. Sự khác biệt này không chắc chắn trong một số trường hợp, vì vậy hãy xem danh mục khác như khi thiếu mục nhập. " – Aardvark
@Aardvark, @ Matthew, ngừng trích dẫn một nửa tài liệu hoàn chỉnh mà chúng tôi phải chỉnh sửa. Trích dẫn trực tiếp trích dẫn thực tế mà Wikipedia đã sử dụng. – Pacerier
@Pacerier bạn nhận ra điều này đã được trả lời trong năm 2009? Tại thời điểm này, bạn nên sửa câu trả lời này nếu bạn cảm thấy nó không đáp ứng các tiêu chuẩn của bạn. – Aardvark
Một lỗi được tìm thấy trong mã
Một vấn đề có thể được tìm thấy ở bất cứ đâu, trong quá trình, trong phần cứng, trong nhân dân.
Điều đó phụ thuộc vào quy trình phát triển bạn đang áp dụng như ý nghĩa của các định nghĩa.
Không chắc chắn, nếu mọi người có thể đăng nhập các vấn đề liên quan đến mọi người :) – shahkalpesh
Tất nhiên họ có thể, Nếu nhà phát triển không tuân thủ các tiêu chuẩn mã hóa do công ty đặt ra, họ trở thành một vấn đề và rủi ro dự án. – Peter
@Peter, Đó là không có gì sai gọi là * vấn đề * với ai đó là "lỗi". – Pacerier
Đây không thực sự là câu trả lời hoàn chỉnh cho câu hỏi của bạn, nhưng tôi đã có những câu hỏi tương tự đến với giao dịch với khách hàng. Tôi nghĩ ở cấp độ cao nhất, một hệ thống theo dõi lỗi có vẻ thường tập trung hơn vào nhà phát triển. Đó là, các nhà phát triển đang cố gắng theo dõi các vấn đề trong mã. Hàm không trả lại giá trị phù hợp, bạn nên thực hiện thêm xác thực, v.v.
Ví dụ về hệ thống tích hợp độc đáo với mã là Trac.
Hệ thống theo dõi vấn đề dường như tập trung vào khách hàng hơn. Ví dụ, có thể có một khách hàng nói "Khi tôi nhấp vào" OK "Tôi nhận được một lỗi". Nó có thể được đào tạo người dùng, nó có thể là một tính năng, hoặc nó có thể trong thực tế là một lỗi.
Vì vậy, trong nhiều dự án mà tôi đã làm việc, chúng tôi giữ những điểm khác biệt này. Chúng tôi có một hệ thống theo dõi vấn đề cấp cao có thể có hoặc không dẫn đến lỗi thực sự được tạo trong hệ thống theo dõi lỗi. Tuy nhiên, nhiều lỗi được theo dõi nội bộ mà không có bất kỳ "vấn đề" nào được tạo trong hệ thống theo dõi vấn đề.
Vấn đề mà tôi thấy giữa hai điều này là thực sự không dễ dàng cho người dùng thiếu kinh nghiệm để nhập vé vào một cái gì đó như Trac vì họ bị nhầm lẫn bởi lingo kỹ thuật. Tuy nhiên, một hệ thống theo dõi vấn đề cấp cao không tích hợp chặt chẽ với mã nên nó vô dụng đối với các nhà phát triển.
Dù sao ... $ 0,02 của tôi.
Heh, Trac tự gọi mình là một hệ thống theo dõi vấn đề (so với lỗi). – Aardvark
hệ thống theo dõi lỗi như Trác được thiết kế để có một vé cho mỗi vấn đề nội tại đối với chương trình, do đó, một vé được đóng bằng cách sửa đổi chương trình.
hệ thống vé hỗ trợ khách hàng như IssueTrackerProduct được thiết kế để có một vé cho mỗi khách hàng trải qua một tình huống, do đó, một vé được đóng bằng cách làm việc ra tình hình cho khách hàng đó (có thể bằng cách thay đổi chương trình).
Đối với ví dụ về mỗi, xem Wikipedia Comparison of issue tracking systems
Bugs là đặc trưng cho các nhà phát triển phần mềm. Các vấn đề tổng quát hơn và có thể bao gồm tất cả tiến trình của thành viên nhóm trong dự án, bao gồm các nhà thiết kế đồ họa, quản trị viên hệ thống, giám đốc điều hành công ty, v.v.
Trình theo dõi vấn đề nói về điều cần làm và có thể phân loại mục dưới dạng lỗi Nếu cần thiết.
Đó chỉ là những từ ngớ ngẩn, nhưng tôi sử dụng "trình theo dõi vấn đề" khi làm việc với nhiều người không phải là lập trình viên, và chúng ta cần nói một ngôn ngữ chung. nhau đang làm.
Bạn có thể sử dụng trình theo dõi lỗi nhưng nó sẽ chỉ gây nhầm lẫn cho các nhà phát triển không, đặc biệt nếu họ phải nghĩ về nhiệm vụ của mình như là một lỗi.
Tôi có thể nói rằng việc tạo sự khác biệt giữa lỗi và vấn đề đối với người lập trình, vì lỗi thường là vấn đề với mã hiện có và các vấn đề có thể là yêu cầu tính năng mới.
Sự khác biệt có thể rõ ràng hơn từ ví dụ sau.
Giả sử bạn có vấn đề về sản xuất ngày hôm nay đã ảnh hưởng đến 5 khách hàng, nhưng do một lỗi phần mềm đơn lẻ gây ra.
Trong hệ thống -tracking vấn đề của bạn, bạn đã mở 5 vé và bắt đầu theo dõi những gì mỗi khách hàng được báo cáo, những gì đã thông báo cho chúng, khi các bản vá phần mềm được áp dụng, vv Bạn có thể theo dõi mà loại công cụ riêng cho từng khách hàng.
Trong lỗi hệ thống -tracking của bạn, bạn đã thực hiện 1 entry cho lỗi phần mềm bắt đầu theo dõi những thứ như các bước để tái sản xuất, thay đổi mã vv
vấn đề khách hàng có thể được đóng bất cứ khi nào họ đang khắc phục với sự hài lòng của khách hàng và có thể có hoặc không liên quan đến việc sửa chữa phần mềm.Lỗi có thể được đóng khi nó được cố định và kiểm tra lại.
Hai hệ thống, hướng ra ngoài và hướng vào bên trong, theo dõi hai loại thứ khác nhau, mỗi loại có vòng đời riêng.
+1 để nhận biết rằng các vấn đề được tạo ra mỗi lần khách hàng/người dùng báo cáo sự cố và việc giải quyết vấn đề không ngụ ý sửa lỗi trong phần mềm. – molf
Có một nơi để đọc về kiểu theo dõi vấn đề này không? Nơi làm việc hiện tại của tôi cần một số công việc về cách xử lý tất cả những điều này và tôi muốn thu thập thông tin về cách quản lý tốt hơn các vé như thế này. –
@azheglov, tôi không hoàn toàn bị thuyết phục bởi lời giải thích của bạn. Làm thế nào bạn sẽ biết trước rằng những vấn đề 5 * * chia sẻ cùng một lỗi? Ngoài ra, làm thế nào bạn sẽ biết trước khi hai lỗi khác nhau thực sự là một và giống nhau? – Pacerier
Tôi không nghĩ rằng có một câu trả lời dứt khoát, nhưng tôi thường chỉ nghĩ về theo dõi vấn đề chỉ là một thuật ngữ chung chung hơn tương ứng với nhiều hơn là chỉ "lỗi". Để chỉ sử dụng thuật ngữ "Theo dõi lỗi" là loại lỗ chim bồ câu, được kết hợp với lỗi trong phần mềm.
Trình theo dõi vấn đề không nhất thiết phải liên kết với phần mềm và thậm chí BugZilla không theo dõi chỉ lỗi, mà còn yêu cầu cải tiến/tính năng mới, phiếu bầu, v.v. "vấn đề" chỉ là một mục quan tâm mà ai đó muốn "hoàn thành".
Gần đây cũng có sự gia tăng theo dõi mục công việc (ví dụ: Visual Studio và IBM/Rational Jazz), mức thấp hơn "vấn đề" - trong đó vấn đề có thể được xem là yêu cầu một số số hạng mục công việc nhỏ hơn hoàn thành. Ở cấp độ cao hơn, bạn cũng có thể thấy điều gì đó giống như một số Milestone trong số BugZilla.
"Theo dõi mục công việc", cụm từ ... – Pacerier
Vâng ... không có sự khác biệt ngoài thực tế, rằng một vấn đề không chỉ là lỗi. Nó có thể là một nhiệm vụ, một tính năng mới, hoặc đơn giản là một sự cải tiến. Một lỗi chủ yếu được xem là hành vi hệ thống không chính xác, trong khi một vấn đề có định nghĩa rộng hơn. ngoài chỉ là "nó không hoạt động" ...
Bugs: sai sót bất cứ nơi nào trong quá trình (ứng dụng, cơ sở dữ liệu, báo cáo, vv) mà sẽ ngăn chặn 100% các chức năng mong muốn xảy ra. Còn được gọi và được gọi là khuyết tật.
vấn đề: có khả năng gây ra bởi một lỗi hoặc lỗi, một vấn đề là một báo cáo của một số hình thức mất chức năng trong hệ thống đó sẽ được gắn với một người sử dụng. Đây cũng được gọi là vé bàn trợ giúp trong một số tổ chức.
Một lỗi là một lớp con của vấn đề. Tất cả các lỗi là vấn đề, nhưng không phải tất cả các vấn đề đều là lỗi.
Thông thường lỗi là lỗi trong bộ mã. Điều này khác với tính năng chưa hoàn thành/chưa được triển khai hoặc khó khăn hơn để ghim xuống như nhà phát triển đặt vé để xử lý khoản nợ kỹ thuật hoặc lo ngại về giao diện người dùng. Tất cả những điều này là 'vấn đề' nói theo ngữ nghĩa.
Một vấn đề chung, khi không thuộc các danh mục khác, thường không phải là đại diện cho nội dung được báo cáo bởi người dùng cuối. Trong hầu hết các hệ thống, vấn đề được báo cáo này được xử lý dưới dạng báo cáo lỗi. Tôi muốn mạo hiểm để nói rằng đây là một sai lầm.
Phần khó khăn là đôi khi nhiều vấn đề có thể liên quan đến các vấn đề khác. Nó có thể liên quan đến cùng một lỗi, nhiều lỗi, hoặc thực sự là một yêu cầu tính năng. Đó là để nói, có thể có một mối quan hệ nhiều-nhiều giữa các vấn đề.
Tại sao sự khác biệt lại quan trọng?Vâng, có một cây tự nhiên trong nội bộ - Giải quyết một vấn đề có thể gián tiếp hoàn thành (hoặc đóng góp để hoàn thành) một triệu vấn đề khác. Nó cũng tạo sự khác biệt trong cách giải quyết vấn đề. Bản thân các lỗi có thể được giải quyết bằng một thay đổi mã sửa lỗi hoặc làm cho nó không liên quan. Nếu đó là một khiếu nại của người dùng, nó có thể được giải quyết bằng cách gửi cho họ một công việc xung quanh, và sau đó còn lại để được theo dõi khi lỗi ban đầu được giải quyết.
Tính năng hoạt động tốt hơn khi đại diện và làm việc với các sắc thái này theo cách hữu ích thực sự là những gì cần tìm trong hệ thống theo dõi vé.
Tại một thời điểm nào đó, bạn đang nói về các quy trình và phương pháp hơn hệ thống bán vé thực tế và tên thực tế của mọi thứ sẽ bắt đầu trở nên không liên quan. Các giải pháp chính và doanh nghiệp định hướng có xu hướng chạy trên một hệ thống phổ biến như ITIL, nhưng bạn có thể lấy đi những thứ adhoc cung cấp cho mọi người trong nhóm có hiểu biết tốt về nhu cầu dịch vụ khách hàng. Cá nhân tôi thấy nó là một tình huống waterfall (ITIL) vs agile (DevOps).
Về đoạn cuối cùng thứ hai của bạn, phần mềm nào * bạn * sử dụng? – Pacerier
@Pacerier Tôi thường có hai quy trình công việc khác nhau trong Trello - một cho các vấn đề về người dùng được thiết lập giống như một hệ thống trợ giúp CNTT điển hình và một cho vé dev nội bộ dưới dạng scrumban - sử dụng tự do khả năng liên kết của nó. Tôi cũng tự động hóa một số thứ với một số công cụ tùy chỉnh bằng cách sử dụng zapier để tôi có thể nhận báo cáo lỗi từ biểu mẫu và kéo các vấn đề github khi cần hoặc đẩy dữ liệu phân tích tới bảng tính để xử lý sau này. Tôi đã thấy những điều tốt đẹp được thực hiện với Autodesk, Team Foundation Server, Freshdesk và Jira. –
Trello không phải là ứng dụng theo dõi lỗi "thực"? – Pacerier
Để trả lời câu hỏi này, nó yêu cầu ngữ cảnh và từ giao diện của câu trả lời của Alan là bối cảnh của bạn.
Trong thế giới của kiểm thử phần mềm, một trong những sự phân biệt chúng ta thực hiện giữa một vấn đề và một lỗi là: lỗi là bất cứ điều gì đe dọa đến giá trị của sản phẩm khi vấn đề là bất cứ điều gì đe dọa về giá trị của thử nghiệm (hoặc giá trị của dự án và đặc biệt là giá trị của thử nghiệm).Rapid Software testing dạy chúng tôi điều đó.
Theo kinh nghiệm của tôi, hệ thống theo dõi cho phép bạn tạo bất kỳ sự khác biệt nào bạn muốn giữa hai hệ thống. Cách bạn sử dụng một hệ thống theo dõi cụ thể tùy thuộc vào bạn.
Cảm ơn Chris về một liên kết tốt đẹp thảo luận về vấn đề này, cũng bao gồm một số thông tin về SBTM. –
Một được sử dụng bởi những người muốn âm thanh enterprisey. – cgp
không có gì ngoài quan điểm, IMO. Lỗi từ là một chút khả nghi và theo định nghĩa không bao gồm theo dõi 'các tính năng' hữu ích, do đó các vấn đề là IMO tốt hơn. – kenny
"Lỗi" là từ cụ thể hơn, nội tạng hơn là "vấn đề". "Vấn đề" là một từ đáng sợ khiến mọi người cảm thấy thoải mái về những sai lầm của họ. Khi nghi ngờ, hãy đi với từ tiếng Đức, ít Latinh hơn. "Theo dõi lỗi" ftw. – Nosredna