Chapter 4 and 5 Group

Credits To @wezlar11

1. What is “correctness” in agile processes?
Correctness is a measure to a code that targets the level in which such code meets the specified requirements. Basically it checks if the code has the desired behavior.

2. Do TDD tests do a good job testing the software?
TDD is very good for testing the functionally of small parts of your code as you develop. However TDD will not be able to guarantee that your tests are well thought and enough.

3. Can we automate our tests without TDD?
Yes, we can create tests after the creation of our code. These tests aren’t considered as TDD but still a way of automation.

4. Can we use TDD without automating our tests?
No, the whole idea of using TDD is having the ability to automate our tests due to the fact that we don’t already have a code to test.

5. What four structures do we use for test criteria?
Input domains, graphs, logic expressions, and syntax descriptions.

6. What usually prevents our tests from achieving 100% coverage?
100% coverage does not mean it meets user expectations:Your tests could cover 100% of the code, but that does not mean that the application satisfies potential users. The application could:
  • have performance issues under load
  • have workflows that users find too awkward or too difficult to use
  • not include information users expect to see
  • be insecure or not secure enough
  • be missing functionality users want or need
  • have issues handling data outside the test data parameters
  • have memory leaks causing crashes after a period of time

100% unit test coverage does not mean integration tests will run:
If MethodA does not provide MethodB with the correct parameters, the unit tests for both could succeed where integration tests fail.

100% unit test coverage does not mean the application will run:
Unit tests run inside a harness that exercises specifically those units. It's possible to miss setting a reference to be bundled in with the deployment package and have an application with 100% unit test coverage (all passing) that can't run.

100% coverage does not prevent display issues:
You can run into display issues when the user's screen size isn't what you expected, or the user runs the application on a system that doesn't have the fonts you used, or doesn't use the same encoding as you. These are not things that get caught with unit tests - or integration tests, or most automated functional tests for that matter.

100% coverage is not 100% path coverage:
Most applications have an infinite or near-infinite number of paths through the application. It's not practical to test for a user opening and closing a screen ten times before they start entering data, then 11 times, then 12, then... It's not practical to test using the back and forward browser buttons in every possible combination while entering data.

Test coverage only catches what's been coded:
You can't test functionality that hasn't been implemented. If an error scenario isn't coded for, it can't be covered in test cases - but an experienced tester could realize it's not there.

7. Some organizations in industry who adopt TDD report that it succeeds very well, and others report that it fails. Based on your knowledge of TDD and any experience you have, why do you think it succeeds sometimes but not all? 

Code complexity or the Architecture of the code.

8. A few software organizations use test criteria and report great success. However, most organizations do not currently use test criteria. Based on your knowledge and experience, why do you think test criteria are not used more?

Because test criteria can change over the course of projects and because they're very subjective, it depends on the developers, clients, company, and other things.


Comments

Post a Comment

Popular posts from this blog

Chapters 6.1 & 6.2

Image
Credits to @4vid Image Link 1. What two properties must be satisfied for an input domain to be properly partitioned?  Completeness: The partition must cover all of the domain. Disjoint: blocks should not overlap 2. What is an Input Domain Model (IDM)? Two Approaches to Input Domain Modeling: A. Interface-based approach. 􏰀 Develop characteristics directly from individual input parameters. 􏰀 Just use properties of the domains without considering the actual function under test. B. Functionality-based approach 􏰀 Develop characteristics from a behavioral view of the program under test. 􏰀 Use your understanding of what the system should do. 3. What gives more tests, each choice coverage or pair-wise coverage? Each Choice Coverage (ECC) states that one value from each block for each characteristic must be used in at least one test case. For example, for partitions [A, B] [1, 2] we can get [A, A], [B, B], [1, 1] and [2, 2] which are clearly redundant. Pair-
Read more

Final Exam Questions

1. Software fault: static error in the code. Software error: internal, not a normal behavior of the program due to a fault. Software failure: external, visible failure of the program. That it doesn't work basically. 2. Beizer discussed the goals of testing in terms of the “test process maturity levels” of an organization, where the levels are characterized by the testers’ goals. Level 0: Testing and debugging are the same. (Worst level) Level 1: Testing is only to find that your code doesn't work. Level 2: Get defensive or make an issue personal with testers because they broke your code. Level 3: Understand the job of a tester and take feedback as constructive criticism. Level 4: Become an expert software tester and make extreme good quality software. Work in harmony with testers. 3. Static Code Analysis is usually performed as part of a Code Review (also known as white-box testing). is a method of debugging by examining source code before a program is run . It’s done by ana
Read more

Course evaluation

Image
Credits to @rossf Image Link ECOA Evidence  I've been Ken Bauer's student for almost four years in several different courses, and his teaching method has always been a breath of fresh air. From flip learning to almost conventional teaching (since you grade your own exam) he's not afraid to make changes and give students the chance to explore self learning and to take responsibility on when and how they learn the content of the course. This is a skill that is very important acquire and that is needed on a daily basis in every job in the tech field. Personally i enjoyed the Software Quality and Testing course. There are many students that might not like this method of teaching applied on this course because it requires them to take responsibilities on their own learning and some students can't handle this type of control over their own learning. No negative feedback for this course, only that maybe some classes should be online.
Read more