This is an adaptation of the original article by Yaroslav Pernerovsky published on DOU.ua, a Ukrainian IT community and blog. Many of you have heard that using automation is a good idea, but not everyone clearly understands how it benefits a project. Some expect to achieve 100% bug-free software. Others believe that QA automation engineers will cover all tasks more effectively than manual testers. Automation testing is full of  myths and misconceptions. If you decide to go for automation testing, mind that it's a rather expensive investment with significant advantages in a long-term perspective. So let's try to figure out when to go for automation and how to avoid pitfalls on the way. When to Use Automation in Software Testing? You certainly need test automation in the following cases: You’ve got a project that lasts for a year or longer. The number of regression tests to run is rapidly increasing. Testers risk getting stuck in a routine, repeating a small number of the same test cases instead of focusing on overall quality. You have a distributed development team or more than two people writing code. The developers should be certain that the changes they make won’t break someone else’s code. Without autotests, they find out about the issues in a day or two in the best-case scenario. In the worst case, users will report critical bugs when the software is already in production.  You support several product versions, constantly releasing patches and service packs for each. Testing different configurations is a routine, and we should minimize the routine. You are developing a service that processes different kinds of data. Entering a large bulk of data manually to conduct tests and analyze results  is a too time-consuming and resource-intensive task for human beings. You work according to agile principles – with short iterations and frequent releases. There is no time for manual regression runs within the sprint. Still, the team should be certain that recent code changes haven’t affected the functionality and no critical bugs appeared. If your project is not like that, then you probably don’t have to bother about automation. Why We Need Automated Tests An opportunity to hasten the testing process isn’t the only benefit that comes with automated tests. There are several other features that add up to the efficiency of automation: test coverage integrity; clear and reliable results; costs for development and support; easy launching and analyzing results, etc.  The main performance indicators of automation are speed, wide test coverage, and cost-efficiency. This is what you need to take into consideration. Any kind of automation reduces the amount of routine work. Test automation is not an exception. However, there is a common misconception that autotests should completely compensate for the work of manual testers, and scripts are enough to check a product. This is nonsense. No script can replace a living person (yet). A script can repeat running the programmed actions – programmed by a person – and signal that something has gone wrong. A script can do simple checks quickly and without human intervention, but it can’t TEST. Why Automation Falls Short of Expectations There are quite a few reasons why automation might not meet your expectations. All are somehow related to incorrect development or management decisions, and sometimes to both. Management decisions deserve a special article, but for now, we’ll just highlight the most damaging errors without broad explanation. An attempt to save on hiring automation QA specialists. If a manager believes the company can just pay for Selenium courses for employees and they will become automation pros, there are some myths to be revealed. An attempt to introduce automation without a well-thought-out strategy and planning – “let’s-implement-and-then-we’ll-see” approach. The only situation that is worse is automation for the sake of automation – “That other company has it, so I need it, too.” Too late start: automation begins when manual QA engineers are exhausted and can’t handle the scope of work. A belief that hiring students for running regression tests manually is cheaper. It means no one is going to implement automation on the project, even though it is essential. Development solutions are decisions software engineers make during working on automation strategies and implementing them. This includes the choice of tools, types of testing, frameworks, etc. Let's take a closer look at some development mistakes.  Automating UI Tests Only Is Wrong The most common mistake is a decision to automate only tests for the graphic user interface. This idea doesn’t seem bad when you get it. It may even be helpful for quite a long time. Automating UI tests only can even be sufficient if the product is already at its final stage and is no longer developing. As a rule, however, this isn’t a good long-term solution for developing projects. UI tests simulate how users interact with an application. It may seem that UI testing is the most logical starting point for automation, but there is a couple of nuances: — UI tests are unstable — UI tests are slow. They are unstable because tests depend on the app interface layout. If you change the order of the buttons on the screen or add/remove an element, the tests may break. The automation tool won’t be able to find an item or it can click on a wrong button and alter test logic. The more tests you have, the more time you need to spend on fixing and supporting them. As a result, you cannot rely on these tests due to frequent false-positive results. At some point, a QA engineer spends all their time correcting errors in scripts that failed instead of writing new ones. These tests are slow because the application interface is slow, too. It requires redrawing, loading resources, waiting for some data to appear, etc. Test script just waits until the system runs it, and that’s a waste of time. Moreover, a test may fail because it is trying to use an element that a slow UI hasn’t managed to render yet. The Way Out Stabilization. We deliberately dramatized the instability. This issue isn’t difficult to solve, but automation QA engineers often prefer not to try solving it. The first thing you need to do is make sure developers don’t forget to add unique attributes for the elements so that an automation tool can identify each of those elements. It is necessary to give up multi-level xPath expressions and CSS selectors and use unique ID, name, etc. wherever possible. This requirement should be explicitly stated in the development guidelines and listed among the definition of done for developers. Be ready for an excuse like ”that’s an overhead for developers.” Perhaps it is, but the team needs to write unique IDs only once and then can forget about them forever. This simple procedure saves hundreds of hours for an automation QA engineer. An application under test should be suitable for testing. If it’s impossible, you need to modify code or forget about this app forever. Besides, it is a good practice to set up an automation tool to wait patiently for the moment when an element becomes available for interaction.  Speeding up. If instability is simple enough to handle, we should address the issue of the slow tests comprehensively since it affects development as a whole. The simple things that can speed up the process are to deploy the application and run tests on faster hardware, to avoid cases when network delays influence the test and application interaction, etc. In other words, it is necessary to solve the problem with hardware and test architecture. Such approach helps to win at least twice more time. Also, consider an opportunity of the independent and parallel launch of test cases, despite the limitations. The logic of the app under test isn’t always possible to test in multiple threads. Situations like this are quite specific and rare, but they do happen. The hardware specifications matter, too. The most radical step is to create as few UI tests as possible. Fewer tests mean earlier results. Testing Pyramid Do you remember a famous testing pyramid? If you put a blunt razor under the small pyramid in the evening, it will become sharp again by morning ©. A pyramid is a very convenient metaphor. It clearly illustrates the desired number of automated tests for each level of the system architecture. There should be a lot of low-level unit tests and very few high-level UI tests. The question is, why is it so and why does this pyramid matter? Everything is pretty simple. Do you recall how finding and fixing an issue proceeds during manual testing? First, a developer makes changes to the code. A QA engineer is waiting until a new build is assembled and deployed on the test stand. A tester runs a check, finds an issue, and creates a ticket in a bug tracking system. A developer immediately responds and fixes the problem.  There are new changes to the code, and then goes the new build again, deploy, and retest. If everything is fine, a QA engineer closes the ticket. It takes from a couple of hours to several weeks to fix an issue after it is reported. What happens when this test is automated? You still have to wait for the new build and for tests to be completed. Then you analyze the results of the test run. If there are some issues, it is necessary to determine their origin – whether it is the app or the test code. Then you run a failed test again manually to understand if the problem has been identified correctly.  Start a ticket, wait until the bug is fixed. Restart the test, make sure everything is fine, and close the ticket. Again, it takes from a couple of hours to several weeks. But while the tests run, a QA engineer keeps working on other tasks.  Automated tests using API to communicate with the back-end are a different story. There are some attractive options to consider: — A team runs tests on a deployed application with all external systems functioning. Time for execution and analysis of the results reduces since there are fewer false-positive results. The rest is pretty much the same as in the UI tests. — Tests are run on a ready build without deploying it to the test environment. External systems are blocked. Tests check the build, issues don’t require creating tickets since a developer fixes issues immediately. The progress in bug detecting and fixing speed is huge. — And there are unit and component autotests. They do not require a ready build and are launched immediately after compiling a module. The response is instant. The time that passes between finding and fixing an issue is minimal – only a few minutes. The lower you go down the pyramid, the less time mentioned autotests take. Testing becomes very time-efficient. The lower level you take, the more effective tests coverage and response time get. Complex Approach It is important to understand that unit tests check the code. They verify that a piece of code works as intended and doesn’t break the general logic. UI tests are critical, as they check the whole system – something a user will access. To get effective results, you need to find the right combination of all kinds of autotests at each level. Test-Driven Development is no longer a recommendation. It should come by default. TDD helps you avoid problems during refactoring and development issues typical for large teams. At the level of API testing, you need to replace functional tests by fast and stable regression tests during a sprint. Only demo acceptance tests, the so-called Happy Path or End-To-End scripts, proceed to the UI tests stage. It is relevant for both web and mobile applications. Thus, if you simply follow the pyramid recommendations, you can get very quick tests with excellent coverage while maintaining the sane cost of development and support. Bottom Line Some projects don’t require full automation. Auxiliary scripts may be enough to make a tester’s life easier. But if we’re talking about a long-term project with a huge team working on it and an equally huge plan for development, automation is essential. Excellent test automation is achievable if you develop autotests at each level of the system architecture. This decision alone is already the key to success.

This is an adaptation of the original article by Svyat Login published on DOU.ua, a Ukrainian IT community and blog. Mobile app security testing is an important part of product development that ensures protection against malware and hackers. The majority of Android apps require registration. Users enter sensitive data, like emails, phone numbers, and payment details. The data shared with an app is stored on a company’s server, and without proper security, hackers can access it. Hopefully, our mobile app security testing tutorial will help you prevent it. The tutorial is based on testing top 10 vulnerabilities defined by OWASP will be useful for QA engineers and developers. Mobile app security vulnerabilities by OWASP The OWASP TOP 10 list of vulnerabilities in mobile applications includes: Mobile and web applications have at least a half of security issues in common, as both app types work the same way, sharing client-server architecture. A native application is a client for mobile devices, while a browser is a client for the web. Every request from a mobile device and a browser is transmitted to the (same) server. As a result, half of the techniques used for detecting web vulnerabilities are suitable for searching gaps in native applications too.  Let’s start with a set of tools we need for a basic application security check. Later, we’ll explain how to apply this toolkit for Android app analysis. iOS, however, has a slightly different nature, that’s a subject for a different blog post. How to Test Mobile App Security So how to do security testing for mobile apps? We’ll need several things for that. Test environment, e.i. an app. We can use the DIVA app. It contains the most common vulnerabilities of mobile applications, and you can practice finding them.  DIVA Welcome screen Mobile device. Take the Genymotion emulator or a real one. Just remember that the device should be rooted. Otherwise, you won’t be able to penetrate. GENYMOTION Filters screen​​​​ Santoku Linux. This is one of the Android app security testing tools created specifically to check the apps for vulnerabilities. All the necessary applications for hacking already preinstalled. Santoku for Linux - general windows view Android App Security Testing Step by Step 2018 OWASP statistics on security bugs occurrence provides a list of vulnerabilities to pay attention to during mobile app audit. That’s what today’s Android app security testing checklist will look like:  We won’t analyse the categories in a numerical order but move straight to M9 – Reverse Engineering, since the penetration test begins with it. M9 — Reverse Engineering Reverse engineering of mobile code is common. This is a simple and unauthorized analysis of: Application source code Libraries Algorithms Tables, etc. To obtain an app’s source code, you need to upload an installation file (APK) to Santoku Linux, open the console, and execute easy commands. Run the command unzip -d diva-beta base.apk. As you might guess, it unzips the application and extracts the files in a folder we’ve called diva-beta. Next, open this folder and run the command d2j -dex2jar classes.dex. It will decompile the code this file contains. If we open the file without decompilation, we’ll get some mojibake. After running the command, a new file classes-dex2jar.jar will appear in the folder. It will contain a normal app source code suitable for reading by humans. To open this file and begin to study the app code, we need a Jadx application. It is also installed on Linux distribution. Run the command jd-gui classes-dex2jar.jar. Then, Jadx will open and display the source code. We will be able to understand all the shortcomings and find some vulnerabilities. Checking vulnerabilities of the Android App​​​​​​ on Jadx M1 — Improper Platform Usage And now let’s bounce over to the M1 category. M1 covers improper use of the operating system features or platform security measures. These things happen often and can have a significant impact on vulnerable applications. Since we already have the app with source code, we’ll study one of the APK activities using the previous vulnerability. We can see that a developer used logcat for the app debugging to understand the errors in this field. When compiling the application into a release build, someone forgot to remove the debug command.  What does this mean for app users? If there’s any error or warning, an action will be logged. When a user fills out a form (let's say, for accepting card data), this data will flash in the application logs if a user makes a mistake or receives a warning when filling out. As you can guess, a hacker can gain access to the logs.  Find more details in this video. M2 — Insecure Data Storage This risk on the OWASP list informs the development community of the insecure data storage on a mobile device. A malicious user can gain physical access to a stolen device or log into it using malware. In case of physical access to a device, a hacker can easily open the file system after connecting the device to a computer. Many freeware programs allow a person to view directories and personal data. So remember two things: Confidential in-app data must be encrypted Apps can share data with other apps Let’s take, for example, the app registration form. DIVA registration form You register as a new user. A developer receives your data and stores it unencrypted in a public folder. Other applications installed on your phone can access it. Yes, your data leaks this easily. For more details, check out the video. M3 — Insecure Communication M3 is another common risk mobile app developers forget about. Data flows to and from a mobile app via mobile traffic or Wi-Fi. If this transfer isn’t protected, violators can disclose users' personal information. Hackers intercept user data on a local network through a compromised Wi-Fi network. They can connect through routers, cell towers, proxy servers, or use malware. Some of user data requests to the server pass through HTTP protocol instead of HTTPS. Here’s an example of how to exploit this vulnerability. A penetrator creates a compromised Wi-Fi network. A user connects. Then, the man in the middle begins to analyze all the traffic that flows through this compromised network.  A hacker can intercept user data sent to the server via the HTTP protocol and access the credentials. Below are the examples of good and poor ways to transfer data. You can also watch a video about traffic interception. Poorly managed transfer: Data should be encrypted. Even if an attacker connects to the same network you do and starts intercepting traffic, at least they won’t see the information openly. We will complicate the data theft as shown in the picture below. M5 — Insufficient Cryptography Okay, we have applied the encryption discussed in the previous section. But if we use weak encryption/decryption processes or make errors in the algorithms that run them, user data will become vulnerable again. There are three ways attackers exploit cryptographic problems: Gain physical access to a mobile device Monitor network traffic Use malware to access encrypted data To understand what methods developers use to encrypt data, we need to look at the source code we already have. In the picture above, we can see that a developer has applied the MD5 hash method. This is one of the easiest methods that shouts, “Break me now!” "Break me now" example When intercepting a request from a user, we will see data seemingly encrypted. However, if we open an online decoder and paste the hash there, we’ll see a real user password. M4 — Insecure Authentication Poor authentication schemes allow an attacker to anonymously perform any user actions in a mobile app or on a server this app uses. Weak app authentication is quite common issue due to the input form factor of a mobile device. The form factor strongly recommends using short passwords that are often based on four-digit PIN codes. Authentication requirements for mobile applications may differ significantly from traditional web authentication schemes, where users are expected to be connected to the network and authenticate in real-time. Once an intruder understands how vulnerable the authentication scheme is, they fake or bypass authentication by sending requests to the server to process the mobile app, without using the latter at all. For instance, an attacker can use some kind of an application analyzer – let’s say, Burp Suite. It is enough to analyze what pages this application has. Let’s take a look at an authorization request. Here’s the data sent to the server. An abuser simply tries to obtain information from the server using the original info from the request. They go through the allocated places to achieve a positive result of unauthorized access to someone’s data. In this request, you can: Pay attention to URLs Pay attention to the user type Try to replace the token by choosing the right one (with access to admin functions), etc. M6 — Insecure Authorization M4 risk is often confused with M6 since both relate to user credentials. M6 is about using authorization to log in as a legitimate user. M4 is a case when an attacker tries to bypass the authentication process by logging in as an anonymous user. As soon as a meddler deceives the app’s security mechanism and gains access to the application as a legitimate user, they aim to gain administrative access. By picking requests, a hacker may stumble upon administrator commands.  Attackers typically use botnets or malware to exploit authentication vulnerabilities. The result of this security breach is an opportunity for a penetrator to perform binary attacks on a device offline. It is possible to use Burp Suite for the search, too. In this case, a person tries to fulfill the admin requests as an ordinary user. See vulnerability M4. M7 — Client Code Quality The risk of M7 arises from poor or inconsistent coding practices, where each member of the development team adheres to different coding practices and creates inconsistencies in the final code.  M7 isn’t that threatening to app security. Despite the prevalence, this risk area is difficult to detect. It’s not easy for hackers to learn the patterns of bad coding. This process often requires complicated manual analysis.  Due to poor coding, however, a user may experience slower processing of requests and the inability to correctly download the necessary information. The story of WhatsApp is a good example. WhatsApp engineers discovered the possibility of buffer overflows by sending a specially created series of packages. It wasn’t necessary to answer a call, and an attacker could execute arbitrary code. It turned out that the vulnerability was used to install spyware on devices. You should not use functions that can overflow the buffer, like this: M8 — Code Tampering Not much to tell here, everything is rather clear. Just don’t download APK apps from third-party resources. Hackers prefer to falsify app code, as it allows them to get unlimited access: To other applications on your phone To user behavior In M9 we did reverse engineering of the application so we know the source code, remember? Now we can alter it (fill in some kind of worm that can access data from other apps), recompile, and put the APK on some website with an “available for free” note :) M10 — Extraneous Functionality Before the application is ready for use, the development team often stores code in it to have easy access to the internal server. This code doesn’t affect the app’s operation in any way. However, when a malicious user finds these hints, it’s kind of trouble for developers. What if this code features admin credentials? Let’s take, for example, a page where you need to enter a key to gain access to important data. We’ll study how this page looks under the hood – as the code. We’ll see that here a developer left a hint on what to enter to gain access to the data we need. The video is here. Wrapping Up Now you know: About OWASP Mobile Top 10 What tools to use to search for vulnerabilities What programs can help practice finding vulnerabilities By gaining new testing skills, you can become a more valuable employee and take on more responsibilities. When management notices your progress in testing mobile app security testing services, you’ll certainly get a reward – a salary review, for example. You can become a security specialist, and there is a big shortage of those in the market.  Just remember, the information above is for learning! You can only use it in your projects with the permission of the copyright holder.

Any product is created for the end-user, which means the user experience is what matters most if you want your app to be people's first choice. In products built for studying and learning, user expectations are even higher. Before the release, you have to make sure that everything works properly and there are no bugs. In other words, you need to have your product checked by QA specialists. In this UTOR blog post, we’ll explain the role of QA in e-learning products and how to test e-learning applications based on our expertise. We’ll also examine the main errors that can appear in the e-learning product and discuss how to cope with them. The Importance of QA in E-learning Let’s imagine you have created an e-learning app and you are going to release it to the market soon. Of course, you want to deliver the best quality product. How are you going to achieve it? Start by thinking about your audience. Who are the people that will take your courses? Where are they from? What devices do they use? What operational systems do they prefer? There are many issues to think of before you launch your e-learning service. QA specialists try walking in your learners’ shoes to detect defects and bugs in your application. QA specialists use special tools and testing methods that help them find even those mistakes which no one could suspect. QA in e-learning has its particularities. E-learning products are complicated for testing because they usually include many elements such as texts, photos, illustrations, interactions, and videos. A thorough check-up of each of the elements is needed. To find bugs, QAs need to conduct a complex analysis. Let’s figure out what this analysis includes.  Performance A customer expects a fast and responsive platform, which loads smoothly on every device and provides a seamless user experience.   View on different devices and browsers If you want your user to enter the course from a desktop and mobile, Google Chrome or Mozilla Firefox, be ready to test the product for adequacy in each needed browser and for all the devices. Define your audience’s preferences first.   Text There’s nothing easier than making a bad impression because of the poor grammar or typos. Interface texts, descriptions of courses, explanations of the study process must be correct.    Visuals Pictures and photos help learners to perceive information faster and more efficiently. Make sure that the quality of the images is good, that they are relevant and up-to-date.    Audio/video To make the studying process more engaging, other multimedia tools such as audio or video explanations are commonly used. However, this part requires additional attention. Is the quality of video good enough? Are video transcriptions correct? A good QA considers these issues too.   Interactions/links A cohesive platform is the one you can easily and predictably navigate: from one course to another, from one category of knowledge to another. You have to make sure that there are no problematic issues. QA specialists have special tools that won’t let even the smallest bug spoil a user’s experience.   Contact forms/FAQ Your users’ opinion is valuable for you, isn’t it? Making sure that users can easily reach you and ask their questions is absolutely important to master your product. Image: Codoid.com Factors to Consider in E-learning testing There is an opinion that there are positive and negative types of testing. Negative testing is about finding mistakes and the positive one is about checking if everything works properly.  Let’s look at the negative testing issues that might occur in your product and recommendations to avoid them.  The common E-learning Errors and Tips to Deal with Them Spelling and grammar mistakes Check and then check once again. The more the better. You won’t have a chance to make another first impression. Pay attention to all types of texts you have in the course.   Mixed fonts Mixed fonts on a page look tasteless. Sometimes the difference is not significant, but don’t underestimate an attentive user’s eye. Make sure the fonts are picked right.   Cluttered design Too many images on one page, too many colors, not matching colors… This is just a short list of problems with the course design. Test and ask for other people’s opinions to avoid negative comments in the end.    Broken hyperlinks, inactive buttons Click everything that must be clickable to make sure it really is. There is a big disappointment for a customer to find inactive elements on the page.   Missing navigation buttons Navigating from one page to another is a crucial factor in shaping up the user experience. That’s why the buttons to navigate the course require special attention.    Massive text blocks Trying to understand the main idea of a huge text block is a challenging task. And an extra challenge probably isn’t a thing your clients are looking for. Make text simple and readable.   Dim task instructions We all like to be well-instructed. And one of the most irritating things is unclear instructions. Make sure that your users know what to do by testing the product. What Approaches to Use for QA in E-Learning We’ve mentioned the most typical errors that can occur on the e-learning platform. Are there any approaches that can help you reduce the mistakes? There is not a single answer. The approaches vary from company to company. However, there are a few common factors that influence the quality of any product. Based on our experience on testing software at UTOR, these factors include: Proper communication People don’t read thoughts, that's why it’s necessary for product owners to explain their needs to their QA team. In their turn, the QA engineers have to report about the mistakes in a clear way.    Use the right tools If you expect huge traffic on the platform, you may need stress testing to check whether your platform can cope with the high load. The QA team can pick relevant automated testing tools for your project needs.   Provide end-to-end reviews Encourage the team to do several end-to-end reviews. It’s more difficult to notice a mistake if you deal with the same product and the same functions for hours. QA engineers should make a few cycles of checking to find all bugs and prevent them from recurring again.   Divide the roles One of the secrets of productive work is the correct division of roles in a team. Dealing with a QA team, learn about the main roles and responsibilities of the testing specialists to set up efficient processes.   A new perspective Let other people see your product and speak out about its interface, content, and usability. If you get perspectives from people with various backgrounds, you’ll get a chance to make your product fit different audiences. Final Thoughts QA is a necessary procedure in any product. In particular, it’s important in creating e-learning platforms because the expectations of customers towards the studying resources are naturally high. To achieve the prime results, you may hire a QA team with the needed expertise and be sure that your clients will get a flawless product. UTOR is a software testing company. We have experience in conducting quality assurance for e-learning platforms. You can learn more about the process of testing and the results of our work in our e-learning QA case study. If you’re interested in trying out our testing or QA services, contact us.

In this article, you will get to know what is ISTQB exam certification and the best ways to prepare for it. The material is a translation of an article by Victoria Pysarenko published at DOU.ua, a media and a forum about IT. The article is based on ISTQB certification review of the author. What is the Aim of the Exam? Although today’s diplomas and certificates almost don’t influence the remuneration of QA specialists, many specialists find ways to get international proof of their expertise. Speaking about the ISTQB Certification importance, is one of the most popular ways to get such proof in more than 100 countries. ISTQB certification is a complex exam. Are you interested how many levels are there? You can get tested in expert, advanced, and foundation levels in agile, core, and specialist directions. In particular, the ISTQB Foundation level certification is a base of higher level certificates.  Does the ISTQB certification help to get a promotion or a better salary? It doesn't, but it gives more chances to grow professionally. To pass the ISTQB certification exam, you need at least two things. Firstly, you should be aware of the chosen area of knowledge. Secondly, you need to be skillful in completing the certification. It’s not enough to be good at testing and know the SDLC (Software Development Life Cycle). It’s important to think like the creators of the test. The tests are not as simple as it might seem at first glance. The majority of questions may perturb you. There can be questions with either two correct answers or no correct answer at all. There is one more category of questions about something never mentioned before just to keep you on your toes. I’ll tell you about everything step by step.  How to prepare for the ISTQB Certification Exam After you figured out the basic issues such as how to register for ISTQB certification,  it’s time to get ready for the test. There is a short ISTQB certification preparation guide below. Learn a Syllabus (78 pages) Read and understand a book Foundations of Software Testing ISTQB Certification (207 pages). Even to my humanitarian’s mind, the book is wordy and wishy-washy Read and particularly learn the ISTQB Vocabulary Answer 500 Sample questions. Unfortunately, ‘sample’ doesn’t mean ‘simple’ Read additional resources, do other tests, install the app for more practice Since it is difficult to cope with all of the mentioned things on your own, it’s advisable to join the specialized courses. It can be also useful to talk to people who have already passed the test and who can share their experience During the preparation, you acquire your own vocabulary of synonyms. Those who passed the test will understand me. Sometimes I have a feeling that all of those words substituting one another are used to confuse a testing specialist.   For example, the clear ‘Black-box testing’ is synonymous with ‘Specification-based’, Input/Output-driven, and Behavioral. Аnd ‘White-box’ means the same as ‘Structural’, ‘Structure-based’, ‘Clear-box’, and ‘Glass-box’. It takes effort to learn different names of the same thing.  Another case is that the test contains words that are very similar in writing and absolutely different by meaning. For example, ‘Maintenance Testing’ and ‘Maintainability Testing’ are absolutely different things. In terms of the limited time, it’s really easy to confuse such words. Another example is ‘Decision condition testing’ and ‘Decision table testing’. These are examples of absolutely different approaches. The first approach is aimed to check the code for all the possible condition consequences. Another approach is a Black-box technique of creating tables of certain solutions based on multiple conditions. It’s a great test to challenge your attentiveness. What You Will Learn During the Preparation Getting ready for the test, you will learn a lot of things. I’ll mention a few interesting aspects of the preparation process. Here they are: Structuring theoretical information Strengthening theory by the practical tasks Dealing on all the aspects of testing including the software, manager’s work aspects, risk assessment, team interaction, and the work models in general Types of static and dynamic testing, types of Black-box, and White-box testing techniques The fundamental and detailed testing process with examples Tasks of the Test Lead and a testing specialist Testing a plan answering the questions what? how? what for? Risk management in terms of testing During my preparation, I came across really useful and interesting phrases found in «Foundations of Software Testing. ISTQB Certification» and «Standard Glossary of Terms Used in Software Testing». Here they are: We should understand what is quality for customers and what are their expectations We have a choice to test everything, test nothing, or test a part of the functions (we take into account risk assessment to define how much testing is needed) Testing is a process that includes all the activities of a lifecycle both dynamic and static, related to testing, preparation, evaluation of the software product, and the results of work. All the mentioned activities should prove that the product complies with the requirements and show that they match the mentioned aims One of the seven principles “Misconception of the absence of mistakes” informs that detecting and fixing defects won’t help if the created system doesn’t meet a customer’s expectations and needs The comprehensive testing is unreachable The QA process consists of the following directions of work: planning and management, analysis and design, implementation and realization, evaluation of the outcome criteria, creating reports, and after-testing activities The ‘oracle’ test is a source of the expected result (not a code) to compare with the actual result of the tested functions The needed skills of a QA include an app or a business domain, technology, and testing Risk isn’t a factor that can cause negative outcomes in the future, usually, it is expressed via probability and influence The risk of the project is a risk related to project management, control, or testing within the project. For example, the lack of staff, tough deadlines, change of the requirements, etc. The product risk is a probability that the system or the software may not meet some rational expectations of a customer, a client, or a stakeholder After you pass the exam having gained a certificate with the ‘Completed’ inscription, you understand that all the efforts were worth it. Decided to strengthen your QA expertise? Maybe it’s time to start getting ready for the exam. By the way, it’s possible to get ISTQB certification online. Good luck!