Web Application Testing Session 5 May 2023

Introduction to Testing Types and Order of Execution

In this session, the focus is on discussing different testing types and their order of execution. The goal is to understand the sequence in which each type should be performed.

Understanding Testing Types and Order of Execution

• Different testing types will be discussed and organized in a logical order for execution.

• The importance of cross-browser testing will also be explored, along with tools that can be used for this purpose.

• The bug life cycle will be reviewed, emphasizing the significance of properly documenting bugs.

• Opening bug tickets is essential for building a collection of bugs found in the application, which can be showcased during interviews.

• Practice with executing test cases from someone else's project will be assigned, using remote browsers for testing.

• Building a video library by recording screen activities and sharing them on platforms like YouTube and Slack will help in future reference.

• A big homework assignment will also be given, due in the next session.

Writing About Your Project

This section focuses on preparing for job interviews by writing about your project experience.

Writing About Your Project

• Use a Google form provided to write about your project experience.

• The answer should include a description of the project itself (mobile or web-based), its purpose, and target audience.

• Highlight important features tested within the app to give interviewers an understanding of your domain expertise.

• Explain how you approached testing, including any test documentation created such as accessibility matrices or test cases derived from user stories and acceptance criteria.

Timestamps are not available for some parts of the transcript.

Final Draft and API Testing

In this section, the instructor advises against considering the current draft as the final version for clearance. They mention that there are still tasks related to API testing and SQL sessions about working with databases that need to be completed.

Working on the Draft

• The instructor suggests starting work on a solid draft that will later include experience with API testing.

• The Open Circle project will involve working at both the API level and SQL level, providing an opportunity to gain more insights into backend development.

• It is recommended to focus on tools already familiar with and consider including any bugs found in the project.

Collecting Emails for Assignment

The instructor explains why they are collecting emails for a specific assignment and how it relates to sharing answers among participants.

• For this particular assignment, emails are being collected because answers will be shared only with those who have submitted their own stories.

• Participants who submit their stories will receive answers from their classmates as well as their own.

• If someone does not submit their story, they will not receive answers from others.

• Even if watching a recording of the class at a later time, participants can still submit their story by contacting the instructor.

Submitting Homework and Contacting Instructor

The instructor provides instructions on submitting homework after watching a recording of the class and emphasizes the importance of providing an email address for communication purposes.

• Participants can submit homework even after watching a recorded class session by contacting the instructor directly.

• If someone needs assistance or did not receive something, they should provide their email address so that communication can take place effectively.

• Any questions regarding homework or assignments can be addressed during future classes.

Importance of Assignments

The instructor emphasizes the significance of completing assignments and explains that certain assignments have specific deadlines.

• The instructor highlights the importance of completing assignments, even if some can be done at a later time.

• Although some assignments may have flexible deadlines, there are specific due dates for certain tasks such as test execution and remote browser homework.

Reviewing Bike Tickets

The instructor discusses reviewing bike tickets in the project and ensuring they contain all necessary information.

• The instructor plans to review bike tickets in the project to assess their clarity and completeness.

• It is important to ensure that all bike tickets include the three W's: who wants it, what they want, and why they want it.

• Some tickets may already be in progress or fixed, while others may require verification.

Ticket Types

The instructor explains the different types of tickets in the project, including stories, tasks, improvements, and suggestions.

• In the project, there are four types of tickets: backlogs (stories), tasks, improvements (also known as suggestions), and bugs.

• Stories represent new functionalities from a user perspective.

• Tasks are smaller items that need to be completed.

• Improvements/suggestions refer to smaller changes or enhancements.

• Bugs are issues or problems identified in the project.

User Stories

The instructor provides an explanation of user stories and emphasizes their importance in evaluating functionality needs.

• User stories are written from a user's perspective to evaluate whether a particular functionality is needed or not.

• User stories should address three key questions: who wants it, what they want, and why they want it.

• If any of these three parts is missing from a user story, it cannot be considered complete.

Timestamps were used wherever available.

Understanding the Purpose of Different Apps

The speaker discusses the importance of having different apps for different purposes, using the example of a shopping app like Amazon. They emphasize that certain features, such as a profile picture, may or may not be relevant depending on the context.

Multiple Apps and Contextual Relevance

• Different apps serve different purposes and have varying functionalities.

• Features like profile pictures may or may not be necessary in certain apps.

• Context plays a crucial role in determining which features are relevant.

Evaluating Requirements with Stories Format

The speaker explains how the stories format helps in evaluating requirements and deciding whether to implement them or not. They also discuss the concept of improvement tickets and their purpose.

Stories Format for Requirement Evaluation

• Stories format aids in assessing requirements' feasibility and relevance.

• Improvement tickets focus on enhancing existing features rather than implementing new ones.

• Improvement tickets typically consist of two main points: current implementation and suggested implementation.

Structure of Improvement Tickets

The speaker thanks Marta for creating an improvement ticket and discusses the format of such tickets. They highlight that improvement tickets are more flexible compared to bug tickets, allowing for a free-form approach.

Free-form Format of Improvement Tickets

• Improvement tickets do not require strict step-by-step instructions.

• Steps to reproduce are only necessary for bug tickets.

• Improvement tickets should address two main points: current implementation and suggested implementation.

Describing Current Implementation and Suggested Implementation

The speaker explains how to describe current implementation and suggested implementation within an improvement ticket. They provide an example using an "Update Item Title" ticket.

Describing Current Implementation vs. Suggested Implementation

• Use separate columns for current implementation and suggested implementation.

• Describe the current implementation in the corresponding column.

• Describe the suggested implementation in the respective column.

Defining Expected Results and Actual Results

The speaker discusses the concept of expected results and actual results within improvement tickets. They explain how to determine expected results and who to consult for clarification.

Understanding Expected Results

• Expected results are based on requirements or user expectations.

• If requirements are unclear, consult a product manager or owner for clarification.

• Product managers/owners may not always have immediate answers but can guide further discussions or open a ticket for backlog refinement.

Consulting Product Managers/Owners for Clarification

The speaker emphasizes the importance of consulting product managers/owners when unsure about expected functionality. They explain that product owners have a sense of ownership and responsibility for guiding development.

Consulting Product Managers/Owners

• Product managers/owners provide guidance on expected functionality.

• They may not always have immediate answers but can initiate discussions or create backlog refinement tickets.

• Their role is to ensure clarity and alignment with product goals.

Differentiating Improvement Tickets from Bug Tickets

The speaker highlights the difference between improvement tickets and bug tickets. They clarify that improvement tickets focus on enhancing existing features, while bug tickets address mismatches between expected and actual results.

Improvement Tickets vs. Bug Tickets

• Improvement tickets aim to enhance existing features.

• Bug tickets address mismatches between expected and actual results.

• Improvement tickets do not necessarily involve expected vs. actual results comparison.

Example of an "Update Album Title" Improvement Ticket

The speaker provides an example of an improvement ticket related to updating album titles. They demonstrate how to structure such a ticket by describing current implementation and suggesting improvements.

Example: "Update Album Title" Improvement Ticket

• Current implementation: No way to update album titles.

• Suggested implementation: Implement the ability to update album names.

• Improvement tickets focus on suggesting solutions rather than stating problems.

Ability to Update and Delete Items

The speaker discusses the importance of being able to update and delete items. They mention that while deleting may not always be possible, deactivating or disabling an item is a common approach.

Updating and Deleting Items

• Being able to update items is essential for maintaining accuracy and relevance.

• Deleting items may not always be possible; deactivating or disabling them is a common alternative.

• Users often expect the ability to modify or remove their own content.

Checking Other Bug Tickets and Charts

The speaker mentions checking other bug tickets and charts for further information or issues related to the topic discussed.

Further Investigation: Bug Tickets and Charts

• Additional bug tickets may provide more insights or related issues.

• Checking charts can help identify trends or patterns in reported bugs.

Timestamps are approximate and should be verified with the actual video.

Creating a Filter for Bug Tickets

The speaker discusses the need to create a filter for bug tickets and mentions the difficulty of doing it solely through the UI. They suggest looking at past tickets marked as fixed to gather information.

Creating a Filter with Specific Criteria

• It is suggested to create a filter that excludes bug tickets, improvements, and other categories.

• The speaker recommends using negative criteria in the filter.

• They mention that using basic search might be easier but creating a filter allows for more specific criteria.

Reviewing Back Tickets

The speaker suggests reviewing back tickets to find examples of fixed issues and gather information for creating filters.

Reviewing Fixed Issues

• The speaker suggests reviewing back tickets to find examples of issues that have been marked as fixed.

• This can provide insights into how certain issues were resolved in the past.

Example of an Unmasked Password Field

The speaker provides an example of an issue related to an unmasked password field and explains how they discovered it using Dev tools.

Example of Unmasked Password Field Issue

• On the first page, the password field was not masked.

• Navigating to the login page, they found that the password value was correctly masked.

• They used Dev tools to identify that the password field was implemented as type "text" instead of "password."

Renaming Ticket and Verifying in Version Two

The speaker suggests renaming a ticket related to an unmasked password field on the first page. They also mention verifying the issue in version two.

Renaming Ticket and Verification

• The speaker suggests renaming the ticket from "first page" to something more specific, like "login page."

• They mention the need to verify the issue in version two.

• The speaker plans to close their duplicate ticket and advises against creating duplicate tickets.

Opening Tickets and Avoiding Duplicates

The speaker emphasizes the importance of avoiding duplicate tickets and suggests checking if an issue has already been reported before opening a new ticket.

Avoiding Duplicate Tickets

• The speaker warns against creating duplicate tickets at work.

• They suggest checking if someone else has already reported and opened the same issue before opening a new ticket.

• Opening duplicate tickets can cause issues during bug ticket reviews.

Back Triage Meetings

The speaker mentions back triage meetings where teams come together to review bug tickets, determine priority, and discuss other related matters.

Back Triage Meetings

• Back triage meetings involve reviewing bug tickets as a team.

• During these meetings, teams determine whether an issue is a bug or not and discuss its priority.

• These meetings help ensure efficient bug ticket management.

Updating Issue Type for Improvement Ticket

The speaker discusses updating an improvement ticket related to email field character limit based on a suggestion from Dimitri. They emphasize the need for supporting arguments in improvement tickets.

Updating Improvement Ticket

• Dimitri suggests increasing the character limit of the email field from what is currently specified in requirements.

• The speaker asks Dimitri to provide more information and reasoning behind this suggestion.

• They stress that improvement tickets should have supporting arguments based on guidelines or best practices, rather than simply following competitors' approaches.

Justifying Improvement Ticket Suggestions

The speaker emphasizes the importance of providing solid justifications for improvement ticket suggestions and encourages referencing reliable sources.

Providing Justification for Improvement Tickets

• The speaker mentions the need to build arguments when opening improvement tickets.

• They suggest referring to human interface guidelines, best practices, or other reliable sources.

• Simply stating that competitors are doing something is not a sufficient justification.

Maximum Email Length and Argumentation

The speaker discusses the maximum length of email addresses and the importance of providing well-reasoned arguments in improvement tickets.

Maximum Email Length

• The speaker explains that there is no absolute maximum length for email addresses.

• They mention that domain names can contribute to exceeding character limits.

• It is important to provide strong arguments when suggesting changes in improvement tickets.

Adding Details to Improvement Tickets

The speaker emphasizes the need for adding more information and details to improvement tickets if they lack sufficient context or explanation.

Adding Information to Improvement Tickets

• If an improvement ticket lacks details, it may be requested to add more information.

• This applies both at work and during M28 sessions.

• Insufficiently detailed tickets may require rewriting or further clarification.

Summary Clarity Check

The speaker asks for feedback on whether the summary provided is clear and understandable without having to read the entire back ticket.

Checking Summary Clarity

• The speaker asks if everyone understands the summary provided without needing to open the full back ticket.

• Feedback on clarity is requested from the audience.

Understanding Spare Requirements

In this section, the speaker discusses spare requirements and their implications in relation to a joint Circle page.

Spare Requirements

• The speaker mentions that spare requirements are not explicitly stated because they are normally implied.

• By meeting the spare requirements, the need to mention them in every ticket can be avoided.

Password Field Acceptance Criteria

This section focuses on the acceptance criteria for the password field and how it relates to spare requirements.

Password Field Acceptance Criteria

• The speaker explains that if the password field accepts more than 20 characters, it exceeds the limit specified in the requirements.

• The spare requirements refer to what can be omitted or skipped.

• The speaker suggests closing this issue as it is not a bug but rather an adherence to the spare requirements.

Clear Steps and Login Page

Here, the speaker emphasizes being careful with steps and clarifies when logging in is necessary.

Clear Steps and Login Page

• The speaker advises being cautious with step descriptions, particularly regarding login steps.

• If logging in is required for a specific action, such as entering a password, it should be mentioned explicitly.

• Instead of stating "log in," specifying "navigate" or "open login page" would be more appropriate.

Password Field Limitations

This section addresses limitations related to the password field and its character limit.

Password Field Limitations

• It is mentioned that currently, there is no limitation on the password field's length.

• However, this issue is acknowledged as a work in progress and will eventually be fixed.

• Verification of this aspect will be possible once it has been resolved.

Special Characters Acceptance

The speaker discusses the acceptance of special characters and clarifies the distinction between not required and disallowed.

Special Characters Acceptance

• The requirements state that special characters are not required but do not explicitly mention their disallowance.

• The speaker explains that not requiring special characters does not mean they should be rejected.

• As it aligns with the requirements, this issue is considered a non-bug and can be closed.

Maximum Length for Name Field

This section highlights an issue regarding the maximum length for the name field.

Maximum Length for Name Field

• It is observed that there is no explicit indication of the maximum length for the name field.

• However, when attempting to submit a form with more than 32 characters, an error message is received.

• This discrepancy between expected behavior and actual results indicates a bug in limiting the field's length.

Bug Ticket Status: Design

Here, the speaker addresses ticket statuses and designating bugs as "designed."

Bug Ticket Status: Design

• The bug ticket related to the name field exceeding its maximum length can be marked as "designed."

• By setting it as designed, it implies that this issue has been acknowledged and will be resolved accordingly.

User Stories: Maximum Length for Name Field

This section focuses on user stories related to setting a maximum length for the name field.

User Stories: Maximum Length for Name Field

• There are user stories concerning setting a maximum length for the name field.

• However, specific details about how this limitation should be implemented are missing.

• This lack of clarity indicates a bug in properly restricting input beyond the specified limit.

Error Messages and Input Validation

The speaker discusses the importance of error messages and input validation to prevent mistakes.

Error Messages and Input Validation

• It is noted that although error messages are displayed when exceeding the name field's limit, it would be more effective to prevent input beyond the limit.

• The speaker suggests opening an improvement ticket for this issue.

• A link to a session by Michael about bug ticketing is shared as a resource for further information.

Generating Text for Fields

This section introduces a method for generating text for fields instead of manually counting characters.

Generating Text for Fields

• To simplify testing web-based applications, the speaker recommends using tools that generate text based on specified requirements.

• By utilizing such tools, developers can easily generate strings of desired lengths without worrying about character counts.

Conclusion and Additional Resources

The speaker concludes by summarizing the discussed issues and providing additional resources.

Conclusion and Additional Resources

• Three main issues have been identified in the tickets: spare requirements, password field limitations, and maximum length for the name field.

• The speaker emphasizes that bugs should be opened only if they contradict written requirements.

• A link to a session by Michael on bug ticketing is shared as a valuable resource.

Login Page Issue

The user encounters an issue with the login page where they receive a wrong message for the password. They discuss the importance of having clear summaries in tickets and suggest recording videos to demonstrate steps instead of relying on written instructions.

Clarifying Summary in Tickets

• It is unclear from the summary alone what the issue is, so it is necessary to check the ticket for more details.

• Clear summaries are important during triage meetings to save time and avoid opening each ticket individually.

Recording Videos for Demonstrating Steps

• Instead of relying solely on written instructions, it is suggested to record videos that show the steps involved.

• Videos should start closer to the relevant moment rather than from the beginning of an action or process.

• This helps team members quickly understand issues without having to read lengthy descriptions.

Importance of Clear Summaries

The importance of clear summaries in tickets is further discussed, emphasizing that titles should be informative and imply a summary. A specific example of a login page issue with an incorrect password message is examined.

Clear Summaries and Video Attachments

• Clear summaries are crucial as people often prefer not to read lengthy descriptions.

• Video attachments can provide a visual demonstration of steps, making it easier for team members to understand issues.

Example: Incorrect Password Message

• The example ticket describes an issue with receiving an incorrect password message on the login page.

• The expected result is mentioned, but there are no specific details about what exactly went wrong.

Improving Ticket Summaries

The need for improving ticket summaries is emphasized, particularly when reviewing multiple tickets during triage meetings. Suggestions are made regarding how to enhance clarity and efficiency in communication.

Importance of Clear Ticket Summaries

• Clear ticket summaries save time during triage meetings when reviewing multiple tickets.

• People prefer videos over reading lengthy instructions, so clear summaries and video attachments are beneficial.

Enhancing Clarity in Summaries

• Summaries should clearly state the steps involved, such as navigating to the login page and entering the wrong password.

• Including expected results in the summary helps team members quickly understand the issue.

Recording Videos from Relevant Moments

The importance of recording videos from relevant moments is discussed. It is suggested that videos should not start from the beginning but rather focus on specific actions or processes.

Recording Videos for Issue Demonstration

• Videos should be recorded from relevant moments instead of starting from the beginning.

• Starting a video from logging into an application may not be necessary if the issue occurs later in the process.

• This approach saves time and provides a more focused demonstration of the problem.

Benefits of Video Attachments

The benefits of using video attachments in tickets are highlighted, including improved clarity, reduced reading effort, and better understanding during triage meetings.

Advantages of Video Attachments

• Video attachments provide a visual demonstration of steps, reducing reliance on written instructions.

• Team members can quickly review videos during triage meetings to understand issues without spending excessive time reading descriptions.

• In today's fast-paced environment, people prefer watching videos over reading lengthy text.

Importance of Clear Titles/Summaries

The importance of clear titles or summaries in Jira tickets is emphasized. Suggestions are made to improve clarity by providing concise and informative summaries that accurately describe the issue.

Using Clear Titles/Summaries in Jira Tickets

• In Jira tickets, it is important to have clear titles or summaries that accurately describe the issue.

• While a catchy or intriguing title may be fine, it is crucial to provide a clear summary for better understanding.

• A well-written summary helps team members quickly grasp the problem without having to open each ticket individually.

Example: Wrong Password Message

An example of a ticket with a wrong password message on the login page is examined. The expected result and the actual result are discussed.

Example Ticket: Wrong Password Message

• The example ticket describes an issue with receiving an incorrect password message on the login page.

• The expected result is mentioned, but there are no specific details about what exactly went wrong.

Exploring Login Page Issue

The user explores the login page issue further by attempting to replicate it. They discuss how typing an incorrect password triggers an error message related to password requirements.

Replicating the Issue

• To investigate further, the user types an incorrect password on the login page of Circle.us.

• An error message appears stating that the password should contain at least one uppercase letter, one lowercase letter, etc.

Limitations of Bug Report

The limitations of reporting bugs solely based on typing into fields are discussed. It is explained that certain issues cannot be expected if only typing into fields without considering other factors.

Limitations of Typing Into Fields

• Reporting bugs solely based on typing into fields has limitations.

• Some issues may not occur just by typing into fields; other factors need to be considered as well.

• Merely entering information may not trigger all possible scenarios or reveal underlying problems.

Investigating Login Issue

The user continues investigating the login issue by typing into the password field and observing the behavior.

Investigating Login Issue

• The user types into the password field on the login page of Circle.us to investigate further.

• They observe how the application responds and whether any error messages appear.

Sign-In Page Examination

The user examines the sign-in page and wonders where their password is stored. They discuss different tiers in a database structure.

Examining Sign-In Page

• The user examines the sign-in page of Circle.us.

• They question where their password is stored and mention different tiers in a database structure.

Password Storage Location

The user ponders where their password is stored, mentioning that it is not stored in plain text but rather encrypted or hashed for security purposes.

Password Storage Location

• The user wonders where their password is stored.

• It is explained that passwords are not stored in plain text but are encrypted or hashed for security reasons.

Slug Location

The location of slugs in a database structure is discussed, specifically referring to tier three.

Slug Location

• Slugs are located in tier three of the database structure.

• It is clarified that previous references to "Tire" were incorrect, and apologies are made for any confusion caused.

Client-Side Handling of Password

The handling of passwords on the client-side application (front-end app) is explained, including its role in providing an input field for users to enter passwords.

Client-Side Handling of Password

• On the client-side application (front-end app), its role is to provide an input field for users to enter passwords.

• When the user submits or logs in, the password is sent to the server for comparison with the stored password.

Password Encryption and Comparison

The process of password encryption and comparison is discussed, highlighting that passwords are encrypted during transmission and stored as hashes in the database.

Password Encryption and Comparison

• When a user submits their password, it is encrypted during transmission over the internet.

• Upon arrival at the server, it gets decrypted for further processing.

• However, passwords are not stored as plain text; they are converted into irreversible hashes before being stored in the database.

Decoding Hashed Passwords

It is explained that hashed passwords cannot be decoded back into plain text. The comparison of hashed passwords happens using specific algorithms.

Decoding Hashed Passwords

• Hashed passwords cannot be decoded back into plain text.

• The comparison of hashed passwords with stored hashes happens using specific algorithms.

• This one-way procedure ensures security by preventing unauthorized access to actual passwords.

Understanding Password Validation

The speaker discusses how password validation helps in identifying missing information and provides hints for creating a correct password.

Importance of Password Validation

• Password validation helps users understand if they are missing any important information while typing their password.

• It can identify if the password lacks uppercase, lowercase, or digit characters.

• The speaker mentions that this feature is helpful for clients who do not know their passwords.

Differentiating Bugs from Error Messages

The speaker explains that incorrect passwords can only be received from the business logic responsible party and clarifies the difference between an error message and a bug.

Identifying Incorrect Passwords

• When receiving an incorrect password message, it is not considered a bug but rather a response from the business logic responsible party.

• The absence of an error message when entering an invalid passcode to join a circle is identified as a bug.

• The speaker emphasizes that bugs should be distinguished from error messages.

Checking Network Tools and API Level

The speaker asks if any outside noises are audible before discussing network tools and API level testing.

Audible Noises and Testing Tools

• The speaker asks if any outside noises are heard during the conversation.

• Network Tools and Hana at API level are mentioned as tools to observe errors or issues.

• Accessing DevTools on mobile browsers is discussed, including instructions for Chrome on iPhone and Android devices.

Addressing Field Length Issues

Field length issues related to first name acceptance and special character acceptance in user passwords are discussed.

Field Length Issues

• First name field accepts more than 32 characters, which is considered a bug.

• User password field accepts special characters, but it is not a bug as it is not required but allowed.

• The speaker mentions that there is a requirement to delete the topic, which is missing in the implementation.

Mismatch between Requirements and Implementation

The speaker discusses an issue where requirements state that topics should be deletable, but the feature is not implemented.

Requirement Mismatch

• The speaker highlights that there is a mismatch between the requirements and actual results regarding topic deletion.

• This discrepancy can be considered a bug since it was promised in the requirements.

Error Message for Invalid Passcode

The absence of an error message when attempting to join a circle with an invalid passcode is identified as an issue.

Missing Error Message

• When trying to join a circle with an invalid passcode, no error message appears on the UI.

• The speaker suggests that there should be some sort of error message displayed in such cases.

Checking Network Tools for Errors

The speaker asks if any errors are visible in Network Tools or DevTools while using the join button.

Checking for Errors

• The speaker asks if any errors or messages are displayed in Network Tools or DevTools when attempting to join circles using different browsers.

• Instructions are provided on how to access DevTools on mobile browsers for Chrome and Safari on iPhone and Chrome on Android devices.

Testing Mobile Browsers with DevTools

The importance of testing applications in mobile browsers and utilizing browser tools even on mobile devices is discussed.

Testing Mobile Browsers

• It's important to test applications in mobile browsers, especially when there is no dedicated mobile version.

• Instructions are provided on how to access DevTools in mobile browsers for Chrome and Safari on iPhone and Chrome on Android devices.

Investigating API Responses

The speaker suggests checking the network tab in Network Tools to investigate API responses.

Analyzing API Responses

• The speaker suggests checking the network tab in Network Tools to gather information about API responses.

• An issue related to attempting to create a circle with an already registered email address is mentioned, where no error message appears on the front end despite receiving an unauthorized response from the API.

Timestamps have been associated with relevant sections as per the transcript.

New Section

In this section, the speaker discusses the bug lifecycle and the steps involved when a bug is found.

Bug Lifecycle

• When a bug is found, it is reported.

• After reporting, the bug is assigned to a developer or product manager.

• The bug may be specifically assigned to someone or added to a to-do list for anyone to grab.

• Once assigned, the bug is fixed by the developer.

• An example of a bug's lifecycle is given: "Password not masked on login page." It goes through statuses like new, in progress, fixed, and verification.

New Section

In this section, the speaker discusses how to handle bugs that occur during different versions of an application.

Handling Bugs in Different Versions

• If a bug occurs in version 1 and version 2 is released, testing type depends on what failed. For example, if build acceptance testing fails due to an untestable condition, it needs to be sent back to the developer for resolution.

• The speaker gives examples of scenarios where build acceptance testing might fail due to issues like server errors or crashes on launch.

New Section

In this section, the speaker concludes the discussion on handling bugs in different versions and mentions taking a break before moving on.

Conclusion and Break

• The speaker emphasizes that encountering untestable conditions in specific versions requires sending them back for resolution. Examples include disabled buttons or crashing applications.

• A break will be taken before continuing with the next topic.

Introduction and Break Request

The speaker mentions leaving a screen open for the viewer to see and requests a slightly extended break of around seven minutes.

• The speaker leaves the screen open for viewers to see.

• Requests a slightly extended break of around seven minutes.

Note-Taking and Definitions

The speaker encourages viewers to start taking notes while they are on break. They mention building definitions for various testing types such as UAT, integration testing, cross-browsing testing, and regression testing.

• Viewers are encouraged to start taking notes during the break.

• Definitions for various testing types will be built, including UAT, integration testing, cross-browsing testing, and regression testing.

Workbook and Return Time

The speaker mentions not being able to edit the document but refers to it as a workbook. They state that they will return after the break.

• The document cannot be edited but is referred to as a workbook.

• The speaker will return after the break.

Break Conclusion

The speaker announces their return from the break.

• The speaker returns from the break.

Uncertainty about Noise

The speaker expresses uncertainty about potential background noise but hopes there won't be any disturbances during the session.

• Uncertainty about potential background noise.

• Hopes there won't be any disturbances during the session.

Foreign Mentioned

A mention of "foreign" is made in passing. No further context is provided.

Foreign Mentioned Again

Another mention of "foreign" is made in passing. No further context is provided.

Technology Stack and Document Location

The speaker mentions the technology stack being available in a document posted on the class page. They encourage viewers to read more about it and learn from the information provided.

• The technology stack is available in a document posted on the class page.

• Viewers are encouraged to read more about it and learn from the information provided.

Open Circle Mentioned

The speaker briefly mentions Open Circle, possibly referring to another topic or resource related to testing.

• Open Circle is mentioned, but no further context is provided.

Workbook Availability

The speaker suggests checking the workbook or stack on one's own if it's possible, as not all information may be explicitly given. They reassure viewers that they won't go too deep into specific topics during this session.

• Suggestion to check the workbook or stack independently.

• Reassurance that specific topics won't be explored in depth during this session.

Mobile Applications Discussion

The speaker mentions discussing mobile applications and states that knowing whether an app is native or cross-platform would be sufficient for their purposes.

• Discussion of mobile applications.

• Knowing if an app is native or cross-platform would be sufficient for their purposes.

Timeline Building Introduction

The speaker introduces the concept of building a timeline and asks viewers if they can put different testing types in the correct order of execution.

• Introduction to building a timeline.

• Viewers are asked if they can put testing types in the correct order of execution.

Collaboration on Timeline Building

The speaker suggests working together to build the timeline. They start with discussing what happens when implementing new functionality and ask viewers for their input on what testing type comes first.

• Collaboration on building the timeline.

• Discussion about what happens during implementation of new functionality.

• Request for input on the first testing type in the timeline.

Activities During Implementation

The speaker asks viewers what they do while developers are working on implementation. They suggest reading user stories and acceptance criteria as one possible activity.

• Question about activities during implementation.

• Suggestion to read user stories and acceptance criteria as an activity.

Preparation for Testing

The speaker continues discussing activities during implementation, mentioning that they create test documentation based on user stories and acceptance criteria. They mention creating a traceability matrix and test cases.

• Discussion of preparing for testing during implementation.

• Creation of test documentation based on user stories and acceptance criteria.

• Mention of creating a traceability matrix and test cases.

First Testing Type

The speaker asks viewers to identify the first testing type that occurs after implementation. They mention options such as functional, build acceptance, and user acceptance testing.

• Question about identifying the first testing type after implementation.

• Options mentioned: functional, build acceptance, and user acceptance testing.

Clarification Needed for Testing Types

The speaker suggests clarifying the meaning of each testing type mentioned. They reassure viewers not to worry if something is unclear and that they won't go into too much detail during this session.

• Suggestion to clarify the meaning of testing types.

• Reassurance that lack of clarity is okay.

• Mention of not going into excessive detail during this session.

Conclusion

The speaker concludes the discussion on building a timeline and encourages viewers to ask questions if needed.

• Conclusion of the discussion on building a timeline.

• Encouragement for viewers to ask questions if needed.

Usability Testing

Vladimir discusses the concept of usability testing and its importance in evaluating software applications with representative users. He mentions using tools like Figma to create prototypes for user feedback before finalizing requirements and writing test cases or code.

What is Usability Testing?

• Usability testing involves evaluating software applications by testing them with representative users.

• It helps ensure that the application makes sense to the user and meets their needs.

• Usability testing can be done on features that are still under development or even during the requirement definition phase.

• Tools like Figma can be used to create prototypes for users to interact with and provide feedback.

Evaluating Ideas

• Usability testing allows us to evaluate our ideas before finalizing requirements or writing code.

• It helps determine if our ideas make sense to the user and if they find them usable.

• In some cases, where there is no dedicated UX/UI team or budget for recruiting users, we may need to conduct usability testing ourselves.

Importance of Usability Testing

• As developers, we may not always have the best perspective on how well an app will perform for users.

• Usability testing provides valuable insights from real users who may have different perspectives and experiences.

• By conducting usability testing early on, we can identify any issues or improvements needed before investing time in development.

Unit Testing

Vladimir introduces unit testing as a white box testing technique primarily done by developers. He explains that unit tests focus on testing small units of code functionality, such as methods or functions.

What is Unit Testing?

• Unit testing is a white box testing technique primarily performed by developers.

• It involves testing small units of code functionality, such as methods or functions.

• The goal is to ensure that each unit of code works as expected and can be used interchangeably.

Benefits of Unit Testing

• Unit testing allows developers to test their code at a granular level, making it easier to identify and fix issues.

• It helps ensure that individual units of code function correctly before integrating them into the larger application.

• By catching bugs early on, unit testing saves time and effort in the long run.

Example: Calculator Unit Test

• As an example, Vladimir mentions a calculator application.

• A developer would write unit tests for each functionality of the calculator, such as addition, subtraction, multiplication, and division.

• The tests would compare the expected results with the actual results to verify that the functions are working properly.

The transcript does not provide further information beyond this point.

Unit Testing

This section discusses the importance of unit testing in software development and how it helps ensure the correctness of code.

Unit Testing Basics

• Unit testing is a low-level testing technique used to test individual units or components of software.

• The purpose of unit testing is to compare expected results with actual results to determine if the code is functioning correctly.

• If the expected and actual results are equal, the test case passes. If they are different, the test case fails.

Integration Testing

• Integration testing involves testing how different units or components work together and communicate.

• It can be done using white box techniques (testing multiple classes together) or black box techniques (testing integration with external systems).

• Integration testing may involve third-party solutions like payment systems or APIs such as Google Maps.

Importance of Unit Testing

• Unit tests help identify bugs early in the development process, making them cheaper to fix.

• They are essential for ensuring that all units of code function correctly before moving on to higher levels of testing.

• Skipping unit tests can lead to issues being discovered later in the development cycle, which is more costly.

Other Types of Testing

• There are other types of testing beyond unit and integration testing, such as usability testing and cross-browser compatibility testing.

• Build acceptance testing is performed after developers complete their work and ensures that new functionality added to the application works correctly.

• The purpose of build acceptance testing is to identify any critical issues before further testing.

Build Acceptance Testing

This section focuses on build acceptance testing and its purpose in ensuring that an application is in a testable condition.

Purpose of Build Acceptance Testing

• Build acceptance testing is performed to ensure that a build or version of the application is in a testable condition.

• The goal is to identify any critical issues before proceeding with further testing.

• It helps verify that major functionality is not broken and that the application can be used for testing.

Importance of Passing Build Acceptance Testing

• If build acceptance testing does not pass, it indicates that there are critical issues with the build.

• Even if the issues are not severe, such as complete application crashes, any major functionality being broken means the build did not pass.

• For example, if account creation or login functionality is not working, it would fail build acceptance testing.

Next Steps after Build Acceptance Testing

This section discusses what happens after passing build acceptance testing and explores different types of testing.

Determining Next Steps

• After passing build acceptance testing, the next step depends on the specific situation and requirements.

• Different types of testing may be conducted based on priorities and needs.

Types of Testing

• Possible types of testing include unit testing, integration testing, functional module testing (black box), cross-browser compatibility testing, and more.

• Each type serves a specific purpose in ensuring the quality and correctness of the software.

• Prioritizing these tests based on their importance can help identify potential issues earlier in the development process.

Purpose of Functionality Testing

In this section, the speaker discusses the purpose of functionality testing and why it is performed after build acceptance testing.

Why Functionality Testing?

• Functionality testing is conducted to verify if specific features or bug fixes implemented in a build are working correctly.

• It helps ensure that new functionalities are functioning as expected and that previously identified bugs have been resolved.

Relationship with Build Acceptance Testing

• Build acceptance testing is performed internally to verify that a build meets certain criteria before being shown to customers.

• Once a build passes build acceptance testing, functionality testing is conducted to further validate the implemented features and bug fixes.

Purpose of Functionality Testing (Continued)

The speaker continues discussing the purpose of functionality testing and its relationship with build acceptance testing.

Verifying Implemented Features

• Functionality testing aims to verify if something specific was implemented in a particular build.

• It checks for fixed bugs or newly added functionalities in the current version.

Importance After Build Acceptance Testing

• If a specific version fails build acceptance testing, it cannot be verified for fixed bugs or new features.

• In such cases, moving on to the next version (e.g., Version 3) allows for retesting and verification of bug fixes and new features.

Evaluating Version 3

The speaker discusses evaluating Version 3 after previous versions failed build acceptance testing.

Assessing Integration at Different Levels

• Integration can occur at both white box and black box levels.

• White box integration refers to integrating different components within an application, while black box integration involves integrating an application with other external applications.

Evaluating Version 3 Functionality

• To evaluate Version 3, the speaker suggests checking if features like joining a circle, submitting forms, and creating circles are working properly.

• Admin access for creating circles should also be tested.

Verifying Bug Fixes

The speaker discusses the importance of verifying bug fixes in Version 3.

Bug Fixes from Previous Versions

• Two bugs were reported and claimed to be fixed in previous versions.

• One bug involved password masking, while the other was related to a truncated login error message.

Ensuring Bug Fixes in Version 3

• It is necessary to verify if these bug fixes are indeed present in Version 3.

• Testing scenarios can include entering registered email addresses with intentionally incorrect passwords to check for proper error messages.

Documenting Bug Fixes

The speaker emphasizes the importance of documenting bug fixes and providing evidence through screenshots.

Attaching Screenshots as Proof

• Taking screenshots during testing helps provide evidence that a bug was fixed or a feature is working correctly.

• Screenshots can be attached to bug tickets when reporting and closing them.

Conclusion

In this transcript, we learned about the purpose of functionality testing after build acceptance testing. We discussed how functionality testing verifies implemented features and why it is important after build acceptance testing. Additionally, we explored evaluating Version 3 and ensuring bug fixes from previous versions. Finally, we highlighted the significance of documenting bug fixes with screenshots as proof.

Bug Lifecycle and Closing Process

In this section, the speaker discusses the bug lifecycle and the process of closing a bug.

Bug Lifecycle

• Bugs go through different states in their lifecycle, starting from being reported to being closed.

• The speaker mentions that they opened a comment to show that the password is now masked.

• They add a comment stating "beautified version 3" and save it.

• The bug goes through various states such as opened, approved, fixed, verified, and closed.

Closing a Bug

• Once a bug is fixed and verified, it can be closed.

• If for some reason the bug is not fixed during the QA state, it can be reopened and assigned back to the developer.

• Additional proof may be required when reopening a bug, such as screenshots or additional logs depending on the ticket.

• The speaker asks if they should close the ticket or come back to it later for regression testing.

Verifying Fixed Bugs

In this section, the speaker talks about verifying fixed bugs and closing them.

Verifying Fixed Bugs

• The speaker mentions that they have gone through the lifecycle of a bug with us.

• They explain that once a bug is fixed and verified, it can be closed.

• They mention that sometimes there might be back-and-forth communication between testers and developers if there are difficulties reproducing or fixing the bug.

• It is important to ensure that bugs are properly fixed before closing them.

Reopening Unfixed Bugs

In this section, the speaker discusses what to do if a bug is not fixed during QA state.

Reopening Unfixed Bugs

• If a bug is not fixed during the QA state, it can be reopened.

• The speaker mentions that they would reopen the bug and assign it back to the developer.

• They also mention that additional proof may be required when reopening a bug, such as screenshots or additional logs.

Providing Additional Proof for Unfixed Bugs

In this section, the speaker talks about providing additional proof when reopening an unfixed bug.

Providing Additional Proof

• When reopening an unfixed bug, it is important to provide additional proof beyond just stating that it is not fixed.

• Screenshots and additional logs can be helpful in providing evidence for the issue.

• The speaker mentions that they need a moment to find a screenshot for demonstration purposes.

Closing Verified Bugs

In this section, the speaker discusses closing verified bugs and completing the bug lifecycle.

Closing Verified Bugs

• Once a bug is fixed and verified, it can be closed.

• The speaker demonstrates how to close a ticket by attaching a new screenshot and marking it as "verified in version 3."

• They set the status of the ticket to "done" and consider whether to go home or continue testing.

Regression Testing after Bug Fix

In this section, the speaker talks about regression testing after fixing a bug.

Regression Testing

• After closing a bug, it may be necessary to perform regression testing around the fix.

• Regression testing ensures that fixing one issue does not introduce new issues in other areas of functionality.

• The speaker asks if they should do some regression testing around the fix before going home or continuing with their timeline.

Back-and-Forth Communication for Bug Fixes

In this section, the speaker discusses the potential back-and-forth communication between testers and developers during bug fixes.

Back-and-Forth Communication

• There may be a lot of back-and-forth communication between testers and developers during bug fixes.

• Sometimes bugs are difficult to reproduce or fix, leading to multiple iterations of fixing and retesting.

• The speaker mentions that it can be challenging when a bug is partially fixed but new issues arise, requiring further investigation on whether to close the ticket or open a new one.

Partial Regression Testing after Bug Fix

In this section, the speaker talks about performing partial regression testing around a bug fix.

Partial Regression Testing

• After fixing a bug, it may be necessary to perform partial regression testing around the specific functionality that was fixed.

• This testing ensures that the fix did not introduce any new issues in that particular area.

• The speaker asks for suggestions on what else they should check around the login functionality after verifying the bug fix.

Checking Different Scenarios in Login Functionality

In this section, the speaker discusses checking different scenarios in the login functionality after verifying a bug fix.

Checking Scenarios in Login Functionality

• After verifying a bug fix related to login functionality, it is important to check various scenarios.

• The speaker suggests trying to log in with valid credentials as well as invalid password and non-existing usernames.

• They mention that there is always a chance of something breaking while fixing one issue, so thorough testing is necessary.

Troubleshooting Existing User Login Issue

The speaker discusses a bug fix related to an existing user login issue and the introduction of a regression bug in a social network app.

Existing User Login Issue

• The bug fix addressed the issue of invalid passwords, but there is still a truncated error message for existing users not found.

• The speaker mentions the importance of thoroughly testing the login feature after the fix to ensure nothing else was broken.

• They explain an example of a regression bug in another app where adding a new field caused issues with button behavior.

Regression Bug Example

• The speaker describes a social network app with a change password functionality that initially had two fields (current password and new password).

• An improvement ticket suggested adding a third field (confirm new password) to prevent users from accidentally changing their password.

• However, when the third field was added, the logic for button behavior was not updated, resulting in the button remaining enabled even if only two fields were filled.

• This is an example of a regression bug, where changes introduced during development cause unintended issues in previously working features.

Regression Testing and Impact Analysis

The speaker explains the importance of regression testing and impact analysis when dealing with changes or fixes in software features.

Regression Testing Importance

• Regression testing involves checking previously working features and related functionalities after making changes or fixes.

• It ensures that no unintended issues or bugs have been introduced as a result of modifications.

• In the given example, although the change password functionality worked fine with the addition of a third field, it caused issues with button behavior.

Impact Analysis

• When performing regression testing, it's essential to consider sister features that might be affected by changes made to one feature.

• For example, if working on the change password functionality, it may be necessary to rewrite test cases for login as well, to ensure nothing was broken.

• The speaker emphasizes the need to open a bug ticket if there are issues with implemented changes, even if an improvement ticket was closed.

Comprehensive Testing and Regression Bugs

The speaker discusses the importance of comprehensive testing and provides further examples of regression bugs.

Comprehensive Testing Approach

• When testing a specific feature, it's important to also consider related features that might be impacted by changes or fixes.

• In addition to running test cases for the feature itself, it is advisable to rewrite test cases for sister features that could potentially be affected.

Regression Bug Example

• The speaker mentions the need to thoroughly test various scenarios related to login functionality.

• They explain that if they have any work related to change password functionality at the end of the day, they would not only run test cases for change password but also rewrite test cases for login.

• This approach ensures that any potential regression bugs are identified and addressed before releasing the software.

Regression Testing and Timeline Organization

The speaker highlights the importance of regression testing after build acceptance and offers tips on organizing timelines effectively.

Regression Testing After Build Acceptance

• After performing build acceptance tests (e.g., checking bug fixes or new functionalities), regression testing should be conducted.

• Regression testing involves partially retesting features and their sister functionalities to ensure no unintended issues have been introduced.

Organizing Timelines

• Timelines can be organized in a way that suits individual preferences.

• The speaker suggests revisiting timelines when meeting with Michael (presumably another team member) to discuss testing types and further explore regression testing concepts.

[t=1:47:33s] Testing Prioritization and Regression Testing

The speaker discusses the importance of prioritizing test cases and performing regression testing to ensure that code modifications do not break existing functionality.

High Priority Test Cases

• Running high priority test cases for each functionality helps identify any accidental breakage in other areas.

• Regression testing is performed during feature testing to ensure nothing gets broken as a result of code modifications.

End-to-End and Cross-Browser Testing

• For bigger features or interconnected functionalities, end-to-end testing may be conducted.

• New functionality is tested in multiple supported browsers simultaneously to ensure cross-browser compatibility.

• Supported browsers for the application include Chrome, Firefox, Safari, and Microsoft Edge.

Non-functional Testing

• Cross-browsing testing is a type of non-functional testing that verifies the application's compatibility across different browsers.

• It is usually included within the functionality testing phase rather than as a separate step during regression testing.

• Mobile versions are also considered for cross-browser and cross-platform testing.

[t=1:52:24s] User Acceptance Testing

The speaker briefly mentions user acceptance testing (UAT) and its role in the development process.

UAT Execution

• User acceptance testing is typically performed by specialists or third-party individuals.

• It helps validate whether the developed product meets user requirements and expectations.

[t=1:53:39s] Order of Execution and Clearance Questions

The speaker discusses the order of execution in relation to clearance questions during user acceptance testing.

Clearance Questions

• During clearance, questions arise regarding when certain tasks should be executed and who should perform them.

• The discussion aims to provide clarity on when user acceptance testing occurs within the overall timeline.

Conclusion

The transcript covers topics related to prioritizing test cases, regression testing, end-to-end testing, cross-browser testing, user acceptance testing, and the order of execution in relation to clearance questions. These topics provide insights into ensuring the quality and functionality of software during the development process.

Understanding User Acceptance Testing

In this section, the speaker discusses the importance of user acceptance testing and its relevance to industry standards. They also mention the involvement of doctors in providing feedback and running tests on the developed application.

Importance of User Acceptance Testing

• User acceptance testing is crucial to determine if an application meets industry standards.

• Feedback from doctors during usability testing can help improve the application.

• User acceptance testing involves inviting end clients to test the application.

User Acceptance Testing for Open Circle

• The speaker questions whether user acceptance testing is necessary for applications like Open Circle.

• They ask for opinions on whether subject matter experts are needed for user acceptance testing in this case.

Different Types of Testing

• The speaker mentions that Michael will provide more information about different types of testing, including user acceptance testing, beta testing, and crowd testing.

• Not all applications require specific domain knowledge or subject matter experts.

• Beta testers can be invited to test software, while open circle may be suitable for beta testing rather than user acceptance testing.

Running Test Cases in Remote Browsers

In this section, the speaker introduces a remote browser service called bitbar.com and suggests using it to run test cases. They explain how to start a browser test session and select different browsers and operating systems for testing.

Using Bitbar.com for Remote Browser Testing

• The speaker recommends trying out remote browser testing using bitbar.com.

• Users can sign up for a two-week trial period with free access to their account.

• By selecting the desired browser, operating system version (Mac OS or Windows), and browser version, users can start a test session.

Running Test Cases on Open Circle

• Users are advised to run their test cases on Open Circle's website (version 3) using remote browsers.

• The speaker demonstrates how to start a test session and run test cases on the website.

Other Remote Browser Services

• The speaker mentions other remote browser services like browser stocks, Lambda Test, and sour slop.

• These services offer similar functionality for remote testing.

• Links to these services are provided on the class page.

Homework Assignment: Using Remote Browsers

In this section, the speaker assigns a homework task to use a specific form for running test cases in remote browsers. They provide instructions on how to access the form and remind students to be careful when entering their email addresses.

Homework Assignment: Running Test Cases in Remote Browsers

• Students are assigned a homework task to run their test cases in remote browsers using a specific form.

• The speaker provides instructions on accessing the form and warns students to be cautious when entering their email addresses.

Timestamps have been associated with relevant bullet points as per the transcript.

Benefits of Executing Someone Else's Test Cases

The speaker suggests that executing someone else's test cases can provide a better understanding of how to improve one's own test cases.

Importance of Executing Others' Test Cases

• By executing someone else's test cases, individuals can gain insights into what could have been improved in their own test cases.

• It is recommended to execute test cases created by others to enhance one's understanding and skills in building effective test cases.

Testing with Non-Subject Matter Experts

The speaker discusses the idea of involving non-subject matter experts, such as relatives in France, for testing purposes.

Involving Non-Subject Matter Experts

• While it may be possible to ask relatives or non-experts for testing, their feedback may not be as reliable or accurate compared to subject matter experts.

• Subject matter experts are not necessarily required for certain types of testing scenarios.

Open Discussion and Questions

The speaker invites questions, comments, and concerns from the audience.

Open Discussion

• Participants are encouraged to ask any questions or share their thoughts on the topic at hand.

• This is an opportunity for attendees to raise any concerns they may have regarding the discussion.

Considerations for Test Scenarios

The speaker mentions the importance of considering different test scenarios based on authentication technology used.

Authentication Technology and Test Scenarios

• Depending on the specific test scenario, it is important to consider the technology used for authentication.

• In some cases, authentication may rely on cookies rather than cache. Clearing cache files may not fully reset the authentication process.

• The speaker suggests discussing this topic further in the next session to explore specific scenarios where cache files should not be present.

Rebuilding Cache Files

The speaker discusses the quick rebuilding of cache files and mentions scenarios where cache files may not be desired.

Quick Rebuilding of Cache Files

• Cache files can be rebuilt quickly, even after clearing them.

• Unless there is a specific scenario where having no cache files is necessary, the rebuilding process occurs rapidly.

Building a Web Testing Checklist

The speaker proposes building a web testing checklist for future discussions.

Web Testing Checklist

• The speaker suggests creating a web testing checklist that covers various aspects of web testing.

• This checklist will be discussed in detail during the next session.

Execution in Version Three

The speaker mentions executing test cases in version three.

Execution in Version Three

• It is recommended to execute test cases specifically designed for version three of the software or system being tested.